Guys,

I hope this article useful for all,

Incident:
An incident is any significant, unplanned event that occurs during testing that requires subsequent investigation and/or correction. Incidents are raised when expected and actual test results differ.

Incidents and the test process
An incident occurs whenever an error, query or problem arises during the test process. There must be procedures in place to ensure accurate capture of all incidents. Incident recording begins as soon as testing is introduced into system's development life cycle. First incidents that will be raised therefore are against documentation as project proceeds; incidents will be raised against database designs, and eventually program code of system under test.

Incident logging
Incidents should be logged when someone other than author of product under test performs testing. When describing incident, diplomacy is required to avoid unnecessary conflicts between different teams involved in testing process (e.g. developers and testers). Typically, information logged on an incident will include:
•Name of tester(s), data/time of incident, Software under test ID
•Expected and actual results
•Any error messages
•Test environment
•Summary description
•Detailed description including anything deemed relevant to reproducing/fixing potential fault (and continuing with work)
•Scope
•Test case reference
•Severity (e.g. showstopper, unacceptable, survivable, trivial)
•Priority (e.g. fix immediately, fix by release date, fix in next release)
•Classification. Status (e.g. opened, fixed, inspected, retested, closed)
•Resolution code (what was done to fix fault)

Incidents must be graded to identify severity of incidents and improve quality of reporting information. Many companies use simple approach such as numeric scale of I to 4 or high, medium and low.

Note that incident priority is not the same as severity. Priority relates to how soon the fault will be fixed and is often classified as follows:
1. Fix immediately.
2.Fix before the software is released.
3.Fix in time for the following release.
4.No plan to fix.
It is quite possible to have a severity 1 priority 4 incident and vice versa although the majority of severity 1 and 2 faults are likely to be assigned a priority of 1 or 2 using the above scheme.

Tracking and analysis
Incidents should be tracked from inception through various stages to eventual close-out and resolution. There should be a central repository holding the details of all incidents.
For management information purposes it is important to record the history of each incident. There must be incident history logs raised at each stage whilst the incident is tracked through to resolution for trace ability and audit purposes. This will also allow ht formal documentation of the incidents (and the departments who own them) at a particular point in time.
Typically, entry and exit criteria take the form of the number of incidents outstanding by severity. For this reason it is imperative to have a corporate standard for the severity levels of incidents.
Incidents are often analyzed to monitor test process and to aid in test process improvement. It is often useful to look at sample of incidents and try to determine the root cause.

Thanks
V.Vadivelan

Thanks for the information.

About the Incident management, Before start working on it, we should know what is Incident Management System. I have given the following details about the IMS.

All organizations experience incidents that either impact or threaten to impact the normal running of the business. As businesses have become increasingly dependent upon their IT services, the need to react quickly and effectively to any incidents that adversely affect IT services or infrastructure has become paramount.

Incident management is a critical process that provides organizations with the ability to first detect incidents and then to target the correct support resources in order to resolve the incidents as quickly as possible. The process also provides management with accurate information on the incidents impacting the organization, so that they can identify the required support resources and plan for their provision.

By utilizing the incident management process, organizations can ensure that their support resources are focusing on the issues that have the greatest urgency and potentially the greatest impact on the business. Without the control and management information provided by this process, organizations cannot be sure that their often-substantial investment in IT support is really meeting its objectives.

Key benefits of incident management are:

• Timely resolution of incidents, resulting in minimized business impact.

• Improved utilization of support resources.

• Better understanding of the impact of incidents on SLA targets, allowing improved prioritization.

• Accurate information on the incidents that are occurring.

• Elimination of "lost" incidents and service requests.

• Increased availability of management information.

The Above informations from theMicrosoft Incident Management system. Good one to understand the concept of IMS.


thanks

__________________
Karpagarajan. R
Necessity is the mother of invention