Skip to main content

A Bug's Life! Defect Management Process in Software Testing

First things first, what does a "bug" mean in the software development process? A bug is what we call a behavior that is different from what's expected based on the provided requirements. A tester's main purpose is to find and report bugs in the system as early as possible.

In some companies, it's sometimes called a "defect". They actually mean slightly different if we go by the book. In this post, I'll be covering the lifecycle of a software bug which are issues that are found during the development phase.

You're testing the system and you found a bug. What is the first thing you do?

a) You immediately write a bug report
b) You try to reproduce it
c) You complain "How could this very obvious bug reach QA? Dev should've spotted this earlier ugh."

The formal answer is B (I'll just let you figure out what's the informal answer),

It's common for a QA to be gaslighted. "I cannot reproduce this bug.", "It doesn't happen on my machine.", "Can you try to clear your cache?". You will go through periods of self-doubt where you think did the issue really happen or it's just you're imagination? Test evidence is very important that's why you have to make sure that you can reproduce a bug consistently before you create its bug report.

What happens if you cannot reproduce a bug consistently? Well, that's probably a topic for later.

Creating a bug report

Make sure you have some sort of tool to track bugs because it can get messy. It can be as humble as a file in Google Sheets, a Jira ticket, or some dedicated bug-tracking tool. What's important is it contains all the key information that a bug report should have.
  1. Bug ID. This is the unique identification number for your bug report. It will make conversations about the bug easier.
  2. Summary. This is a brief description of your bug. A title if you will.
  3. Test Data. It could be a user ID that you used to log in when you encountered the bug or a specific input value that triggers the bug.
  4. Environment. This could vary or be expanded based on your organization. It could be the test environment, the browser, the operating system, the system version, etc.
  5. Steps to Replicate. A list of steps that will lead the developer to recreate the bug on their machine. Please write this in a numbered list format or else I'll haunt you.
  6. Expected Result. The expected outcome of your steps based on the requirements.
  7. Actual Results. The actual behavior of the system (a.k.a. the bug itself).
  8. Test Evidence. Could be a screenshot, screen recording, etc that proved that the bug did happen.
  9. Severity. Helps identify how severe the bug is. You can think of it as, "From 1-10, how devastated the user would be if this happened?"
  10. Priority. Helps identify how soon should the team fix the bug. You can think of it as "How f*cked will the company be if we don't fix this before we launch?"
  11. Reported by. The person that the developer hates.
  12. Assigned To. The person that the QA hates.
  13. Status. The phase in the life cycle the bug is currently in.
You can also add other attributes in your bug report such as "Created date", "End Date", "Category", "Resolution", "Feature" etc. in case you want to track more data to be used for creating metrics to assess the team's performance or find analyze the system under test.

The lifecycle of a bug

Detection

A bug's life starts when QA finds it and submits it to the team in the form of a bug report.

Analysis

The team checks the bug report and assesses if:
  • Is it valid?
  • Is it urgent?
  • How much effort do we need to fix it?
This is why it is important that your bug report has all the necessary information because it's not just for the team to replicate, but also helps them decide on when to fix it.

Resolution & Closure

The developers will fix the bug and the QA will retest. Closing a defect might not be straightforward. There could be times when the fix did not work so we have to send it back to the developers, or that we need to pull in the product owner since the QA and developer cannot agree on the expected result if they interpreted the requirement differently.

Reflection

This is where we reflect on why the bug happened, why we had x number of bugs, x number of bugs that failed retest, x number of bugs in the release/module, x number of high severity etc. This helps us find out the root cause and think of necessary actions to fix these so we can have a better release next time.

Creating a bug workflow

When deciding on the workflow of your bug report, consider how your organization works, how your dev team works, and how the QA team works. It could be that they want to keep it simple, or maybe there are specific metrics you'd like to extract in the future that would depend on a specific status




A bug is only over once it's fixed. The Status attribute plays a very important role in managing the bug because it helps everyone understand where it currently stands.

Remember these important points when thinking about the list of Statuses:
  • It should be clear when the bug is ready to be picked up.
  • It should be clear when the bug is ready for retesting.
  • It should be clear when the bug is closed.
The list of statuses you'll have for a bug can vary based on your organization's preference. It could be something as simple as a few statuses like this.
Or if you'd like to get more data on how the bug progressed, it can be as elaborate as this one:
 

Conclusion

A bug report is a crucial deliverable of a software tester. It's very important that we provide all the necessary information and the correct workflow to reduce the chaos in our organization as much as possible. There's no single solution for everyone so make sure you curate your process based on your organization's needs.








Labels:

Popular posts from this blog

Reframing how I identify bug root causes

It's been more than a year now since I've set up our bug tracking in JIRA. In there, I've set up an Issue Root Cause custom field where it had the following options: Incorrect coding Unclear / Missing / Incorrect Requirements Unclear / Missing / Incorrect Design Insufficient / Duplicated / Incorrect Testing Deployment Issue Environment Third-party issue My thoughts when I listed these as options is so that it would be easy to identify which team is responsible for the cause why we had that bug. They're pretty straightforward -  Incorrect coding  is of course when the developers didn't follow the expectations,  Unclear / Missing / Incorrect Requirements is because there's a gap in the requirement, and so on. And also, it's because that was the way it's done in my previous company so that's also my initial knowledge source. Recently, I've been reading a few articles regarding Shift Left, reducing silos, and generally how quality is a team activit...
Read more

QA Tools: Custom Test Case Generator in Google Sheet using Google App Script

When testers have to document test cases, it's usually done in the traditional format of putting all your test cases and steps in one sheet. Once it accumulates, for me it can be overwhelming to look at. It looks something like this: As a solution, I decided to make a tool that will help me focus on only drafting my test scenarios and look at my test cases one at a time. I'd like to share this here with everyone else who's like me. Hopefully, it can make your testing journey even a little better. Test Case Generator Tool This tool is for QA or non-QAs who need to write test cases. What it can do: Write your test scenarios in one tab Focus on writing steps for each test case one sheet at a time Generate an import file Generate a test execution document Sample test execution document: Scroll to the bottom to see how it works. Sheet Purpose Test Scenarios This is where you set the details for this test set/the project/story/epic where you're creating the test cases u...
Read more