Defects in testing – everything you should know


25 July 2016 • 10 min read

    It is impossible to create software that has no defects. Defects are an inseparable element of every product, which can become a significant risk factor to our business or our clients. However, we can minimize the effects of errors thanks to proper software development practice.

    A tester’s work is extremely important, and testing is a key stage in product development. It is thanks to the tester’s work that we can identify critical areas of the application and ensure its high quality by finding errors (called defects or bugs).

    What is a defect in testing?

    A defect is a system error that doesn’t allow the intended action to be completed. Finding defects is the tester’s most important task. It’s important to start testing as early as possible because defects can be found throughout the entire software development process. The earlier we identify them, the lower the costs of their fixing. All bugs should be recorded and tracked so that they can be properly managed and resolved.

    Effective bug reporting

    Accurate and proper bug reporting is very important. If the report contains all the necessary information, the bug is easy to identify and is repeatable. People who correct a specific defect can reproduce it so that it can be repaired. This helps to avoid unnecessary misunderstandings, useless work, and additional explanation.

    To create reports without any problems, simply implement the 6 simple rules.

    Life cycle

    Each defect follows a specific pathway from its detection to removal. This is the so-called bug life cycle that has many stages. Depending on the product being tested or the bug detection tool we use, this process may look different.

    The most basic one is based on six stages:

    1. New – a new defect is reported by the tester.
    2. Assigned – assigning a bug to the developer who will be responsible for its solution.
    3. Resolved – application of required corrections in the code by programmers. Sending to the testing team and re-checking. This stage may be followed by two different ones.
    4. Verified – solution verification and decision to end or re-open the process.
    5. Reopen – this step is performed when the tester decides that the defect needs to be repaired.
    6. Closed – closing the process after solving the problem – marking the bug as closed.

    There are several stages in the bug life cycle that can affect the order of the steps taken. For example, if the detected error is not so important for the current stage or a given version, it may get the Deferred status at the beginning. The process can also stop because of the lack of sufficient information about the defect the tester passes to the developer.

    Defects and their business impact

    Defects are an integral part of every software product. We have to accept the fact that finding all bugs is simply impossible. Our task is to ensure the highest possible quality and reduce the cost of business defects – and these can be very serious.

    Software errors often lead to financial losses that can happen at various levels. One of them is operational costs. The reason behind that is the defects affecting the processes in the organization – they prevent or limit the company activities. Another example is reputation costs that occur when errors affect customers. Inaccessible services, poor performance, delays – these problems often cause a loss of trust.

    A thoughtful testing process tailored to the project needs allows effective identification of serious problems and thus minimization of this risk.

    How to manage bugs?

    Once we find bugs, we must learn how to manage them. It would seem that identifying defects is a walk in the park – after all, we’re supposed to eliminate each identified problem. But what if we have limited human resources, deadlines are near, and mistakes are multiplying?

    First of all, we need to prioritize defects. This measure determines how urgent correction is. Thanks to prioritization, we can plan work without fearing that we will constantly fight errors. Of course, some defects need to be repaired immediately, but a large part of them can wait their turn.

    Severity is another useful measure for managing errors. It tells us what impact a given bug will have on the application. As with prioritization, its levels must be well defined. An example of a critical error is the inability to make a quick transfer in the banking system. A logo error, on the other hand, will have a negligible impact on the system.

    You can also categorize bugs. That allows creating databases and more accurate reports so that testers can check whether a given error has already been reported. It also enables better diagnostics and identification of application areas that are causing the most problems, i.e., those that should be given special attention during future tests.


    The topic of defects is very important in the context of the software development process. Bugs affect the product quality, so you need to manage them properly and eliminate the most serious issues on a regular basis – all the while maintaining the continuity of other work. 

    Error reporting is an important issue as well. It allows categorization or prioritization of errors, but also provides a source of information for developers who implement patches and corrections. Another issue is the transparent workflow for bug fixing, which reflects the current defect status. These elements are key to maintaining better defect control that helps to build more valuable software.

    [contact-form-7 404 "Not Found"]