A Software Bug: The Life and Times

Understanding the life cycle of a software bug opens the doors to understanding Quality Assurance and its place in the Software Development Lifecycle. Knowing what happens once a bug has been entered will help you understand some of the processes undertaken by software testers and developers. Below I will guide you through all the questions you may have about what happens once a bug is found.

As you go about your day quality assurance testing, you will encounter behavior in the program that is not as designed. When this happens, it’s time for you to enter a bug.

Once you have entered it, how does the bug get fixed? Who does it get assigned to and what should that person do with it?

Below is an explanation that follows a bug’s life. Follow along on the proceeding flowchart as you read this to gain a clear understanding of why and how a bug is assigned to different people and what they do with it.

1. You find a bug:
1. Being the responsible and thorough tester that you are, you search the bugbase to see if this particular software bug already exists. You search through Open and Closed bugs.
1. If the bug already exits and is currently in an “Active” state, add any new information that you have uncovered (if applicable) and move on to your next test
2. If the bug already exists but is in a “Closed” state, Re-Activate the bug and assign it to the appropriate person. This is often the person who fixed it in the first place or the Producer/Project Manager
3. If the bug is not yet in the bugbase, you determine the exact environment and steps necessary to reproduce the bug. Once you have done that, you are ready to enter it
2. You enter the bug:
   1. Employing all of the knowledge you have gained to date, you enter a bulletproof bug. You fill in all of the necessary fields and then assign the bug to the appropriate person
   2. At this point the bug is in the Active state
3. The person assigned the bug now reviews the bug, prioritizes it, and either:
1. Fixes it, changes the Status to a Resolved state and assigns it to QA
2. Assigns it to the appropriate party to be fixed
3. Assigns it back to QA because the bug needs more information or some other sort of clarification
4. Once the bug is assigned to the appropriate person to be fixed:
1. A fix is made
2. The bug’s Status is changed to a “Resolved” state and is assigned to QA
5. Having determined that they need more information before attempting a fix, the bug is reassigned back to you in the Active state, requesting more information
1. You update the software bug with the necessary information and reassign in back to the person that assigned it to you, clearly noting that you have added the information requested. The bug is still in the Active state
6. A Resolved bug is assigned to QA:
1. You review the fix for the bug and determine 2 things:
1. The stated fix is clear to you
2. The build in which you will be able to test the fix
Once you have a build in which you can test the fix, you test the bug:
1. If the testing fails and the bug still occurs, change the Status to an Active state and assign the bug back to the appropriate party
2. If the testing verifies that the fix worked and that that bug no longer occurs, change the Status to a Verified state and then close the bug




And so goes the life of a software bug.


---

Any sufficiently advanced bug is indistinguishable from a feature.
~Rich Kulawiec

---


Leave A Software Bug: The Life and Times and go to Successful Quality Assurance Home

© 2008-2011 Successful-Quality-Assurance.com


SBI!