How Software Testing Managers Tackle the Incidents during the Development Life Cycle

Posted in: ISTQB Advanced Test Managers Exam Preparation

How Software Testing Managers Tackle the Incidents during the Development Life Cycle

The activity of managing unexpected events that are encountered during testing is called incident management. It is formally an activity in the configuration management process, but being emphasized here because it is strongly connected to software testing.

We can say that, Incident is a defect or an outcome of an action during testing, wherein the actual result differs from the expected result & such an event requires greater study & investigation.

What are the prime causes of Incidents?
When a product is being developed, tested, deployed, and maintained, incidents are bound to come up. It is human to make mistakes so defects get introduced during development, requirements change over time, and the environment in which the product is deployed can evolve as well.

Testing is the obvious source of incidents, since the idea of software testing is to expose things that compel us say : “Oops – what was that?” Generally Incidents are detected in the form of defects

in static testing, and typically in the form of failures in dynamic testing. An incident could be that the actual result is different from the expected result when a test case is executed.

How do we recognize an incident?
Upon recognition of an incident, software testing engineers initiate an incident report. All incidents must be reported meticulously so that they can be investigated, recreated if needed, and monitored.

When an incident is initially recognized, set of supporting information that need be included in the incident report can contain:

# Identification of the incident, including unique number, heading, trigger event, proposed fix, if possible, and documentation (e.g., screen dumps)

# Identification of the environment, including hardware, software, vendor, item in which the incident was seen, and fix description, if any

# Identification of the people involved, including originator and investigator

# Related time information, for example, system time, CPU time, and wall time as appropriate

How do we classify an incident?
The information for classification could contain:

# Project activity: What were you doing when the incident was recognized?

# Project phase: What phase was the project in when the incident was recognized?

# Symptoms: What did you see when you recognized the incident? It could also include information about suspected cause, repeatability, and product status.

What type of information related to the Impact of an incident must be a part of the incident report?
Impact related information could contain:

# Its Severity

# Impact on project schedule

# Impact on the project cost

Who as an individual can raise an incident?
Incidents can be raised by all stakeholders within the organization or by customers. It is important that all incidents are handled via a defined path and are processed in a controlled way.

How do we investigate Incidents?
The investigation is performed based on the information provided in the incident report. Formally this is not testing but configuration management.

The investigation is about finding out what is wrong, if anything, and what should happen next. Many things could be wrong, for example, in the context of testing, these could be:

# A wrong wording, caught during a review of a document.

# A coding defect found during a walk-through of a piece of source code.

# A failure found in the integration test.

# A wish to expand or enhance the finished product, arising when the product is in acceptance testing

# A change required in the code because of the upgrade to a new version of the middleware supporting the system (e.g. a new version of MS Access, which in certain places is not backward compatible)

If something is certainly wrong the investigation must try to find out what the impact is and what the cost of making the necessary corrections is. It must also be considered what the cost of not making the corrections is. It is not always a simple matter to perform such an analysis, but it must be done before an informed decision about what to do can be made.

Possible actions can be:

# Nothing – No failure after all or the failure is too insignificant

# Nothing right now – Changes are postponed

# Changes must be implemented immediately where necessary

The supporting data for the other life cycle phases include primarily

# Identification of the people involved in the investigation, at least those responsible for any decisions made

# Related time information

The information for classification can contain:

# Actual cause – Where have we pinpointed the incident to come from a high level?

# Source – In which work products or product components must changes be made?

# Type – What type of incident are we dealing with?

What actions do we take when Incident takes place?
If any action is to be taken it will be in the form of one or more changes, since one incident may trigger changes in more places.

Specific change requests should be produced by the software testing engineers for all the objects to be changed. This makes it easier to follow-up on the progress of a change through its life cycle: open, implemented, and approved.

When testing comes into picture while handling Incidents?
The software testing comes into the incident handling at the time of approval. Re-testing must be done to ensure that corrections have been made correctly, and regression testing must be performed to ensure that the correction has had no adverse effects on the areas that were working before the correction.

How do we dispose of the Incidents?
In case an action has already been initiated, we can dispose of the incident only when approval to all the change requests is granted. Here we can close the incident report only when details are furnished about the methodology of implementing the corrective measures after due approval.

How do we use the information derived from the Incident reports?
Useful information that can be extracted from incident reports is essential for a number of people in the organization, including test management, project management, project participants, process improvement people, and organizational management.

The primary areas for which incident report information can be used are:

# Estimation and progress

# Incident distribution

# Effectiveness of quality assurance activities

# Ideas for process improvement

Some of the direct measurements we can extract from the incident reports at any given time are:

# Total number of incidents

# The number of open incidents

# The number of closed incidents

# The time it took to close each incident report

# Which changes have been made since the last release

What is the methodology of counting Incidents?
The incidents can be counted for specific classifications, and this is where life gets so much easier if a defined classification scheme has been used.

We can count the number of:
# Incidents found during review of the requirements

# Incidents found during component testing

# Incidents where the source was the specification

# Incidents where the type was a data problem

For estimation and progress purposes we can compare the actual time it took to close an incident to our estimate and get wiser and better at estimating next time. We can also look at the development in open and closed incidents over time and use that to estimate when the testing can be stopped.

How do we communicate Incidents?
Careful incident reporting in written incident reports using an incident management system facilitates objective communication about incidents and defects. However, should not be a substitute for the verbal communication, which must not be eliminated at all.

Communication about incidents is a bit difficult task. The first and most important thing for software testing engineers and developers is to keep in mind that developers and others do not make defects on purpose to annoy us, or to tease us, or even to keep us busy. The next and equally important thing is that software testing engineers and others do not report incidents to tease and punish but as their contribution to a high-quality product.

Another aspect of incident communication among software testing engineers & others is concerned with what should be corrected and when.

Full Study Material for ISTQB Advanced Test Manager Exam

0 0 votes

Article Rating