We’re starting a new blog series where we interview BBST® graduates and ask them to share their unique perspectives and experiences on a topic regarding the courses or their profession. Our objective is to let you, our readers, have more in-depth answers to the not-so-straightforward questions we receive.

One surprising thing we learned during this interview was that the Bug Advocacy course is among the BBST® courses with the most immediate impact on our graduates` day-to-day work. Not just because of the technical skills they’ve developed, but also because of the way the course has revealed their blind spots regarding the main deliverable of testing, the bugs they log. They talk about how they’ve become more confident, more effective, and less frustrated. Here are their answers.

Showstoppers are not the only bugs that matter

Bug Advocacy helped me advocate my bugs better and faster. Of course, you will think of those significant bugs, the showstoppers, hard to detect, with a massive impact on the project.

Well, for me, that was not the tricky part of my day. It is “challenge accepted” to find THAT bug and save the project, being a hero after a long battle, but it’s way tedious to investigate and advocate for bugs that don’t look like a showstopper. Bugs that seem like corner cases or with lower impact on users, for which the usual answer is that your take on it is subjective.

Just thinking that it would take more time to convince team members to fix it than the time needed to actually fix it exhausted me before I even started to write my report.

Coming back to the Bug Advocacy course, I was surprised to learn how to properly investigate and give strong arguments for the not-so-obvious bugs, that are not necessarily showstoppers, and tell their story.

New features vs. Bugs

Many new features in the upcoming sprint with many bugs forgotten in the backlog. Have you ever been here?

Before my Bug Advocacy class, I thought that all bugs must be fixed before releases, and I found bug deferrals disappointing as I felt my work was not valuable enough. Later on, I realized I was focused solely on my work and my perception of what a high-quality product is.

If I have to name just a few lessons learned in Bug Advocacy, they would be:

• Redefining quality as a subjective matter – Different people will have different views on quality depending on what they want from the product.
• Practice thinking in terms of customer satisfiers and dissatisfied.
• Keep in mind the scope of the release.
• The best tester is the one who gets THE RIGHT bugs fixed.

It works on my machine

One of the most difficult situations I have ever been in professionally taught me that finding a bug is just the beginning, and what you do next brings the most value to your team.

My situation was something like this: I found a bug, reported it, but the developer could not reproduce it and closed it. I would reopen it when from time to time, the bug reappeared; the developer would close it again, finding different reasons why it would appear only in my environment. The bug did not get fixed, and unfortunately, it was a critical problem that affected one of our three main customers in production.

Many things went wrong in that scenario, but one thing that could have helped me was asking why the developer couldn’t reproduce the bug. Getting into that discussion would have helped me realize that my description of the bug was incomplete. I kept reproducing the bug over and over again without trying to find out what was the actual underlying problem and what the critical condition was in fact.

Sometime later, I went through the Bug Advocacy course and learned about RIMGEN, a bug investigation guide that stands for: replicate, isolate, maximize, generalize, externalize and use a neutral tone.

If I were to use this framework, even the first three steps would have helped me a lot:

• Replicating – important as this step is, it was the only thing I was doing.
• Isolating – by trying to get to the shortest list of steps to reproduce the bug, I would have discovered precisely where the problem was and helped the developer reproduce it.
• Maximizing – by doing some follow-up tests, I would have realized that the bug is affecting many more components and would be a showstopper for our customers. With this information, I could have insisted more and prevented this bug from going into production.

RIMGEN has changed the way I look at problems and how I report them in a bug database. It helped me understand how to make my reports better, to offer relevant information with a good attitude.

I don’t need to appeal every bug deferral

Whenever one of my bugs is deferred and I do not agree, I think about this quote from the Bug Advocacy course “If you are going to fight, win”. While in the past I would fight for every bug, the course helped me understand that I need to carefully choose my fights, otherwise I will be in the same situation as the boy that cried wolf too many times and will lose my credibility.

My top three ideas that help me decide whether I have chances to win the fight are:

• Can the bug be Maximized, Generalized, or Externalized?
• Does the bug contradict any of the Consistency Oracle Heuristics, e.g the bug is an inconsistency with the vendor’s image, purpose, product history, claims, regulations, etc.
• If the bug is very minor, is the effort to fix it also minor to pay off its investment? In this category, I also consider that the bug should not be part of a bigger architectural change planned for the future.

The course taught me to put the correct light on bugs, not make them look more severe than they are, and not waste my and my colleague’s time arguing about a non-important bug when there are bigger priorities in the project. This attitude helps towards efficiency so the team can make the right decision whether the bug needs to be fixed or not. So, now when I have to advocate for a bug I think twice: Am I advocating for the right bug to be fixed?

If you face similar situations in your work, consider improving your investigating and reporting skills and join our next Bug Advocacy class. You will gain new technical skills and also the skills to provide highly effective and persuasive reports that help your team fix the right bugs. The spots are limited to ensure an interactive environment and hands-on approach, so book yours right now.

Do you have other curiosities about our courses or the software testing practice you want our graduates to answer? Let us know in the comments or send an email to contact@bbst.courses.