Defects in testing – everything you should know

Last update: March 05, 2021

According to the 2020 Software Testing Trends report, 25% of employees in the tech industry believe that the biggest challenge facing start-ups is making development a priority. Testing is a key stage in product development, and the tester’s work is extremely important, not only for start-ups but also when it comes to software houses or even international companies. 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). 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.

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.

To put it simply, in the context of the IT industry, a defect is an error or a bug. Defects usually arise as a result of a programmer’s error, at any stage of software design, logic implementation, or code writing. They cause the malfunction of software of final product. The definition of a defect, according to the ISTQB Glossary, is as follows:

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 execution, may cause a failure of the component or system.

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 explanations. Reproducing the bug is necessary to make sure that what we consider to be a bug is indeed a software bug, not a user mistake or environment error.

Before we report a bug we find, we should check if someone else has reported the same bug before. If such a report already exists, then instead of duplicating it, we can add relevant information in the comment to help the developer fix the bug in the future.

It’s a good practice to create a bug report template so that we don’t omit any important information. How to make bug reporting effective? Such a report should include a summary, short overview, steps to reproduce, test results, and description of environment setup and configuration. This way we can avoid miscommunication.

Again, according to the 2020 Software Testing Trends report, 76% of software testers used tools for bug tracking like Jira, Bugzilla, or Redmine in 2019, making them the most common test management tools used by software testers. The next most used ones were agile workflow tools, capping at 59%. From our point of view, the effectiveness of reporting bugs does not depend on the tool itself, but on how well the tool matches the needs of the team, process, and individual workflow.

Life cycle

We have already established that the most important thing is to adjust the test management tool to the individual needs. And rightly so, because companies, teams, projects, work methodologies, and processes differ from each other. 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:

Bug lifecycle 01 New - a new defect is reported by the tester 02 Assigned - assigning a bug to the developer who will be responsible for its solutions 03 Resolved -  bug fixing, sending QA team and re-checking 04 Verified solution - verification and decision to end or re-open the process 05 Reopen - this step is performed when the defect needs to be repaired again 06 Closed - closing the process after solving the problem

First of all, a new defect is reported by the tester. Then the tester assigning a bug to the developer who will be responsible for its solution. The next stage is the application of required corrections in the code by developers. Then the fixed bug is sending to the QA team and re-checking. This stage may be followed by two different ones because, after solution verification, the QA team makes a decision to end or re-open the process. Reopening is performed when the QA team decides that. The defect still needs to be fixed. In other cases, we close the process after solving the problem and that marks the bug as fixed and 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, but the existence of bugs in the first place can ruin your business. Our task is to ensure the highest possible quality and reduce the cost of business defects – and these can be very serious.

Financial losses can occur at various stages of software development. Detecting and removing a code error at an early stage of production is definitely cheaper than removing the error and its consequences after software release or implementation. A huge waste of money has occurred with space missions such as Mariner 1, NASA’s Mars Climate Orbiter, and Ariane 5. Each of these devices was destroyed shortly after take-off, before completing the mission. Each of these disasters resulted from a software defect. This could have been avoided if the code had been tested beforehand.

Brand image may also suffer. An example is the most famous social networking site Facebook. A data leak in 2018 caused by a photo API bug caused users’ trust in this platform to drop dramatically.

Code defects can lead not only to such obvious consequences as financial losses or a negative impact on the brand image. It can also be a huge consequence of a large caliber. An example is the energy crisis in North America in 2003 (Blackout 2003), which was caused by a malfunction in the power grid control software. This incident affected North America and parts of Canada, caused chaos, a series of fires, and enormous financial losses.

How to avoid such accidents? It’s impossible to test all parts of the software, but we can still minimize the risk. Through risk analysis, we can identify and test those areas that are exposed for the greatest risk potential and that are most likely to fail.

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.

Software test management: the most important

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. As far as there is no software without bugs, it is hard to keep the company safe from the above-mentioned outcomes. Trying to mitigate business risks pay more attention to proper QA and testing of your software.

Fixing bugs at early stages saves your business from negative implications. Engaging a professional testing provider in the development process is one of the most effective and proven QA solutions. 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.

If you’d like to learn more about streamlining test management and bug tracking using Jira Software, check out this video tutorial series on our YouTube. Also, read more about requirements and test management:

Martyna Wiśnik

Martyna is a Content Specialist at Deviniti. She gathers information, writes down her notes on paper, and then brings the results to the digital world. As a hobby, she learns to code iOS apps.

More from this author