Life Cycle of a Bug

Software bugs can affect computer operating systems' functionality, safety, and security. "Debugging" and error management "bugs" are already a fundamental part of the computer industry.

Quality Assurance or QA’s objective is to ensure that the internal processes, manufacturing means, and all the tasks to obtain the product or service are adequate. In quality control, the final product is analyzed and measured, making the necessary checks to see if it meets the criteria specified by the client, the company, or any required quality standard. QA ensures quality in a preventive way, avoiding the appearance of failures or errors "BUGS" in the final deliveries.

What is a Bug?

A bug is a failure or an error in an application that occurs in the programming of the software. Despite the revisions, the bugs still need to be eliminated many times. Although they are frequently reported, reproducing a bug in a controlled environment is a difficult task, making its identification a late process.

Regardless of the software, bug fixing is a priority and should be done in a development environment with a QA team. A bug is only fixed once the error occurs; until then, the identification and resolution methods must be implemented repeatedly.

A tester is responsible for proofing an application to find as many defects as possible to ensure a quality product reaches the customer.

Some bugs may not cause severe effects on the program’s functionality and may go undetected for a long time. Another category of bugs affects security when a malicious user accesses a program's controls and gains unauthorized privileges.

Stages of a Defect in a Test Environment

• New: A new defect is found, and validation and testing are performed on this defect in the later stages of the defect life cycle.
• Assigned: The project lead or test team manager assigns a newly created flaw to the development team to work on.
• Open: The developer starts the defect analysis process and fixes it. Suppose the developer deems the defect to be inappropriate. In that case, it can be transferred to any of the following four states: Duplicate, Deferred, Rejected, or Not a Bug, depending on a specific reason.
• Fixed: The developer finishes correcting a defect and making the necessary changes; he can mark the status of the defect as 'Fixed.’
• Retest: The tester begins retesting the defect to verify whether the developer has fixed the fault accurately as per the requirements.
• Verified: If the tester finds no issues with the defect after being assigned to the developer for retesting, the defect status is set to 'Verified.'
• Reopen: If some issues persist, it will be assigned back to the developer for testing, and the defect status will change to 'Reopen.'
• Closed: The defect can be closed after validation by the quality team. They can also close a duplicated or not considered defect.

The workflow of a defect life cycle is shown in the diagram below:

When a tester logs new bugs, the required fields are Build Version, Ship On, Product, Module, Severity, Synopsis, and Description to reproduce. You can add optional fields in a manual bug submissions template, such as Customer Name, Browser, Operating System, Attachments, or Screenshots.

Defect Description

The description of the defect considers the following elements:

• When: Action that describes the event and variables within the test case description.
• What: The result obtained when executing the action (when), which differs from the expected result.
• Where: Location of the test object.
• Expected Result: Describes the purpose of the functionality.

Defect Severity

Assigning severities to the reported defects will facilitate their prioritization. Different types of severities exist, such as Blocking, High, Critical, Major, and Minor. This will depend on each organization.

• Blocking: There are no business rules and/or application functionality. The normal flow of the functionality is blocked and cannot continue.
• Functional/Major: These are serious problems that affect business rules.
• Minor: The defect does not affect business rules and is probably a cosmetic problem.

Different tools like Jira allow tracking bugs and generating reports for each execution cycle by priority and status. It is an excellent strategy to measure priorities, so the team does not get surprises when receiving reports.

Guidelines for Implementing the Defect Life Cycle

• The entire team clearly understands the different states of a defect.
• The defect life cycle should be properly documented to avoid confusion in the future.
• Make sure that everyone assigned to any task related to the defect life cycle clearly understands their responsibility for the best results.

• When changing the status of a defect, a detailed explanation should be provided to understand the reason for the change.
• It is essential to maintain consistency across defects and, therefore, within the defect life cycle workflow.

Seven Elements of a Bug Ticket

When raising a bug ticket, remember that the only audience is the developer who will implement the solution. Reports must be concise and exceptionally clear about what is going wrong and the expected result. All essential details must be discussed to ensure the developer can diagnose and fix, allowing QA to properly retest and close the ticket.

Reporter and Assignee

Provide the name of the person reporting the error. If the defect arises in a current ticket being tested, QA can assign it to the same developer who worked on the original ticket. If a new issue is unrelated to any existing ticket, the given field can be left for a project manager to find the right developer.

Title Description

Type a specific title relevant to the nature of the problem. This is the first thing a developer sees before opening the ticket and reading the details. The description should be a summary of what the problem is. It is usually between one and three sentences long. You must state precisely what is happening.

Steps to Reproduce

Clearly describe the steps that need to be taken to witness this error in real-time. The steps should be comprehensive and easy to follow. Do not assume or skip any playback steps. For complex issues or bugs that are only reproducible sometimes, it's best to meet one-on-one with a developer and discuss further.

Actual Behavior versus Expected Behavior

Clearly describe the steps that need to be taken to witness this error in real-time. The steps should be comprehensive and easy to follow. Do not assume or skip any playback steps. For complex issues or bugs that are only reproducible sometimes, it's best to meet one-on-one with a developer and discuss further.

Severity and Priority

Evaluate and describe the severity of the bug's impact on the tested system: critical, major, minor, or trivial. The priority indicates the urgency of the reported error: how crucial it is to the business. The priority assignment determines how bugs will be dealt with after they are reported. If there are many bugs in the backlog, a bug triage meeting, including the product owner or project manager, should be held to review the severity and priority assigned.

Environment and Devices

List the environments where the bug was detected to ensure the developer can replicate it. The app may behave differently in test, UAT, or production environments. It is equally important to define the type of platforms and devices used: URL, mobile devices, and the operating system.

Affected Version

Indicate the version of the application in which the problem was detected. For example, you found a bug in your software that affects versions 1, 2, and 3 of your software. You must put 1, 2, and 3 in the "Affects versions" field. This allows the development team to track bugs or defects in already released code and trace back to where the bug originated.

Conclusion

A bug life cycle defines a defect’s stages from beginning to end. It starts when a tester finds a new bug and ends when a tester closes that bug ensuring it won't be reproduced. Identifying and remediating defects early is essential since fixing them before going to production is less time-consuming and less costly.