ICOA Defect Tracking Procedure.

How it was done- 
 

While coding is performed on the application to be tested, the ICOA team creates business scenarios to test against the software. 

ICOA performs tests, both scenario and standard testing procedures, after software is received. 

If it passes tests, it is released as expected. 

If a bug is detected, it is detailed on the "Test Reporting Form" 

Once a bug is found: 

A control number is assigned using tester's initials and the issue number. 

A summary of how to reproduce the defect is placed in the appropriate field on the form along with the following information: 

"Path" -- Shows the shortcut path where the defect can be recreated.

"Severity" -- Shows the impact of the defect. 1 = Cannot operate without the fix. 2 = The defect has a serious impact on operations. 3 = The defect inhibits but does not prevent operation. 4 = The defect has no immediate impact (Application Enhancements go here).

"Software Version" -- Shows which release of the software was being tested.

"Module" -- Which Software Module was being tested.

"Environment" -- Which server the defect appears in or which environment the test was run on. 

"Functional Area" -- Which business area is affected by this defect (i.e. Business, Invoice and Rev-Rec, Operations, Finance, Service et cetera). 

A summary of the of the issue including documents that demonstrate the results of the bug (report print-outs for instance). They are faxed to Astea later in the procedure in order to communicate hand-written comments that designate problem areas and notes on the example documents. 

The Test Reporting Form is filled in electronically by the tester and then Emailed to the Test Team Metric Coordinator. Information on this form is used to populate fields within the Defect Control Sheet and the Test Reporting Form is archived in the shared network folder and in a hard copy file catalog, once the Astea Signoff has been completed. 

Note that this applies only if the defect is not an internal issue. Issues involving "Jetforms" and other internally coded changes follow the same process but without the Astea Sign-off. The defect is reported to an internal Business Analyst where a severity is assigned, then it is assigned to a coder, and patching and retesting is accomplished per the same process.

The bug report is physically ported to the Business Analyst in hard copy, with attached documentation. 

An Astea Representative checks verbiage to ensure the bug is well defined and can be recreated in the method documented. 

If there's not enough documentation, the Business Analyst contacts the business Analyst who tested the issue in order to gather further information, and then an amended report is submitted usually with Astea sign-off complete. 

The Business Analyst assigns Severity to the case. 

The Astea Representative signs off on the report, indicating that it is complete and ready to be sent to Astea. 

After the signoff, it is returned to the Metric Coordinator to be forwarded to Astea, and the Defect Control Document is updated to show the current status. 

The Defect Report and the attached documentation is forwarded to Astea for assessment, reproducing, and repair of the defect. 

Astea assigns an "S" control number and a "K" control number for internal Astea tracking. 

Astea forwards S and K numbers back to the Storage Tek Metric Coordinator for inclusion within the Defect Control Sheet. 

The bug is assigned to an internal analyst so that they can recreate the error. 

Once re-creation happens, a fix is planned and an internal programmer is assigned. 

Until an internal programmer is assigned and working on the correction to the code, an ETA for the patch is not created. When the programmer is actively working on the defect, the Defect Control Sheet is updated to show a "WIP" (Work In Progress) status and an ETA is provided by Astea. 

Once coding is complete, a "Patch" form is completed and notification is sent to the Test Team Metric Coordinator, and the Business Analyst. 

Business Analyst assigns a tester for the retest of the scenario that identified the defect against the new code. 

If the error cannot be recreated by Astea, the defect and documentation are returned to the Metric Coordinator and to the Astea Representative for assignment to the original business analyst. 

If the business analyst verifies that it is a valid defect from a valid business scenario test, further documentation is produced and it recycles back through the above detailed process, starting again with the achievement of the Astea Sign-off. 

Before it cycles back through to Astea again to be resolved, the original instance of the defect in the Defect Control Sheet must be closed, and a new one opened with (a) after the original tracking number per standard double entry book keeping so that the retest can be tracked in the reporting process. 

If the defect cannot be recreated by the tester, then it is closed and appropriate comments are appended to the Defect Report Form. The Defect Control Sheet is changed to reflect the closed status on the issue, and is resorted for reporting purposes. 

If the test is found to not be a valid test, it is retested under valid parameters as detailed above. 

Re-test procedure. 

The patch is sent to the Metric Coordinator who assigns a tester after consulting the Test Lead for availability. If conditions require a delay until the retest can be accomplished it remains in a "hold" status until conditions are created to allow the retest to occur (i.e. time rolls and changes). Changes in status are updated within the Defect Control Sheet. 

Testing determines pass or fail for the patch to fix the documented defect. 

If passed, the defect is closed by updating the Defect Control Sheet. The Defect Form is updated with a comment line and any additional comments are then archived to the network drive. 

The Defect Control Sheet is resorted for reporting purposes. 

The new, corrected code is sent to the client for implementation or for user acceptance testing. 

If failed, the defect resurrects under a new control number in the Defect Control Sheet as follows: 

The original defect is closed with a "failed" status, and the new defect is named with an extra character, a/b which represents the number of times that this defect has failed retesting. Xbc09 becomes Xbc09a et cetera. 

Retest failure information is appended to the initial report and Astea is notified of the failure. It then follows through the development path until successfully fixed. 

Note that all updates in the life cycle of the documentation are tracked in the Defect Control Sheet and appended to the Test Reporting Form. Severity level is tracked, ETA changes, status changes are updated on daily conference calls, along with changes or updates to Astea tracking numbers. 

If the severity is changed, the old defect must be closed in the defect reporting form, and a new one must be created for double entry book keeping purposes. 

So How Will We Do It