Bug Reporting and Defect Management

# CHAPTER 5

Bug Reporting and Defect Management #

1. Introduction #

Finding a bug is only half the battle. If a QA Engineer finds a critical vulnerability but writes a terrible, vague bug report (e.g., "The app crashes sometimes"), the developer will close the ticket as "Cannot Reproduce," and the bug will ship to production. A bug report is a critical piece of engineering communication. It must be precise, objective, and contain all the technical context required for a developer to isolate the issue immediately. In this chapter, we will master Bug Reporting and Defect Management. We will explore the Bug Life Cycle, learn the crucial difference between Severity and Priority, and write the perfect "Steps to Reproduce."

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Understand the complete Defect/Bug Life Cycle.

• Write a professional, developer-friendly Bug Report.

• Clearly differentiate between Bug "Severity" and Bug "Priority."

• Define clear "Steps to Reproduce" (STR).

• Utilize tracking tools (like Jira) for defect management.

3. The Bug Life Cycle #

A bug does not just exist; it travels through a specific state machine.

1. 1. New: QA finds a bug and logs it.

1. 2. Assigned: The Test Lead assigns the bug to a Developer.

1. 3. Open / In Progress: The developer is actively fixing the code.

1. 4. Fixed: The developer pushes the code and marks it fixed.

1. 5. Retest: QA tests the exact same bug again in the new build.

1. 6. Verified (Closed): If the bug is truly gone, QA closes the ticket.

1. 7. Reopened: If the bug is *still there*, QA reopens the ticket and sends it back to step 3.

4. Severity vs. Priority #

These two concepts are highly tested in interviews and often confused.

• Severity (Technical Impact): How much damage does this bug do to the system? (Determined by QA).

• *High:* The app crashes, data is deleted, security is breached.

• *Low:* A typo in the footer text.

• Priority (Business Impact): How urgently does this need to be fixed? (Determined by Product Manager).

• *High:* Fix it today.

• *Low:* Fix it next month.

*Examples of the Matrix:*

• High Severity, High Priority: The Payment Gateway crashes completely. Nobody can buy anything.

• High Severity, Low Priority: The app crashes if a user uses a specific legacy browser (IE8) that only 0.001% of users have. (It crashes badly, but the business doesn't care right now).

• Low Severity, High Priority: The company's logo is spelled wrong on the homepage. (It doesn't crash the system, but the CEO wants it fixed in 5 minutes).

5. Anatomy of a Perfect Bug Report #

A developer should never have to message you asking for clarification.

1. 1. Title: Clear and concise (e.g., "App crashes when entering negative numbers in Quantity field").

1. 2. Environment: OS, Browser, App Version (e.g., iOS 17, Safari, v1.2.0).

1. 3. Steps to Reproduce (STR): Numbered, exact actions.

1. 4. Expected Result: What *should* happen.

1. 5. Actual Result: What *actually* happened (The Bug).

1. 6. Visual Evidence: Attach a screenshot, video recording, or network console logs.

6. The Golden Rule: Isolation #

Before reporting a bug, QA must isolate it. If the app crashes on the "Submit Order" page, is it because of the credit card number? The shipping address? The browser type? A good QA tester tests different variations to pinpoint the exact trigger before writing the report, saving the developer hours of debugging.

7. Visual Learning: A Good vs. Bad Bug Report #

The Bad Bug Report:

• *Title:* Shopping cart is broken.

• *Description:* I tried to buy a shirt and it gave me an error. Please fix.

*(Result: Developer closes as "Needs More Info").*

The Perfect Bug Report:

• *Title:* 500 Server Error when applying Promo Code "SUMMER10"

• *Environment:* Chrome v115, Windows 11, Staging Environment.

• *Steps to Reproduce:*

1. 1. Add 'Blue T-Shirt' to Cart.

1. 2. Proceed to Checkout screen.

1. 3. Enter "SUMMER10" in the Promo Code field.

1. 4. Click "Apply".

• *Expected Result:* A 10% discount is applied to the total.

• *Actual Result:* A red popup appears saying "500 Internal Server Error" and the cart total resets to 0.

• *Attachments:* Screenshoterror.png, ConsoleNetwork_Log.txt

8. Best Practices #

• One Bug Per Ticket: Do not write a bug report that says "The login button doesn't work, and also the profile picture is upside down." These are two different bugs that require two different developers to fix. Make two separate tickets.

9. Common Mistakes #

• Emotional Language: Never use angry, insulting, or emotional language in a bug report. (e.g., "The developer broke the login again, this is garbage code.") Stick entirely to objective, technical facts. QA and Devs are on the same team.

10. Mini Project: Write a Bug Report #

Scenario: You are testing Instagram. You try to upload a 5GB video. The app freezes completely and you have to force-quit the application. The requirement states the maximum file size is 1GB. Your Task: Write the bug report. *(Self-Check: Did you include the Device environment? Did you list the steps? Did you identify this as High Severity?)*

11. Practice Exercises #

1. 1. Define the difference between "Verified/Closed" and "Reopened" in the Bug Life Cycle. Whose responsibility is it to change these statuses?

1. 2. Provide a real-world example of a bug that is "Low Severity" but "High Priority".

12. MCQs with Answers #

13. Interview Questions #

• Q: Walk me through the standard Defect Life Cycle from the moment you discover a bug to the moment it is closed.

• Q: A developer rejects your bug report and marks it as "Cannot Reproduce." What are your immediate next steps as a QA Engineer?

• Q: Explain a scenario where a bug might be classified as High Severity but Low Priority.

14. FAQs #

Q: What if the developer says "It's not a bug, it's a feature"? A: This is a classic conflict. The resolution is the Business Requirement Document (BRD). If the BRD says the system should do X, and it does Y, it is a bug. If the requirement is ambiguous, the Product Owner must clarify it.

15. Summary #

In Chapter 5, we learned that finding a bug is useless if it cannot be communicated effectively. We mastered the Bug Life Cycle, ensuring issues are tracked from discovery to verified closure. We learned to separate technical damage (Severity) from business urgency (Priority). By writing flawless, unambiguous bug reports with exact "Steps to Reproduce" and isolated variables, QA engineers provide developers with the exact surgical information needed to fix the application rapidly.

16. Next Chapter Recommendation #

Manual testing and bug reporting are the foundation. Now, we must look at how developers test their own code before QA even sees it. Proceed to Chapter 6: Unit Testing Basics.