Test Director Ppt Training

7,061 views

Published on

Intralinks_testdirector

Published in: Technology, Business
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
7,061
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
222
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Test Director Ppt Training

  1. 1. Test Director 7.6 – training guide Prepared by: Vithal Padki Date: 4/10/03
  2. 2. Audience <ul><li>The regular members of the Intralinks QA team </li></ul><ul><li>Any other employees of Intralinks belonging to other departments participating in the IntraLinks System Testing and Validation </li></ul>
  3. 3. Scope of this Training <ul><li>Overview of Test Director (TD) components being used by Intralinks QA (Non Admin) </li></ul><ul><li>Indicate features of Test Director not being used by IntraLinks QA </li></ul><ul><li>Quick Overview of each component of TD in relation to IntraLinks QA SOPs </li></ul>
  4. 4. TD – Access <ul><li>Web Based application (works only with Microsoft Internet Explorer) </li></ul><ul><li>Access restricted to IL internal network </li></ul><ul><li>Access available via VPN </li></ul><ul><li>User accounts and levels of usage can be configured (Admin Functions) </li></ul><ul><li>Access configurable by Projects </li></ul><ul><li>Users can set their own passwords </li></ul>
  5. 5. TD – Overview outlined by application TAB layout <ul><li>Requirements – Track requirements coverage </li></ul><ul><li>Test Plan – Test Script writing and Management </li></ul><ul><li>Test Lab – Script Execution </li></ul><ul><li>Defects – Defect management </li></ul>
  6. 6. Requirements <ul><li>This feature is an addition to the previous version of Test director (6.0) which is designed to aid the requirements trace ability and script coverage. </li></ul><ul><li>We at Intralinks do not use this feature because requirements are defined in the form of properly numbered use cases and scripts are built around these use cases following the same numbering system. </li></ul><ul><li>This system was adopted to automatically incorporate the trace-ability into the regular process without making extra effort to maintain trace-ability. </li></ul><ul><li>In addition to this we maintain the trace-ability matrix which follows the same numbering system across the various departments involved in the development of the Intralinks applications. </li></ul>
  7. 7. Test Plan <ul><li>This section has the following sub sections: </li></ul><ul><li>Test Plan Tree/Directory structure </li></ul><ul><li>For each folder on the test tree - Description/ Attachments </li></ul><ul><li>For each test case associated with the use case folder- Details/ Design Steps/ Test Script/ Attachments/ Requirements coverage. </li></ul>
  8. 8. Test Plan – Tree/Directory structure <ul><li>Test Tree is based on the hierarchy: Project/ Sub-project/ Use cases/ Scripts </li></ul><ul><li>This is usually created by the administrator at the beginning of the project </li></ul><ul><li>The Requirements Trace-ability is built into this tree – every use case defining the requirement has an associated Folder </li></ul><ul><li>QA team members add tests for each use case under the respective folders </li></ul><ul><li>Specific numbering convention is followed as outlined in the SOP </li></ul>
  9. 9. Test Plan – Description/Attachments for each folder <ul><li>This is a sub-tab related to each folder on the tree </li></ul><ul><li>All the details of the use case are outlined </li></ul><ul><li>Use case document may be attached here for reference </li></ul><ul><li>Baseline data required for the associated test script is also defined in this section (defined as per certain conventions outlined in the SOP) </li></ul><ul><li>Data description may also be in the form of an attachment (excel spreadsheet) </li></ul>
  10. 10. Test Lab – Execution Grid <ul><li>This is the central place from which all the scripts related to a test set are executed. </li></ul><ul><li>More tests can be selected to be added to the test set by using the “select tests” command. </li></ul><ul><li>Tests can be run by selecting a test script and using the “Run Tests” command </li></ul><ul><li>Every test can have multiple runs. </li></ul>
  11. 11. Defects <ul><li>This is the most important and critical part of Test Director from the QA perspective. </li></ul><ul><li>This is a central repository of all the issues identified across the various projects and environments </li></ul><ul><li>The defects can be sorted, filtered searched or identified by any of its attributes – Defect ID, Status, Detected by, assigned to , priority, project , environment etc. </li></ul>
  12. 12. Defects – Add Defects <ul><li>Most frequently used component of TD </li></ul><ul><li>The attributes that define a defect and have to be carefully entered by the QA tester who logs the defect into the system </li></ul><ul><li>Fields marked red are are mandatory fields </li></ul><ul><li>Some of the fields get filled automatically but can be changed if required. </li></ul><ul><li>A detailed description of the defect including steps to reproduce the defect is required to be entered </li></ul>
  13. 13. Defects – Management <ul><li>Tester logs the defect assigns to the QA Lead in charge of execution, marked new and not- prioritized (mandatory fields are also completed) </li></ul><ul><li>PM, QA and Dev teams have daily defect review meetings to prioritize and assign the defects to appropriate developers. </li></ul><ul><li>Some defects may get rejected if they are out of the scope of requirements </li></ul><ul><li>Duplicate defects and defects logged due to testing errors are closed </li></ul>
  14. 14. Defects – Management (Continued) <ul><li>Developers review/fix the defect and mark the planned closing in version attribute and reassign to the QA lead </li></ul><ul><li>The release notes for every build are based on the planned closing in version attribute </li></ul><ul><li>Based on the release notes the QA lead reassigns the defects to the testers for re-validation </li></ul>
  15. 15. Defects – Management (Continued) <ul><li>This is done for every build/release at the beginning of QA cycle and for every patch in between major builds </li></ul><ul><li>QA tester revalidates and closes the defect if fixed or Re-opens the defect and assigns to QA lead to pass through the same process as a new defect </li></ul><ul><li>Comments are entered at each step of the defect cycle </li></ul><ul><li>Defect status and assignment changes are logged under the description/History view </li></ul>

×