Select Page

Software Testing – Why is Testing Necessary? [Part 2]

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 strait 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, investigate and act, the final result can be a lot better than not testing at all, or even test inappropriately.

There are many names and Technics, but one approach I like it must, personally, is 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, prevent it to happening?

Root cause analysis is critical to identify and evaluate the defect in a contain and preventive action, which will in fact contribute to prevent future defect’s 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 the whole picture as the variables can be dimensional, process oriented, visual, Cosmetic, material properties and environmental.

Anything related to the dead lines, 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 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, it’s origin that can be traceable back to the requirements, design, 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 it self, alone, is not the solution, but blending with the categorised defect it is possible to give more meaning to it, for example – wrong algorithm.

Root Causes, Defect Type and Preventive Action

Logical Error The logic behind the functionality of the application.
Root Cause

  • Lack of knowledge of the subject
  • Wrong Algorithm
  • Developer with low experience
  • New program language


  • Knowledge transfer and the learning curve before start the project is important and can be part of the project review meetings.
  • Make the most experienced resources available to train the less experienced ones. The risk should be tracked as part of the risk assessment management worksheet.
  • In occurrence of an introduction of a new programming language, should be advised well in advanced and appropriate training should be given.

Requirements The error in this case is the misunderstand of the requirements or inadequate definition of the requirements.
Root Cause

  • Having assumptions of the requirement.
  • Requirement is ambiguous.
  • Requirement specification is incorrect.
  • Inappropriate technique.
  • Reviewers have no enough time for preparation of reviewing the requirements.


  • Have a deeply discussion about the boundaries of the application and gradually move on as the project progress it.
  • Utilise the most of the business analysis and the professionals involved as you can.
  • Regular workshops, catch up or stand up meetings for clarity, common understanding of implicit and explicit requirements of all stakeholders involved, including test team.
  • Good communication with customers and users will help to understand and know the requirements.
  • A formal sign off from all stakeholder involved in the project is important prior start the design phase.

Design The design error is the inadequate design or the technical inadequacy in design.
Root Cause

  • Requirement is ambiguous.
  • Requirement have not clear message.
  • Inappropriate design tool.
  • Limited knowledge of system used.
  • Reviewers have inadequate participation time.


  • Have a discussion of the desired result and the boundaries of the application and it’s requirements. The design should be well documented and a sign off is important before start the coding/work.
  • A careful analysis of the appropriate tool should carried out before task begin.
  • Training on new tool should be carried out prior to start.
  • The design should follow the requirements and be reviewed by the test and quality team. Should be reviewed adequately following a check-list and signed off.

Graphical Error Is the error in screens, reports layout and in designs.
Root Cause

  • For web based, compatibility of browsers and it supports which business agreed.
  • Screen resolutions and system settings.
  • The limitations in terms of control of the system itself by the user/administrator.


  • Have a set of tests for different environments.
  • Most defects are similar across environments/platform neverless is important to test cross browser, kit, hardware, data.
  • Maintain a defect database of all the tests cases carried out and before starting up with the project.

Documentation Involves the typographical error in the documentation and in code. Including spelling, mistyped words and in the code itself.
Root Cause

  • Oversight
  • Mis-check review


  • Having a thorough check review of the documentation is fundamental before delivery the project.
  • A full customer review is a must to prevent any typographical error in documentation.



About The Author

Rogerio da Silva is a Brazilian who lives in the UK for a little over two decades. He is the owner of a test consulting and outsources services for software development. He likes to blog, write and create content that teaches others how to live a better life. Rogerio has two princesses and one powerful wife that help him with his work. He loves reading biographies of successful authors and dream builders because they inspire him to keep creating!

Leave a reply


Now available on amazon prime

eBook (Amazon)

The Testers Book - An Unconventional Way to Software Testing - Revised Edition

Paperback (