![3 Steps to Smart Delegation [Time Management Series]](https://rogeriodasilva.com/wp-content/uploads/2020/12/Three-steps-to-Smart-delegation-and-why-everyone-should-be-delegating.jpg)
Software Testing – Why is Testing Necessary? [Part 2]
In response to the last post, Why is Testing Necessary? I understand that was a vague description of why software testing is necessary and reasons. To be honest, there is no straight answer, or better said, not a small answer.
Projects can be simple as well as complex, maybe one approach or process is not susceptible to another project.
As long as we as a tester keep asking why investigating and acting, the final result can be a lot better than not testing at all, or even testing inappropriately.
There are many names and technics, but one approach I like most, personally, is to investigate the root cause of a defect. So, the question this time is…
- What can be the root cause of a defect and its effect?
- How can we, as a tester, help prevent it from happening?
Root cause analysis is critical to identify and evaluate the defect in a container and preventive action, which will in fact contribute to preventing future defect recurrence.
Having an effective process is critical as if the cause of the defect is not identified, it is likely the impact on quality will repeat several times.
Step back and analyze the whole picture as the variables can be dimensional, process-oriented, visual, Cosmetic, material properties and environmental.
Anything related to the deadlines, the testing process and knowledge of what it has been testing, the visual aspect and quality of the end product, the final desired effect of a product or even things like environmental conditions such as temperature, pressure and humidity can affect the desired result.
Soon as a defect > bug is found time is money therefore a planning action is required, analyze what you can and go back to basics, verify the Inputs > Process > Environment.
- Identify the time and where the issue has occurred.
- Let people involved know of the issue.
- Gather all the necessary evidence that can be useful for the developers’ team.
- Is there any patch or quick fix to contain until the full investigation and fix can be done?
- Identify the right person for each task.
Once the Impact is assessed and identified, investigate to find the trigger of the cause of the defect and its origin that can be traceable back to the requirements, design, and bad code fix.
Then categorise to help on how it’s going to be corrected, the values entered to fix it can be a feature, algorithm, initialization, error handling etc…
The reason itself, alone, is not the solution, but by blending with the categorised defect it is possible to give more meaning to it, for example – the wrong algorithm.
Root Causes, Defect Type and Preventive Action
| Logical Error | Root Cause | Prevention |
| The logic behind the functionality of the application. |
|
|
| Requirements | Root Cause | Prevention |
| The error, in this case, is the misunderstanding of the requirements or inadequate definition of the requirements. |
|
|
| Design | Root Cause | Prevention |
| The design error is the inadequate design or the technical inadequacy in design. |
|
|
| Graphical Error | Root Cause | Prevention |
| Is the error in screens, reports layout and in designs? |
|
|
| Documentation | Root Cause | Prevention |
| Involves the typographical error in the documentation and in the code. Including spelling, mistyped words and the code itself. |
|
|
References:
What it says in ISTQB
Full Training
- ISTQB Foundation Level 2011 Training 1st Month Free*.
- ISTQB Foundation Leve 2018 Training – Coming Soon | YouTube Preview
