In this article, I will try to explain what the software bug life cycle (SBLC) is, its importance, and how it should be implemented effectively in practice. Let’s get started

The Software Bug Life Cycle (SBLC) – Table of Contents

• What is the software bug life cycle?
• How should SBLC be applied?

1. Find Bugs
2. Find them as early as possible
3. Make sure they get fixed

• Conclusion

Before I talk about what SBLC is, I would like to point out a question I often encounter, to help you understand why we need it: Why can’t the QA team and the DEV team ever get along? 

So, is that true? If you are one of these professions, you must have come across dozens of videos and caricatures on the internet describing the eternal rivalry and even the conflict between these two professions.

In almost all of these contents, the DEV team makes fun of the testers’ lack of knowledge, while the QA brags about the goals they’ve scored to the developers.

What about real business life? Although it is not as exaggerated as on the Internet, it is an undeniable fact that there are disagreements and occasional conflicts between the DEV and the QA team.

So, why is there such incompatibility between these two teams, who work for the same purpose – a quality and bug-free product? Probably the first answer that comes to mind is the mindset difference between these teams: While the DEV team focuses on the development, QA approaches it from a completely different perspective. They focus on the negative, try to find faults in the product, have professional pessimism, and so on.

Contrary to popular belief, this is not the main reason for the conflict between the QA and DEV teams. Both teams know that two different roles complement each other and that it is perfectly normal (and important) to think differently and approach the product from different angles.

Another wrong answer might be that the testers found a bug and the developers feel uncomfortable with it. This is definitely not true. During my professional life, I have witnessed many times that the DEV team is happier than anyone else when QA finds a bug before the release to production. That’s because the bug is found before the production and the DEV team has enough time to fix it.

So what is the reason for this disagreement between these teams? The answer is that the SBLC is not understood in the same way by the two teams and is misapplied in practice. After this long introduction, we can start talking about SBLC

What is the software bug life cycle?

SBLC represents the whole process from finding the bug in the AUT to fixing it. In other words, it consists of communication between DEV and QA team on the bug found. Formally, SBLC consists of the following steps:

• New: When the tester finds a new bug ticket is created, and the status of the bug is set as “New”.
• Assigned: Once the bug ticket is posted by the tester, the tester or the lead of the tester assigns the bug to the developer team.
• Open: The DEV team starts analyzing and works on fixing the bug.
• Fixed: When the DEV team makes necessary changes, they make the bug status “Fixed”.
• Retest: In this step, the QA team does the retesting of the code or feature to check whether the defect is fixed or not. And it sets the status as “Retest”.
• Verified: The tester retests the bug after it got fixed. If the same bug is not detected, then the bug is fixed and the status is set as “Verified.”
• Re-open: If the same bug persists even after the fixing, the tester sets the status as “Re-opened”. Then the previous steps are applied to the bug once again.
• Closed: If the bug no longer exists then the tester sets the status as “Closed.”

Unique use cases:

• • If the bug is repeated twice or corresponds to some other bugs, the status is set as “Duplicate” by the developers.
  • If the DEV team decides the bug is not a real defect or it does not affect the functionality of the application then it sets the bug as “Rejected”.
  • If the bug is not high priority, or it is decided to get fixed in the next release, or the fixing of the bug depends on something, then the status “Deferred” is set.
  • The above diagram and steps only explain the SBLC algorithm. In practice, trying to allocate the communication between the DEV team and the QA team through these robotic steps is an applying mistake of SBLC and will cause major communication problems between teams.

How should SBLC be applied?

While giving an implementation of software development life cycle (SDLC) with the QA approach in practice, I would like to act in the light of the following definition made by Ron Patton in his book Software Testing:

“The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed”.

This description is also a great explanation of the bug life cycle. Let’s consider SBLC in the following three parts:

1.  Find bugs.
2.  Find them as early as possible.
3.  Make sure they get fixed.

1. Find Bugs

As seen in the diagram above, the cycle starts with the detection of the bug by the tester. The common implementation is that the tester finds a bug, creates a bug ticket, and then initiates the bug life cycle, i.e. communication with the DEV team. This is essentially a faulty practice.

The QA team should initiate communication with the DEV team before creating a bug ticket. In order to reach certainty of the current bug suspicion, the opinion of the DEV team must be taken, and then a bug ticket should be created This approach has the following advantages:

• Preventing the application of SBLC for fake bugs which are caused by some mistakes in SRS documents, test cases, test environment, test technique, or tools.
• Pre-analysis made with the opinion of the developer helps the tester at the stage of opening the bug ticket, describing the defect, and specifying the root causes. A ticket with sufficient explanation will make the developer’s job easier during the fix phase.
• It allows the overlooked minor code bugs, DEV environment, or current version problems to be fixed without the need for SBLC steps or creating bug tickets.
• It contributes to the collaboration and communication between the teams.

Even if the tester is 100% sure of the existence of the bug, the pre-analysis with the DEV team is of great importance. Sometimes it takes a long time to fix the defect due to priority.

I have witnessed many times that the bug is not reproduced over a few weeks because it is caused by the current version or the current performance of the application.

Generally, it is beyond the tester’s skill to analyze this situation, and in this case, a pre-analysis with the DEV team may be the only chance to find the root cause of the bug.

2. Find them as early as possible

As a tester, you created a bug ticket. Is your job is done? Of course not. If the bug is confirmed by the DEV team, the tester should act according to the software test principle; Defects cluster together. If there is a bug somewhere, there must be others.

The current bug should be considered as a trigger, a deep test should be started as much as possible, and the relevant functions or features should be tested with different testing practices.

Each new finding should be examined and analyzed in relation to the existing bug, and the bug ticket should be expanded with new comments and made more comprehensive if possible. This method would allow other existing problems to be found as early as possible.

3. Make sure they get fixed

Sometimes a bug waiting to be fixed can be more serious than it seems, so the tester should be dynamic at this stage as well, revealing the real priority of the bug with extensive tests, and push the DEV team to fix it ASAP.

After the defect is fixed, the tester should approach the defect with different test techniques, and run all relevant tests again during the retest phase. If it encounters the same or a different bug, the tester should contact the DEV team again and have the defect reconsidered immediately.

In addition, after the bug is closed, it is the QA team’s responsibility to update the testware, or SRS if necessary. It should be kept in mind that incorrect test cases & scenarios, and incorrect requirement documents will cause fake bugs in the future, leading to a waste of time

Conclusion

In a software application, how many bugs are found and fixed cannot be shown as a measure. The important thing is how much time and how much money you spent on this whole process.

The right methods that enable the collaboration of the teams with different mindsets should be used to reach a quality and bug-free product, which is the main purpose of the software project. When applied correctly, the software bug life cycle is one of these right methods