SIR Process for Function & Function Integration Test

Reject SIR

NEW
REJECTED

OPEN
Identify SIR Analyze SIR DEFERRED
Defer SIR

COMPLETE

Fix SIR MIGRATING

Re-Test SIR
RE-OPEN
ASSIGNED

Re-Open SIR Close SIR

CLOSED
©2003 Accenture. All Rights Reserved.
 Identify SIR
• Problems found during the test execution are logged as SIRs in the FMG Change Request DB
by the test execution team. The executors of the test will be logging the SIRs in the database. If
there is difficulty getting access to the database, because of testing on a laptop for instance, use your
best judgement in how to document the SIR. Recording on paper for later input into the database, for
example, might be more efficient.
• Documenting the SIR
– Compose an “Incident Report” in the FMG Change Request DB
– Set the priority
• emergency = testing process is severely limited or stopped by the existence of the problem
• High = very complex problems that are not impeding progress, but require attention if the test case is to
pass the function test
• Medium = problems that are not impeding progress, but require attention if the test case is to pass the
function test
• Low = problems that do not need addressing prior to moving to the next testing phase.
– Set the Incident Type to “System Investigation Request”
– Set Detected In to “Function Test” or “Integration Test” (for FIT)
– Set Root Cause to the phase that introduced the problem
– Fill out the rest of the Origination section (other than the Remedy Tkt ID/Test ID)
– Set the Analysis Assigned To field to the appropriate cell lead and press the notify button
• The Status will be set to NEW and will be analyzed by the “Analysis Assigned To” person (cell lead)

©2003 Accenture. All Rights Reserved.

 Analyze the SIR
• The Cell Lead should periodically(daily) review the “NEW” and
“RE_OPENED” SIRs
• While reviewing the status of the SIR is “OPEN”
• Determine what to set the status to:
– Rejected: after analysis it is determined that no action is required (this should be
communicated back to the person logging the SIR) This status should be agreed to
by both the Cell Lead and the BA.
– Deferred: the application works according to spec (change request may be
necessary) This status should be agreed to by both the Cell Lead and the BA.
– Open: application does not function correctly with regards to defined requirements
and spec
• Verify Root Cause field is correct
• Fill out Complexity field
• Assign “Open” SIRs by filling in Implementation Assigned To field and
pressing Notify button. Status is changed to “ASSIGNED”

©2003 Accenture. All Rights Reserved.

 Fix SIR
• All fixes are done in the dvl environment
• After fix is coded and tested a signoff of the fix should be done
by the Cell Lead. This signoff is accomplished by reviewing the
fix and test results and updating the SIR status to
“MIGRATING”. ONLY THE CELL LEAD (SIR MANAGER)
SHOULD MARK THE STATUS AS MIGRATING.
• The Completion Date should be filled in.
• The Root Cause should be verified for correctness
• A request to migrate the fix into the testing environment should
then be made. (The migration form will be an online form in
Lotus Notes and will have the ability to cross-reference to the
SIR in question)

©2003 Accenture. All Rights Reserved.

 Re-Test SIR
• After the Migration has occurred the Migration Team updates the SIR
status to “COMPLETE”
• The fix will be re-tested in context of the Test Execution cycle that
identified the problem in the first place
• If the fix works, the execution team will update the status to CLOSED.
(this should be done in a timely manner, as we are measuring the
duration of time from identifying the SIR through Closing the SIR.)
• If the fix does not work, the execution team will update the SIR status
to “RE-OPENED”. The Analysis Assigned To field should be re-
verified and the Notify button should be used.

©2003 Accenture. All Rights Reserved.