Incident is a common name given to the term defect , bug , problem , fault or failure. Simply any deviation of the actual results from the expected results or any questionable behavior of the system is named as incident.
Some important things to consider about incidents :
- There are various causes of incidents like mis-configuration or failure of the test environment,corrupted test data, bad tests, invalid expected results and tester mistakes.
- Incident is about the questionable behavior of the system , all the incidents may not be a true defect. We make a record of all the incidents what we observed so that we can follow up on it and take necessary actions if required.
- Incidents can be logged along all the testing phases , development and reviews.
- Most commonly defects are reported against the code or the system itself , but defects can be reported against requirements and design specifications, user and operator guides and tests.
- Incident reports are used to provide programmers, managers and others with detailed information about the behavior observed and the defect. It is to support the analysis of trends in aggregate defect data, either for understanding more about a particular set of problems or tests or for understanding and reporting the overall level of system quality.
- While logging a Incident we can give as much information as we can. Incidents may be defects or any mis-behave of the system so the details may help the management and development teams in finding out the issues.
- IEEE 829 - Incident Report Template contains :
Test incident report identifier Summary Incident description (inputs, expected results, actual results, anomalies, date and time, procedure step, environment, attempts to repeat, testers and observers) Impact
- Incident report life cycle :
Every Incident goes through a life cycle. All incident reports move through a series of clearly identified states after being reported. After an incident is reported, a peer tester or test manager reviews the report. If successful in the review, the incident report becomes opened, so now the project team must decide whether or not to repair the defect. If the defect is to be repaired, a programmer is assigned to repair it. Once the programmer believes the repairs are complete, the incident report returns to the tester for confirmation testing. If the confirmation test fails, the incident report is re-opened and then re-assigned. Once the tester confirms a good repair, the incident report is closed. No further work remains to be done. In any state other than rejected, deferred or closed, further work is required on the incident prior to the end of this project. In a rejected, deferred or closed state, the incident report will not be assigned to an owner.
- Standard Incident Procedures :
->Identification - detect or report the incident
->Registration - the incident is registered
->Categorization - the incident is categorized by priority, severity ,SLA etc.
->Prioritization - the incident is prioritized for better utilization of the resources and the Support Staff time
->Diagnosis - reveal the full symptom of the incident in details
->Escalation - should the Support Staff need support from other organizational units
->Investigation and diagnosis - if no existing solution from the past could be found the incident is investigated and root cause found
->Resolution and recovery - once the solution is found the incident is resolved
->Incident closure - this is the last phase where Incidents are closed
Some important things to consider about incidents :
- There are various causes of incidents like mis-configuration or failure of the test environment,corrupted test data, bad tests, invalid expected results and tester mistakes.
- Incident is about the questionable behavior of the system , all the incidents may not be a true defect. We make a record of all the incidents what we observed so that we can follow up on it and take necessary actions if required.
- Incidents can be logged along all the testing phases , development and reviews.
- Most commonly defects are reported against the code or the system itself , but defects can be reported against requirements and design specifications, user and operator guides and tests.
- Incident reports are used to provide programmers, managers and others with detailed information about the behavior observed and the defect. It is to support the analysis of trends in aggregate defect data, either for understanding more about a particular set of problems or tests or for understanding and reporting the overall level of system quality.
- While logging a Incident we can give as much information as we can. Incidents may be defects or any mis-behave of the system so the details may help the management and development teams in finding out the issues.
- IEEE 829 - Incident Report Template contains :
Test incident report identifier Summary Incident description (inputs, expected results, actual results, anomalies, date and time, procedure step, environment, attempts to repeat, testers and observers) Impact
- Incident report life cycle :
Every Incident goes through a life cycle. All incident reports move through a series of clearly identified states after being reported. After an incident is reported, a peer tester or test manager reviews the report. If successful in the review, the incident report becomes opened, so now the project team must decide whether or not to repair the defect. If the defect is to be repaired, a programmer is assigned to repair it. Once the programmer believes the repairs are complete, the incident report returns to the tester for confirmation testing. If the confirmation test fails, the incident report is re-opened and then re-assigned. Once the tester confirms a good repair, the incident report is closed. No further work remains to be done. In any state other than rejected, deferred or closed, further work is required on the incident prior to the end of this project. In a rejected, deferred or closed state, the incident report will not be assigned to an owner.
- Standard Incident Procedures :
->Identification - detect or report the incident
->Registration - the incident is registered
->Categorization - the incident is categorized by priority, severity ,SLA etc.
->Prioritization - the incident is prioritized for better utilization of the resources and the Support Staff time
->Diagnosis - reveal the full symptom of the incident in details
->Escalation - should the Support Staff need support from other organizational units
->Investigation and diagnosis - if no existing solution from the past could be found the incident is investigated and root cause found
->Resolution and recovery - once the solution is found the incident is resolved
->Incident closure - this is the last phase where Incidents are closed
No comments:
Post a Comment