Test Director – Proposed improvements within currently used project life cycle By Jason Dynes
Test Director – What is it used for? <ul><li>Simplifies and organises test management  </li></ul><ul><li>Creates a framewo...
Test Director – How is it used? <ul><li>The Test Management Process involves four phases </li></ul><ul><li>REQUIREMENTS - ...
Test Director – How is it used? <ul><li>4 separate system areas are provided for these phases </li></ul>Specify Requiremen...
Requirements – Why use this? <ul><li>Provides the foundation on which the entire testing process is based </li></ul><ul><l...
Requirements – Proposed Changes <ul><li>To use the ‘Requirements’ tab of Test Director to define Testing Requirements </li...
Requirements - Benefits <ul><li>Any Testing Requirements that do not have associated Test cases can be identified prior to...
Requirements – Proposed Changes <ul><li>Requirements are to be reviewed by a colleague (Peer Review) </li></ul><ul><li>Onc...
Requirements - Benefits <ul><li>It is difficult for a Tester to spot every mistake or flaw in a complicated piece of work....
Test Plan – Why use this? <ul><li>Used to organise your testing </li></ul><ul><li>Usually organised according to subject <...
Test Plan – Proposed Changes <ul><li>To be organised at Top Level by release  </li></ul><ul><li>To be organised at second ...
Test Plan – Proposed Changes <ul><li>Each Test Case should be attached to the relevant Requirement in the ‘Requirements’ t...
Test Plan - Benefits <ul><li>Test Cases can be easily located by release and change request. </li></ul><ul><li>Test Case C...
Test Plan – Proposed Changes <ul><li>As part of the Peer Review process as previously discussed, the test cases should be ...
Test Lab – Why use this? <ul><li>The Test Lab tab is used to schedule and organise the tests to be perfomed </li></ul><ul>...
Test Lab – Proposed Changes <ul><li>A similar structure to the one used in the Test Plan tab </li></ul>The top level requi...
Test Lab – Proposed Changes <ul><li>Test Scheduling for the various release and change requests can be easily located </li...
Defects – Why use this? <ul><li>The Defects tab is used to track defects from their initiial discovery through to……. </li>...
Defects – Proposed Changes <ul><li>The release is displayed in the ‘Project’ field </li></ul><ul><li>The Component is disp...
Defects – Proposed Changes <ul><li>A public view will be created in the defects tab that can be selected by any user </li>...
Defects – Proposed Changes <ul><li>The following additional Mandatory fields have been configured: </li></ul><ul><li>‘ Ass...
Defects - Benefits <ul><li>The impact of any defects raised can be reported to Project Management. </li></ul><ul><li>Examp...
Defects - Benefits <ul><li>The impact of any defects raised can be reported to Project Management. </li></ul><ul><li>Examp...
Defects - Benefits <ul><li>The impact of any defects raised can be reported to Project Management. </li></ul><ul><li>Examp...
Test Director – Implementation <ul><li>Once agreement has been reached to increase the Test Director concurrent user licen...
Test Director – FAQ’s <ul><li>Won’t the Test Process will be slowed down? </li></ul><ul><li>Helps prevents the use of frag...
Test Director – Other considerations <ul><li>There are a number of subjects that have been kept outside of the scope of th...
Test Director – The End The End
Upcoming SlideShare
Loading in …5
×

Test director proposedimprovementsv0.4

1,000 views

Published on

Test Direc

Published in: Education, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,000
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Test director proposedimprovementsv0.4

  1. 1. Test Director – Proposed improvements within currently used project life cycle By Jason Dynes
  2. 2. Test Director – What is it used for? <ul><li>Simplifies and organises test management </li></ul><ul><li>Creates a framework and foundation for the Testing process </li></ul><ul><li>Organisation of the Testing Requirements </li></ul><ul><li>Scheduling and executing test sets </li></ul><ul><li>Collecting Test Results </li></ul><ul><li>A clear view of Test Coverage and Traceability </li></ul><ul><li>Tracking application defects </li></ul><ul><li>Provides Audit Trail </li></ul>
  3. 3. Test Director – How is it used? <ul><li>The Test Management Process involves four phases </li></ul><ul><li>REQUIREMENTS - Analyse your application and determine your testing requirements </li></ul><ul><li>TEST PLAN - Create a Test Plan based on your testing requirements </li></ul><ul><li>TEST LAB - Create Test Sets and Perform Test Runs </li></ul><ul><li>DEFECTS – Report defects detected and track how repairs are progressing </li></ul>Specify Requirements Plan Test Execute Tests Track Defects
  4. 4. Test Director – How is it used? <ul><li>4 separate system areas are provided for these phases </li></ul>Specify Requirements Plan Test Execute Tests Track Defects
  5. 5. Requirements – Why use this? <ul><li>Provides the foundation on which the entire testing process is based </li></ul><ul><li>By defining Requirements, you can plan and manage tests that are more focused on business needs. </li></ul><ul><li>Requirements are then linked to tests and defects to provide traceability </li></ul><ul><li>Improves the decision making process by improving the Test reporting ability </li></ul>
  6. 6. Requirements – Proposed Changes <ul><li>To use the ‘Requirements’ tab of Test Director to define Testing Requirements </li></ul><ul><li>To be structured by Change Request Number </li></ul><ul><li>Also attached to its assigned release </li></ul>The top level requirement denotes the Change Request Number e.g. CR 213 The second level and below details the actual testing requirements for that particular CR The ‘Product’ field is a lookup field denoting the release that it is associated with
  7. 7. Requirements - Benefits <ul><li>Any Testing Requirements that do not have associated Test cases can be identified prior to Test Execution preventing untested areas of the system </li></ul><ul><li>During Test Execution it will be possible to check which requirements have passed or failed tests to help make risk based decision making </li></ul>
  8. 8. Requirements – Proposed Changes <ul><li>Requirements are to be reviewed by a colleague (Peer Review) </li></ul><ul><li>Once satisfied, the colleague sets the ‘Reviewed’ column to ‘Reviewed’ </li></ul>The ‘Reviewed’ field is amended by the reviewer
  9. 9. Requirements - Benefits <ul><li>It is difficult for a Tester to spot every mistake or flaw in a complicated piece of work. </li></ul><ul><li>By showing this work to others increases the probability that weaknesses will be identified and with advice, these will be remedied producing better quality tests. </li></ul><ul><li>By doing this within the tool you will also have an audit of the person who reviewed the work. </li></ul>
  10. 10. Test Plan – Why use this? <ul><li>Used to organise your testing </li></ul><ul><li>Usually organised according to subject </li></ul><ul><li>Describes the set of tests you will implement in order to meet the quality requirements </li></ul>
  11. 11. Test Plan – Proposed Changes <ul><li>To be organised at Top Level by release </li></ul><ul><li>To be organised at second level by Change Request Number </li></ul>The top level requirement denotes the release that the CR is assigned to The second level denotes the Change Request Number e.g. CR 213 The third level and below details the actual testing requirements for that particular CR
  12. 12. Test Plan – Proposed Changes <ul><li>Each Test Case should be attached to the relevant Requirement in the ‘Requirements’ tab so that the Test Coverage Status (Passed, Failed, Not Run or Not Covered) is reflected in the requirements tab </li></ul>
  13. 13. Test Plan - Benefits <ul><li>Test Cases can be easily located by release and change request. </li></ul><ul><li>Test Case Coverage and Traceability is improved </li></ul><ul><li>Reporting functionality can be utilised. Example below </li></ul>
  14. 14. Test Plan – Proposed Changes <ul><li>As part of the Peer Review process as previously discussed, the test cases should be reviewed together with the associated testing requirements </li></ul><ul><li>Once the tests cases are considered acceptable by the reviewer then the ‘status’ column will be updated from ‘Design’ to ‘Ready’ </li></ul>
  15. 15. Test Lab – Why use this? <ul><li>The Test Lab tab is used to schedule and organise the tests to be perfomed </li></ul><ul><li>Once these tests have been scheduled they are also executed using this tab using the ‘Run’ button </li></ul>
  16. 16. Test Lab – Proposed Changes <ul><li>A similar structure to the one used in the Test Plan tab </li></ul>The top level requirement denotes the release that the CR is assigned to The second level denotes the Change Request Number e.g. CR 213
  17. 17. Test Lab – Proposed Changes <ul><li>Test Scheduling for the various release and change requests can be easily located </li></ul><ul><li>Also supports Test Reporting within Test Director – see example below </li></ul>
  18. 18. Defects – Why use this? <ul><li>The Defects tab is used to track defects from their initiial discovery through to……. </li></ul><ul><li>The investigation as to their cause </li></ul><ul><li>The solution </li></ul><ul><li>And the testing of the solution </li></ul>
  19. 19. Defects – Proposed Changes <ul><li>The release is displayed in the ‘Project’ field </li></ul><ul><li>The Component is displayed </li></ul><ul><li>The Change Request affected by the defect is displayed </li></ul>The ‘Project’ field denotes the release that the defect is assigned to The ‘Component’ field denotes the component affected by the problem The ‘CR No. impacted’ field denotes any CR that is impacted by the defect. The ‘System Environment’ defines in which environment the problem was detected in e.g. PROD, INT, UAT, PRS
  20. 20. Defects – Proposed Changes <ul><li>A public view will be created in the defects tab that can be selected by any user </li></ul><ul><li>Will provide the most relevant fields relating to a defect </li></ul><ul><li>Can be access using the ‘Favorite’ functionality </li></ul><ul><li>The fields displayed are detailed in the screenshot below </li></ul>
  21. 21. Defects – Proposed Changes <ul><li>The following additional Mandatory fields have been configured: </li></ul><ul><li>‘ Assigned To’, ‘Description’, ‘Project’, ‘Summary’, ‘Component’, and ‘System Environment’ </li></ul>
  22. 22. Defects - Benefits <ul><li>The impact of any defects raised can be reported to Project Management. </li></ul><ul><li>Example 1 - Graph shows the status of defects by Component </li></ul>
  23. 23. Defects - Benefits <ul><li>The impact of any defects raised can be reported to Project Management. </li></ul><ul><li>Example 2 - Graph shows the status of defects by Change Request </li></ul>
  24. 24. Defects - Benefits <ul><li>The impact of any defects raised can be reported to Project Management. </li></ul><ul><li>Example 3 - Graph shows the status of defects by Release </li></ul>
  25. 25. Test Director – Implementation <ul><li>Once agreement has been reached to increase the Test Director concurrent user license from the standard 5 users to an increased capacity of say 20-25 then the implementation could begin </li></ul><ul><li>Due to the high workload of the team I would suggest a phased approach </li></ul><ul><li>Prior to the implementation of each phase, the previous phase should be reviewed </li></ul><ul><li>If we are not satisfied with previous phase then we do not proceed with the next </li></ul>Time Defects Training Defects Requirements Test Plan Phase 1 Test Lab Phase 2 Phase 3 Test Lab Training Test Plan Training Requirements Training
  26. 26. Test Director – FAQ’s <ul><li>Won’t the Test Process will be slowed down? </li></ul><ul><li>Helps prevents the use of fragmented email conversations to clarify testing requirements and/or defects </li></ul><ul><li>A central repository for documentation so other team members can carry on work if necessary should they be out of the office unexpectedly </li></ul><ul><li>As Team members become more familar with the tool, the Test Framework provided will speed the process up. </li></ul><ul><li>Do we have time to implement this due to the disruption caused? </li></ul><ul><li>This is why a phased implementation is the best approach so that a review of past and present performance is analysed before we proceed with the next phase. </li></ul><ul><li>What real benefits will be gained? </li></ul><ul><li>Test Director provides a way of organising the teams so that the testing they perform is of a good quality </li></ul><ul><li>Any problems that are found are visible to the Project team </li></ul><ul><li>Better Test Status Reporting can be supplied to Project Management to aid a better risk based release decision to be made. </li></ul>
  27. 27. Test Director – Other considerations <ul><li>There are a number of subjects that have been kept outside of the scope of this presentation: </li></ul><ul><li>The use of Test Automation Tools such as Winrunner, Quick Test Pro and Loadrunner </li></ul><ul><li>The creation of a Regression Testing Suite and its storage within Test Director </li></ul><ul><li>The analysis and creation of the Test Requirements within the current project life cycle </li></ul><ul><li>The analysis and creation of the Test Conditions within the current project life cycle </li></ul><ul><li>Test Case Design Techniques </li></ul><ul><li>The documentation of defects. </li></ul>
  28. 28. Test Director – The End The End

×