Consider the following when the problem management process is developed and implemented:
- May need to define the severity to use the resources more efficiently.
- May use an automated tool to improve efficiency.
- May require education for the technical team.
- Clearly define the scope of the problem management process.
- Do not get confused with project issues or risks.
- The problem management process is just to handle the technical problems discovered during the tests.
- Some organisations prefer the term ‘Defect Management’ for the process that handles problems arising from test and troubleshoot activities
A defect management process is required to interface with the testing activities. The activities are to record and manage all identified defects through to resolution.
Problem Management
Problem management is the process responsible for managing the lifecycle of all problems that happen or could happen during an IT room migration. The primary objectives of problem management are to prevent problems and resulting incidents from happening, to eliminate recurring incidents, and to minimize the impact of incidents that cannot be prevented.
Problem management includes the activities required to diagnose the root cause of incidents identified and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented in a appropriate manner.
Problem management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents over time. This will ensure effective communication when dealing with related incidents and problems.
Defect Definition
For the purpose of clarity, a defect is defined as “A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during test execution, may cause a failure of the component or system”.
Defect Management
As the interaction and complexity between data and system functionality increases so does the potential impact of a defect, and therefore the detail required in a defect report.
Cosmetic defects are the simplest to report and affect the system the least. They are simply instances where things look wrong. Spelling errors, screen anomalies – these are cosmetic defects. For an IT room migration project this type of defects are unlikely to occur.
Defects that are classified as minor are things that make the system harder to use (but there is a workaround). These are slightly vaguer since part of their effect might be subjective. This also makes it harder to describe what the actual problem is.
When a defect results in a loss of function, a major defect, reporting becomes a bit more complicated and the urgency to fix the defect is greater. These defects mean that a process / function is inoperable until they are fixed. Because of this, the defect report again becomes more complicated.
A defect that causes the system to crash or there is a loss of data can be the hardest to reproduce and therefore the hardest to adequately describe. If you experience this in testing, it is imperative to see if you can reproduce the problem, documenting all the steps taken along the way. On these occasions, it is also important to include the data used in causing the system to fail.
With regards to loss of data, anything that threatens the integrity of data must be fixed as quickly as possible. More than any other defect type, severe defects must be documented as thoroughly as possible.
Reporting Guidelines
The key to making a good report is providing the relevant team with as much information as necessary to reproduce the defect. This can be broken down into the following points:
- Give a brief description of the problem documenting what was expected and what actually happened.
- List the steps that are needed to reproduce the defect.
- Identify the individual items that are wrong.
- Supply all relevant information such as version, system component, environment and data used.
- Supply a copy of all relevant documentation (e.g. reports, screen shots) and actual data including copies of the expected results.
- Provide details of any related or duplicate defects
Remember that when you are reporting a defect, the more information you supply the easier it will be to determine what the problem is and fix it.
Simple defects can have a simple report, but the more complex the defect, the more information the support engineer is going to need.
As a general rule the detail of your report will increase based on:
- The impact of the defect (minor, major).
- The level and complexity of the process / function being tested.
- The complexity of reproducing the defect.
Defect Report
In order to be effective, a defect report must supply all necessary information to not only identify the problem but what is needed to fix it as well.
It is not enough to say that something is wrong. The defect report must also say what the system should be doing.
The report should be written in clear and concise steps, so that someone who has never seen the system can follow the steps and reproduce the problem. It should include information about the system, including the version, component, and what data was used.
The more concise and accurate the information provided the better the report and therefore the quicker the response and resolution.
Tasks
- Define and document the defect management process.
- Identify and install defect management tools.
- Educate project in defect management process and tools.
Hints and tips
- An experienced defect manager could be recruited to perform defect management. Familiarity with IT room migration is ideal, not 100% essential.
- Communication and generation of testing management information is fundamental to the company confidence and overall success. This must be designed into the defect management process.
Activity output
- Defect management process document
- Defect management report
About the Author
