Internal processes.

While coding is performed on the application needing to be tested, the ICOA team Business Analysts create scenarios to test against the software.

The Business Analysts and Astea Analysts test the software with the scenarios as well as with standard tests after the software is received.

..... A defect is discovered, either by the Analysts, or by an end user, and .....the individual creates a Remedy Ticket to detail the issue. 

Key fields are "Detail", wherein the Analyst/user gives a synopsis of the issue and its scope. This is currently the "Comments" field in the defect report sheet.

Another key field is the Call Log, where all additional comments, including path to recreate the error, are logged for tracking purposes.

.....The Test Coordinator logs the incident for tracking and driving .....purposes, and checks for three articles within the Call Log area of the case. .....These three elements are tracked in fields noted on the Remedy Ticket .....Process Documentation.

The first element is the Business Analyst Sign-off. This is a single line indication that the Business Analyst has reviewed and approved the case.

The second element is the Astea Sign-off. This is a single line indication that the Astea representative on site has reviewed and approved the case.

The Astea analyst, and the BA analyst are responsible for ensuring that the description of the issue is complete in all respects, and the Test Coordinator verifies that all necessary information has been obtained before continuing through the process. (Sign-offs, re-creation path, et cetera).

The Test Coordinator also verifies that a Severity has been set for this issue, which is the third and final element. If it has not been previously agreed to, the Test Coordinator will go to the Business Architect for a Severity Assignment.

.....

This is accomplished, as above, by changing the toggle button "Request Type" from Test Coordinator to either Astea or Internal Development.

Note that if the issue is going to the Internal Development Team, the Astea Sign-off is no longer a required element, leaving Business Analyst Sign-off and Severity Assignment as the only required elements. 

The Development leads run queries, with "Request Type" set to the appropriate field, to identify when new tickets have been assigned, and to track existing issues pending action or in action. 

Email notification is also initiated by the system automatically when a case has been specifically assigned to an individual.

.....Once the defect is verified, if Astea, an Astea tracking number is input .....into the Vendor Call Number field.

If the defect cannot be recreated, the Astea representative or the Internal Developer contacts the creator of the Remedy Ticket (Business Analyst) for further information, or reassigns the ticket to the appropriate Analyst.

.....

"WIP" - Work in Progress - Issue is in development with an ETA.

"Hold" - Pending action - Used when the development has been delayed, interrupted, or when the process is waiting for an event (like a clock roll for testing or the like).

"New" - just assigned to development and not yet acknowledged

"Open" - acknowledged but not acted upon yet.

Once assigned to a developer, an ETA for the patch is reported in the "ETR" field. Status set to WIP.

If something interrupts the progress of the fix after it has moved to the "WIP" status, then the case is changed to "hold" and appropriate reason is documented in the case.

.....

.....The Remedy Case is reassigned to the Business Analyst who reported .....the issue by changing the "Owner" (See process documentation). Request .....Type is set to "Retest".

Patch is tested against the original defect by the Business Analyst. 

.....If the issue was resolved, the case is closed with appropriate comments. 

At a future point, the case, rather than being closed after a successful patch, will be placed into a "Staging" request type for implementation and regression testing.

See Regression Testing Process when this is an active process.

Test Coordinator tracks the case and reports necessary elements about the successful fix.

.....

It is not necessary to include the Test Coordinator in this step, as the Test Coordinator keeps daily tracking on the case, and will thereby be informed of the case status.

A new case is NOT created in Remedy as per the current procedure, because all generations of the case can be reported in the same Log book.

Process continues to cycle until the issue has been resolved.