A bug/defect goes through many different phases from discovery to when it’s fixed. Just because you find it doesn’t mean it’s high priority and on the list to be fixed, or honestly, that there are plans any time soon to fix it.

Can this be frustrating? Hell yes. As QA you want quality, your job is to find these issues and report them with the goal of them being fixed and a better customer experience, however, with how fast things move priorities constantly change, which can put some issues on the back burner, or even in line to be on the back burner, haha.

I know I don’t always agree with priorities, but I communicate the issue, the risks, what the user experience is, and from there I’ve done all that I can and I have to trust that my PM is prioritizing the best way. There is currently one “bug” I found, that actually is functioning as it should but is an awful user experience. I bring it up every.single.day. I’m annoying as all get out, but it had me, QA, confused on how to even test correctly and I thought the feature was broken – what will the customer think? I’ve logged it, had the necessary conversations, and now make sure to comment on how bad it is each time my testing ends up touching it. For now though, I have to wait for it to go through its life cycle.

Keep in mind that depending on where you work they may have other names for any of these statuses. Also, at any time you can Reopen a bug, if you find that the fix the developer made isn’t working. I’m not including it below as you simply Reopen, or push back, as needed.

• Bug/Defect is discovered and logged
• Bug is assigned to a developer, or a status that is waiting for developers to work on
• Open, or In progress – when a developer is working on a resolution for the bug. If the bug is determined to not be a bug, or it’s a duplicate, it is handled here.
• Fixed, or Ready for Testing – this is when the developer has finished their fix, hopefully tested it on their machine, and moves it to a status for QA to test
• Functional testing – it could be this status, or read for QA, etc, but this is where QA gets the fix for the bug and re-tests it, to verify it’s fixed. In this status you are generally just testing the function of the fix.
• Verified, or Ready for Integration Testing, etc – this is where you move your bug when it passes functional testing and is then ready to be tested with the rest of the app, in a regression and smoke test, as well as re-validation that it works. This is generally done in a stage environment.
• Deployed – this is where the code is in production and ready for a smoke test
• Closed – once a bug has been verified in production you want to be sure to close it, or have bugs set up to auto-close after a certain amount of time after they’re Deployed

So, again, these could have different names at different companies, but the important part is to understand the general steps and process behind getting a bug fixed.