Create a database (or databases) to track the test status of items that changed plus the items that used them.  This list is from the TestBed Project tracking databases.

Source Status Tracking

Track the status of the Project Items (programs, WFLs, etc. that are changed or are affected by changes):
1. For each 'To-be-Changed' Project Item, include:

• Name and title of the source
• Reason for the change (1 sentence description)
• Whether or not the source had been identified to the accepting team (e.g., Production Support)
• What 'AffectedBys' use this source (see next step)

2. For each AffectedBy Project Item, include:

• Name and title of the source
• Which changed items it uses
• Whether it was also changed for the project
• Ranking based on why it's on the list

3. For all Project Items, include:

• Type of source (e.g., batch program or driver module or web page)
• Risk if the item fails in production
• Whether it's changed, obsolete, or an AffectedBy
• Whether it's an updater or inquiry only
• Name of the business owner (e.g., for a report)
• What cycle it runs (e.g., Calc, Timesheet night)
• What subsystem and/or WFL where it runs
• Notes on how to test.
• Status (e.g., Coded, Reviewed, UnitTested, SystemTested)

Parallel Test Coverage Status Tracking

Track the objects that have been executed during parallel testing, related back to the Changed or AffectedBys:
1. Record the test run status for each object. Include data such as:

• Object (relates back to the changed or AffectedBy source)
• Object Run Status (e.g., completed, bypassed, aborted)
• Cycle (e.g., 06CALC18, 06EDIT23)
• Test run iteration for the cycle (e.g., 3rd run, 4th run)
• Date/Time the test object was run

• WFL where the object ran (especially for objects that run in multiple WFLs; you may have an object that ran fine in BPR but failed in RSR)
• Optional: Test or Baseline environment (if you are tracking baseline runs during parallel tests - useful to see if something ran in baseline but didn't run in test)
• Optional: Test Phase (e.g., System Test vs. User Acceptance Test)
• Notes or comments

2. Identify the general test run details. Include data such as:

• Cycle (e.g., 06CALC18, 06EDIT23)
• Test run iteration for the cycle (e.g., 3rd run, 4th run)
• Pay Period End date for the cycle
• Date the database was captured in production
• Date(s) the full test was run (some test runs may take more than a day to run)
• Start time of the test run
• End time of the test run
• Notes or comments

3. Record the file comparison results. Include data such as:

• File name
• Object associated with the file
• WFL associated with the file
• Comparison Result (e.g., FilesAbsent, Match, NotMatched, AbsentInTest, AbsentInBaseline)
• Cycle (e.g., 06CALC18, 06EDIT23)
• Test run iteration for the cycle (e.g., 3rd run, 4th run)
• Explanation of any differences
• Date the comparison was run
• Notes or comments

Other Test Coverage Status Tracking

For non-parallel tests, you may want to track similar data, or just note the tests in the general status tracking database.  If there are multiple tests for each Project Item, map the tests to the Project Items and track the status of the tests.

Fault Tracking

Failures should be tracked in a separate issue tracking system.  Track the issues as they arise and relate them to a source.  Follow the issue through to resolution and retest.  Include:

• Summary:
• Status:
• Disposition:    
• Type:        
• Priority:    
• RelatedTo:            
• Entered by:        
• Date Entered:      
• Found by:    
• Date Found:   
• Description:
• Steps to Reproduce:
• Workaround
• Fix info (Source fixed and how fixed, when fixed)
• Attachments: