REACT to Bugs (Assert.This)

On October 18, 2016, in Syndicated, by Association for Software Testing

React (kill it with fire)

The most common artifact that testers produce are bug reports. So what do you do when you actually find a bug?

You react, here’s a mnemonic that may help your process…

R eproduce

The cornerstone of proving a bugs existence is if you can track down steps to reproduce it. Like ghosts, bigfoot, or aliens people need to be able to witness the bug for themselves to become believers or resolvers.

The process of identifying reproduction steps is valuable for testers as well. It forces you to reflect on your actions and what you are seeing.

E xplore

You’ve gone from the inkling of a problem, to tangible problematic behavior. It’s easy to get wrapped up in the hunt, before you race to log the issue in your bug tracker of choice, take a minute to survey your surroundings.

It’s not uncommon to find that the particular bug that you’ve just found is just a specific case of a more systemic problem. A bug report filed in haste may just beguile the state of your testing and when th root cause is identified undermine your credibility. The surface level bug just becomes a clue in a deeper more focused investigation. This may result in less reported bugs, but they will have greater impact and give greater creedence to your feedback.

A nalyze

At this point we have a good idea of root and scope of the issue. Take that information and start quantifying its impact and severity. How likely is a customer to uncover this problem? How widespread will it be? Do I need more information?

Testers are more than just reporters of facts, part of the role is being an advocate for both users and quality. How you plan to present the information about the issue impacts its reception by your team and management and therfore the likelihood of its resolution.

C ommunicate

Here is where we actually report the bug. We’ve done all the critical thinking and are ready to present a cogent representation of the issue and its impact. This allows stakeholders to make an informed decision.

This process extends beyond simily entering information into the bug tracking system. It can be sharing status at the team standup, or walking down to a developer or product person to discuss the issue.

T riage

The job isn’t always done after a bug is reported. Testers continue to assist in the prioritization, recognition of duplicate issues, and gathering additional information or answering questions to clarify the issue.


Comments are closed.

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!