At Testuff, we talk a lot about finding defects. But what about fixing those bugs after you’ve found them?
If you regularly follow this blog, you already know how we feel about this topic:
- “Fixing” defects is the developer’s job (exclusively).
- “Finding” bugs is the tester’s job (exclusively).
And it’s best if these 2 hemispheres are kept separate.
But does that mean testers should remain idle after discovering and reporting bugs?
Are they completely out of the picture until the problem is resolved?
In a perfect world, the answer would be “yes.”. If the reporting is done as it should be, testers shouldn’t have to do anything else, until the defect is fixed and the fix is returned for validation, and additional testing.
But we don’t live in a perfect world. And it’s not uncommon for software testers to play a secondary role whenever developers need help recreating issues on their end.
And here’s why that matters…
If a Bug Can’t Be Reproduced, It Can’t Be Fixed
The ability to reproduce bugs isn’t simply a “nice to have.” It is arguably the most important aspect of the entire testing and development process.
And yet, many testers gloss over this step by providing vague feedback like “the login doesn’t work.”
Unfortunately, this isn’t enough. As a software tester, you need to include the exact steps for every bug you find, including:
- Whether the login link is at the top right or in the sidebar widget.
- Whether there was an error message or simply a blank screen?
- What usernames, passwords, and other credentials you used.
- What browsers, operating systems, and devices you tested on.
Sound like overkill?
Maybe. But the hardest bug for a developer to fix is the one that he can’t recreate. And the best way to illustrate this is to temporarily remove reproducibility from the equation.
This is what happens:
- Developers waste time trying to recreate problems on their end. And as a result, they open doors that don’t need opening (and leave doors closed that should’ve been opened).
- There’s more “verbal” back-and-forth between developers and testers. This is a waste of time and money that often leads to redundancies, more errors, and gaps. Worse still, unnecessary communication can actually create “bad vibes” when teams aren’t seeing the same thing from their respective vantage points.
- The testing process becomes hastier, with many QA professionals documenting problems without carefully exploring the underlying causes. Note that it is not the tester’s job to fix these problems per se. But anything he sends forward should be reproducible on the other end.
Without the ability to reproduce bugs, there really is no point to testing. The process becomes subjective, wasteful, and costly. This is especially true when working with remote teams in different time zones. You’ve got to wait until the next day to ask questions – or have those questions answered.
The One Thing That Software Testers CAN Fix
We opened up this piece by stating that software testers shouldn’t get involved in the “fixing” process.
But there is at least one thing they absolutely can (and should) fix. And that’s how they choose to report the defects they find.
Instead of vague feedback, you should provide the clearest possible documentation that you can:
- Written step-by-step instructions is a good start – especially if you include testing conditions and other background information.
- No developer will ever get mad if you send chronological screenshots of each bug.
- Video documentation is arguably the most useful reporting tool. With screencasts, you can walk developers through the “bug creation process” – from start to finish.
Providing this level of documentation takes time. And it’s not always easy to put yourselves in the developer’s shoes. But the benefits of this detailed approach include:
- Less confusion
- Fewer questions
- Faster fixes
- Greater team cohesion
In addition, better reporting offers a faster route to validation – i.e. the point where fixed defects are returned for testing to ensure the original problem has been resolved (and no new ones have cropped up).
Do you agree with these insights? And have you ever discovered a better way to document and report bugs for your development team?
We’d love to hear your thoughts. Feel free to share your experiences down below.