The document proposes improvements to the use of Test Director, a test management tool, within an organization's project lifecycle. It outlines how Test Director could be used to organize testing requirements, test plans, test execution, and defect tracking. A phased implementation approach is suggested to introduce these changes which would provide benefits like improved traceability, coverage reporting, and risk-based decision making.

1. Test Director – Proposed improvements within currently used project life cycle By Jason Dynes

2. Test Director – What is it used for? Simplifies and organises test management Creates a framework and foundation for the Testing process Organisation of the Testing Requirements Scheduling and executing test sets Collecting Test Results A clear view of Test Coverage and Traceability Tracking application defects Provides Audit Trail

3. Test Director – How is it used? The Test Management Process involves four phases REQUIREMENTS - Analyse your application and determine your testing requirements TEST PLAN - Create a Test Plan based on your testing requirements TEST LAB - Create Test Sets and Perform Test Runs DEFECTS – Report defects detected and track how repairs are progressing Specify Requirements Plan Test Execute Tests Track Defects

4. Test Director – How is it used? 4 separate system areas are provided for these phases Specify Requirements Plan Test Execute Tests Track Defects

5. Requirements – Why use this? Provides the foundation on which the entire testing process is based By defining Requirements, you can plan and manage tests that are more focused on business needs. Requirements are then linked to tests and defects to provide traceability Improves the decision making process by improving the Test reporting ability

6. Requirements – Proposed Changes To use the ‘Requirements’ tab of Test Director to define Testing Requirements To be structured by Change Request Number Also attached to its assigned release 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. Requirements - Benefits Any Testing Requirements that do not have associated Test cases can be identified prior to Test Execution preventing untested areas of the system During Test Execution it will be possible to check which requirements have passed or failed tests to help make risk based decision making

8. Requirements – Proposed Changes Requirements are to be reviewed by a colleague (Peer Review) Once satisfied, the colleague sets the ‘Reviewed’ column to ‘Reviewed’ The ‘Reviewed’ field is amended by the reviewer

9. Requirements - Benefits It is difficult for a Tester to spot every mistake or flaw in a complicated piece of work. 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. By doing this within the tool you will also have an audit of the person who reviewed the work.

10. Test Plan – Why use this? Used to organise your testing Usually organised according to subject Describes the set of tests you will implement in order to meet the quality requirements

11. Test Plan – Proposed Changes To be organised at Top Level by release To be organised at second level by Change Request Number 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. Test Plan – Proposed Changes 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

13. Test Plan - Benefits Test Cases can be easily located by release and change request. Test Case Coverage and Traceability is improved Reporting functionality can be utilised. Example below

14. Test Plan – Proposed Changes As part of the Peer Review process as previously discussed, the test cases should be reviewed together with the associated testing requirements Once the tests cases are considered acceptable by the reviewer then the ‘status’ column will be updated from ‘Design’ to ‘Ready’

15. Test Lab – Why use this? The Test Lab tab is used to schedule and organise the tests to be perfomed Once these tests have been scheduled they are also executed using this tab using the ‘Run’ button

16. Test Lab – Proposed Changes A similar structure to the one used in the Test Plan tab 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. Test Lab – Proposed Changes Test Scheduling for the various release and change requests can be easily located Also supports Test Reporting within Test Director – see example below

18. Defects – Why use this? The Defects tab is used to track defects from their initiial discovery through to……. The investigation as to their cause The solution And the testing of the solution

19. Defects – Proposed Changes The release is displayed in the ‘Project’ field The Component is displayed The Change Request affected by the defect is displayed 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. Defects – Proposed Changes A public view will be created in the defects tab that can be selected by any user Will provide the most relevant fields relating to a defect Can be access using the ‘Favorite’ functionality The fields displayed are detailed in the screenshot below

21. Defects – Proposed Changes The following additional Mandatory fields have been configured: ‘ Assigned To’, ‘Description’, ‘Project’, ‘Summary’, ‘Component’, and ‘System Environment’

22. Defects - Benefits The impact of any defects raised can be reported to Project Management. Example 1 - Graph shows the status of defects by Component

23. Defects - Benefits The impact of any defects raised can be reported to Project Management. Example 2 - Graph shows the status of defects by Change Request

24. Defects - Benefits The impact of any defects raised can be reported to Project Management. Example 3 - Graph shows the status of defects by Release

25. Test Director – Implementation 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 Due to the high workload of the team I would suggest a phased approach Prior to the implementation of each phase, the previous phase should be reviewed If we are not satisfied with previous phase then we do not proceed with the next Time Defects Training Defects Requirements Test Plan Phase 1 Test Lab Phase 2 Phase 3 Test Lab Training Test Plan Training Requirements Training

26. Test Director – FAQ’s Won’t the Test Process will be slowed down? Helps prevents the use of fragmented email conversations to clarify testing requirements and/or defects A central repository for documentation so other team members can carry on work if necessary should they be out of the office unexpectedly As Team members become more familar with the tool, the Test Framework provided will speed the process up. Do we have time to implement this due to the disruption caused? 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. What real benefits will be gained? Test Director provides a way of organising the teams so that the testing they perform is of a good quality Any problems that are found are visible to the Project team Better Test Status Reporting can be supplied to Project Management to aid a better risk based release decision to be made.

27. Test Director – Other considerations There are a number of subjects that have been kept outside of the scope of this presentation: The use of Test Automation Tools such as Winrunner, Quick Test Pro and Loadrunner The creation of a Regression Testing Suite and its storage within Test Director The analysis and creation of the Test Requirements within the current project life cycle The analysis and creation of the Test Conditions within the current project life cycle Test Case Design Techniques The documentation of defects.

28. Test Director – The End The End