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 ErrorRoot CausePrevention
The logic behind the functionality of the application.
  • Lack of knowledge of the subject.
  • Wrong Algorithm.
  • Developer with low experience.
  • New program language.
  • Knowledge transfer and the learning curve before starting the project are 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 the occurrence of an introduction of a new programming language, should be advised well in advance and appropriate training should be given.
RequirementsRoot CausePrevention
The error, in this case, is the misunderstanding of the requirements or inadequate definition of the requirements.
  • Having assumptions of the requirement.
  • The requirement is ambiguous.
  • The requirement specification is incorrect.
  • Inappropriate technique.
  • Reviewers have no enough time to the preparation for reviewing the requirements.
  • Have a deep discussion about the boundaries of the application and gradually move on as the project progress.
  • Utilise most of the business analysis and the professionals involved as you can.
  • Regular workshops, and catch-up or stand-up (Scrum) meetings for clarity, and common understanding of implicit and explicit requirements of all stakeholders involved, including the test team.
  • Good communication with customers and users will help to understand and know the requirements.
  • A formal sign-off from all stakeholders involved in the project is the important prior start of the design phase.
DesignRoot CausePrevention
The design error is the inadequate design or the technical inadequacy in design.
  • The requirement is ambiguous.
  • The requirement does have not a clear message.
  • Inappropriate design tool.
  • Limited knowledge of the system used.
  • Reviewers have inadequate participation time.
  • Have a discussion of the desired result and the boundaries of the application and its requirements. The design should be well documented and a sign-off is important before starting the coding/work.
  • A careful analysis of the appropriate tool should be carried out before the task begin.
  • Training on the new tool should be carried out prior to starting.
  • The design should follow the requirements and be reviewed by the test and quality team. Should be reviewed adequately following a checklist and signed off.
Graphical ErrorRoot CausePrevention
Is the error in screens, reports layout and in designs?
  • 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/platforms nevertheless is important to test cross-browser, kit, hardware, and data.
  • Maintain a defect database of all the test cases carried out before starting the project.
DocumentationRoot CausePrevention
Involves the typographical error in the documentation and in the code. Including spelling, mistyped words and the code itself.
  • Oversight.
  • Mis-check review.
  • Having a thorough check review of the documentation is fundamental before delivering the project.
  • A full customer review is a must to prevent any typographical error in documentation.

References:

What it says in ISTQB

Full Training

Author

  • Rogerio da Silva

    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.  He loves reading biographies of successful authors and dream builders because they inspire him to keep creating!
    You can contact Rogerio for anything related to Business & Test Analyst | Microsoft Dynamics 365 CRM | QA | Agile | Manual | Integration & Automation | DevOps | API | Cloud | AI | IoT | CRM | Website Consulting | Email Consulting | Facebook Ads | Social Media Marketing Plan | Sales Funnel | Looking for Scalable Services? InShore, OffShore or Hybrid. Interested? Ask me how we can help.

Leave a reply

Publication

Now available on amazon prime

eBook (Amazon)

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

Paperback (Lulu.com)

Podcast

Certifications