Bug Life Cycle Training

Table of Contents

Opening Remarks

Overview

Definitions

Workflow

Entry

Assign

Open

Fix

Retest

Verify

Close

Back to Open (Return)

Reject or Defer

Automation

Software Tools

Section 1

Module Video Resources

Opening Remarks

As we progress through this module, I will begin referring to the Bug Life Cycle as Software Bug Life Cycle (another acronym SBLC). Bug Life Cycle is the process that a software defect or bug goes through, from its initial discovery to its resolution or closure. Understanding the Bug Life Cycle is crucial to software application quality, as it helps to ensure that bugs are successfully tracked, managed, and resolved.

SBLC is a part of STLC. When a test analyst is testing software, the testing is intended to confirm that the software is working as expected. That process does not always go smoothly. Sometimes a test uncovers a problem which may be a bug, an issue, or a temporary obstacle. I refer to an obstacle as anything that impairs your ability to test in the short term. For instance, the test environment is down. Then there is an issue which is like a bug, but you treat it a little differently.

First, it is not something directly related to a code problem. It is something that is not working or not correctly working. For instance, the application is not available for testing because database backups are running at a time you set for testing. The issue is identified, and the bug system is used to communicate the problem. But someone might be assigned follow up immediately to resolve.

When the problem is a bug, it is considered an application execution level defect.  It is considered a problem with application code, HTML, CSS, or other software. Maybe it would be nice to consider these problems will go away. So, just ignore it and the problem will fix itself. Or somebody in development will see it and correct it. No.

It is not enough to find a bug or issue. It is necessary to know how to track a bug which means you need a way to record it or document it. Some test analysts write it down in a journal. Some use Excel workbooks. Still some use other tools like OneNote, or even emails to remind themselves and keep track of the issues. My favorite tools are known as Bug management or test management tools like ALM and JIRA. The plan in this training module is to give you an opportunity to work with these tools or something like them.

Overview

Bug tracking helps developers and test analysts manage issues and bugs in an organized, clear way. Developers can easily categorize and prioritize bugs to facilitate solutions and keep workflow progressing. Test Analysts can easily report and assign the bugs or issues they find. Users can also benefit from the ability to report bugs on the front end, which in turn helps facilitate comprehensive problem solving on the back end.

Bug tracking software is known as Bug management or bug tracking tools. You can find the bug tracking feature in test management tools too. It is used to ensure application testing runs smoothly and the user experience is as intended. Bug tracking software specifically tracks and explains how to reproduce bugs so they can then be resolved by the development or quality assurance (QA) team. You will also hear other terms for bug tracking, such as issue tracking and defect tracking.

The phrase “bug tracking” tends to imply that bugs can only exist in code, but this is not accurate. Bugs can exist in requirements, design, configuration, test environments, or even specifications. This is why I make a distinction between problem references where I say bugs and issues. Issue tracking is designed to help uncover or prevent these types of bugs from being treated the same as coding bugs.

Definitions

It might be helpful to start by including a list of terms to remind us of what they mean with regards to testing or more specifically, bug management.

• Bug or Defect – problems found in code directly or through testing an application.
• Issue – problems found in requirements, design, configuration, test environments, or even specifications.
• Problem resolution – the process of researching an issue or bug, and then introducing a fix.
•  

• Reporting – You might hear this referenced in two different ways. A user might ask you if you reported the bug which means you are being asked if you enter the bug into the bug management system. On the other hand, you might be asked if you can provide a report on the bug. This means they want to see output regarding the bug for follow-up purposes.
• Tracking – a process of bug entry, reviewing, assigning for fix, retesting, and closing or deferring.
  • Bug entry
  • Bug reviewing
  • Assigning
  • Retesting/Verifying
  • Closing
• Triage – This is typically a reference to a meeting. Typically, a defect or bug triage session is attended by project team leads or the entire team. In some cases, certain other members may also be invited to give their opinions and perspectives regarding certain defects. They are collectively called a triage team.

Workflow

Bug reporting can also be defined as the workflow used by quality assurance personnel and developers to keep track of software problems and resolutions. The result of the bug reporting workflow is two-fold:

• so-called bug reports
• and resolved bugs and issues

Defect or bug tracking is the process of tracking the logged defects for application software from beginning to closure. You do this by inspection, testing, or recording feedback from customers. You resolve by making new versions of the application software to fix the defect.

Defect tracking has a flow. The flow starts with one or more logged defects. Let’s take another look at the flow from the QA Manual Testing Introduction training module.

Bug Life Cycle Flow Diagram

The Bug Life Cycle typically consists of several stages in the process. Here we are including the entry of the bug or defect. It should be noted that the bug entry step is a process within itself. So, let’s go deeper into discussing the entry of a bug into a bug management system. Now keep in mind that you can try and do without a tool, but it makes the process so much more efficient to have a tool. It also makes sure everyone on the project team has access to the data.

For visual purposes I am going to use charts. The first chart is about the steps of bug reporting. While the second chart is about the process flow. In the steps we have seven steps identified: Reporting, Reproduction, Analysis, Fix, Test, Verification, and Closure.

Because of the high probability that you will be using a tool for bug management, I am taking this training to another level. Let’s talk more about the process flow for bug reporting.

I refer you to the Bug Life Cycle Flow Diagram. In the diagram you can see nine action steps. These action steps mostly have to do with changing the entry status within the reported bug. However, there is usually some team interaction that occurs that coincides with the status change.

Entry

With the Entry action step, I mentioned it has a process within itself. The process of bug entry involves not only documenting, but also the readiness for the bug to be what is known as triaged.

The data that needs to be captured for good bug reporting follows:

• A Title or Bug Identification code
• Environment where the test took place, and the test scenario reference
• All steps necessary to reproduce the problem. It must be clear and precise to reproduce the issue or bug.
• Expected Result – specify what was the expected test result.
• Actual Result – specify clearly what happened instead of the expected result
• Visual Proof (screenshots, videos, text) of Bug.
• Severity/Priority – these two values represent how serious the impact is to the software, and how important it is to give attention to this issue or bug, respectively.

When entering a bug into a bug tracking system it is normal for the bug entry to default to a status of NEW, and a bug type of DEFECT. For most entries this is satisfactory. In some instances, it is necessary to change the bug type to something else.

A bug type can be used to further define the nature of the so-called bug. Some projects become more anal where the problem can be identified as a code bug, system defect, document error, change request, feature correction, etc. But the common settings for bug type are Bug or defect, and Issue. The settings for most projects should be somewhere in between to adequately cover bug reporting.

Assign

The next action step can take place by a developer lead, a test lead, or the triage meeting. In the meeting a developer may choose to offer taking on the problem research. It is typical that the meeting attendants walk through the list of current bug list by status type. The status types that are normally reviewed in this setting are NEW, FIXED, RETEST, VERIFIED, RETURN, and DEFER.

As these types are reviewed participants who are familiar with the bug will usually speak up and give reason for the status. Then the meeting leader will take action to progress the bug or move on to the next bug on the list. Progressing the bug means changing the status to get the bug one step closer to a closed state. If the status remains unchanged it is because whoever it is assigned to is still working on it, or if it is not yet assigned someone has decided due to low priority or low severity further action should be postponed.

Open

When a defect has a status of NEW or RETURN, the person assigned to the defect is responsible for changing the defect status to OPEN. This is an indication to others looking at this defect in the system. They are informed that the defect is assigned and in-progress by the assignee. No one else is supposed to make changes to the defect until the status changes. And the bug system should block anyone else from modifications until the assignee releases the bug with a status change.

An assignee can release the bug with several status changes: NEW, FIXED, DEFER. An Assignee who has fixed the defect is expected to change the status to FIXED. But if the assignee found that someone else should work on the problem, the defect status can be changed to NEW again for the triage to handle. When an assignee changes the status to DEFER, the reason is that the assignee thinks the defect is either not a defect or the defect cannot be fixed currently. This leaves the triage to handle the defect further.

Fix

This action step should be labelled FIXED. This is the status that a defect assignee uses to identify to the project team that the defect has been researched and repaired. The triage will reset the status to RETEST and assign the defect to a test analyst for follow-up.

Retest

The assigned test analyst will move on with test preparation and reset the status of the defect to VERIFY. Depending on how the test team has this process defined, there may be other status options. For instance, there could be a VERIFIED status to indicate when the test analyst is done. The test analyst may be allowed to change the status to CLOSE.

Verify

If this is the status used by the test team, the test analyst is using this status to indicate they have completed testing and this defect is confirmed. The triage should review and move on with closing the defect.

Close

At the triage the review of defects in the VERIFY state will possibly discuss with the intent of setting the status to CLOSE. This officially takes the defect off the triage list. It will no longer be discussed unless a new defect is determined to be a duplicate of an existing defect or one that is in the CLOSE state. The triage participants will discuss and determine what action to take.

Back to Open (Return)

Occasionally there are times when a defect is up for discussion in the triage and it is scheduled for RETEST, but for some reason the test analyst has determined the retest results indicate something is still not resolved. Someone must clearly communicate that the developer overlooked something or maybe the changes did not get into the test environment. Then triage will change the status to RETURN and reassign the defect to a developer.

Reject or Defer

Another route for a defect, especially when it is determined to be a duplicate or not a problem is DEFER or REJECT. These statuses can also be used to put a hold on a defect. It is possible that changes have occurred to the project or change requests to the application that may nullify the defect. For instance, a defect identifies a page not working or the link is broken, but by the time the triage was scheduled, a change request was accepted that removes that page.

Automation

The biggest benefit of using a bug tracking tool is that it allows your company to track all the bugs in one place. It is a centralized platform that tells who reported the bug, who fixed it, what the priority and severity is and how long it took to fix the problem.

Having a tool to support the bug management process is essential to test project success. Here are some ideas that can be used to state the argument that a tool is necessary.

1. The project team can more easily manage and prioritize defects in a central location.
2. It is good for task assignments, comments, and progress tracking.
3. It helps identify bug trends.
4. The quality of the software is important to the project.
5. Management and stakeholders can have direct access to the status of things.
6. Historical records of bugs and their resolutions.

Software Tools

It is not enough to mention automation of the bug cycle process without mentioning software tools that support the Bug Life Cycle. There are many tools available that can help to streamline and automate the bug handling process, including

• issue tracking systems,
• bug tracking tools, and
• test management software tools.

Some popular tools include ALM, JIRA, Bugzilla, Trello, Zoho Bugtracker, and Microsoft TFS.

These tools can help to simplify and standardize the bug handling process, making it easier to report, track, and resolve software defects. For example, a bug tracking tool may automatically assign a unique ID to each bug, track its status, and progress, and provide a centralized repository of all bugs and fixes.

In terms of the impact of SDLC and Agile on the Bug Life Cycle, both methodologies can have an impact on how bugs are managed and resolved. In general an SDLC environment, the Bug Life Cycle is typically integrated into the overall development process, with a clear and well-defined set of stages and procedures. In contrast, Agile methodologies emphasize a more flexible and iterative approach, with an emphasis on continuous testing and feedback.

In an Agile environment, bugs are often addressed as part of the regular sprint cycle, with a focus on rapid resolution and continuous improvement. The Bug Life Cycle may be less formal and structured in an Agile environment, with a more informal and iterative approach to bug reporting and resolution.

Ultimately, the impact of SDLC and Agile on the Bug Life Cycle will depend on the specific needs and requirements of each project. However, regardless of the methodology used, it is important to have good processes in place to manage and resolve software defects.

This not the end of this article. This section 1. There is another section for your reading and training. Please click here to see the second section of this topic.