10 Skills of Elite Testers: Day #2

Because this is such a critical component in the quest to be an elite Quality Assurance Professional, I cover the subject of bug writing from multiple angles. Today we focus on a holistic view and identify the most important actions to make into habits when writing bugs.

We offer two additional courses on bug writing that will go a long way in enhancing your skill. The first is the 10 Critical Elements of a Bug where we present an overview of the anatomy of a bug. With this information, you are armed with the knowledge to understand the second course 5 Keys to a Bulletproof Bug.

In 5 Keys to a Bulletproof Bug we go really in-depth with the five most important parts of a bug. If you understand the anatomy of a bug and then learn how to make yours bulletproof, every bug you write will show your value time and again, day after day.

Today’s bug lesson gives you the habits you need to practice until they are second nature. Take these actions to heart and you will be on your way to writing bulletproof bugs.

Skill #2:
Bulletproof Bug Writing

Since entering a bug is something that you will be doing for the majority of the days that you are testing, this is the communication that will be seen the most often by all of the members of your project team. Because of this, you will be judged (fairly or not) by your skill at writing and entering bugs. The best feedback you can get with your bug writing skills is for someone to say “that was a good bug!” “That one was a good find!” This doesn’t happen very often, but is rewarding when it does.

The most common reaction to a bulletproof bug is almost no reaction at all. The bug is reviewed and then, without question, the conversation turns to what to do about the bug; whether the project can withstand the cost and risk of fixing it. There is no recognition of the bug other than what to do about it now. Although no praise is spoken, this is a great result! This means that there are no questions about what you wrote, only what is to be done about it.

Once you can do this consistently, you will have achieved something that many testers I have seen have never accomplished. You will have become a trusted member of the QA team that can be counted on to do their work right the first time. You will be someone whose work is not questioned by other competent project team members.

You will have built trust in your work and people will want you to test the most critical parts of the project. This is a key in being viewed as a true Quality Professional! Be viewed as a professional and you will gain respect for yourself and your QA team.

Keys to writing a bulletproof bug:

So first, always check with your team and then in the bugbase to be sure that the bug was not entered previously. This will prevent the developers wasting time attempting to fix an issue that has already been fixed.

It will also prevent you, the tester, from having to test the same bug multiple times just because someone didn’t do their work properly the first time. Don’t waste your time and the company’s money duplicating your effort.

KISS
KISS stands for: Keep – It – Simple – Stupid. I didn’t invent this, it is a long-standing principle and is as true today as ever. As you write your bug, do your best to write it as clearly and as simply as possible.

Projects and testing become complicated enough on their own with their changing schedule, mutating features, late deliveries, prioritization meetings, etc. Make sure that your bug is an oasis of clarity among the complexities of the project.

Your bugs should be a welcomed respite for people to read and fix amid the confusion that will ensue in other parts of the project.

Include An Unquestionable Reproducibility
I cannot stress this enough: Make sure that the Reproducibility you state in your bug is accurate and complete. Your bugs should have as a Reproducibility (as often as possible) of either Always or Intermittent. If your bug does not always happen, ask yourself: Did I do all of the work I could to determine for sure that this bug is Intermittent? Do your best to verify the Reproducibility you state in the bug.

If the bug is, indeed, Intermittent: You must state how intermittent it is. This can be stated as a percentage, but only if you include the “X-out-of-Y”. The out of . Lack of clarity in this area can lead to people not understanding the true risk involved in fixing or not fixing the bug.

Make Your Expected Result Crystal Clear
Your Expected Result needs to state the exact behavior that you had anticipated experiencing. With this expectation clear, it will be easy for anyone to understand exactly why the issue you entered is, indeed, a bug.

It may also point out where documentation is incorrect or incomplete since the test case you were running when you encountered the bug was based on some documented requirement or described behavior. If this is the case, then your bug may not be a functional issue at all, but instead a documentation issue that needs to be resolved.

For added emphasis, cite the requirement and/or document from which this bug has arisen. In this way, people can check the veracity of your bug against the documentation, and not against how thoroughly they believe you did your job.

Send them to the specs instead of asking them to challenge their beliefs – this is a much more successful route to having questions answered. This will also help pinpoint where the documentation is in error or is incomplete.

Always Spell Check
You may notice that I have mentioned this several times and here it is again: ALWAYS SPELL CHECK! It is easy, it takes only a few seconds, and it helps make you look like you know what you are doing.

A bug with errors in it, whether they are incorrect steps, an inaccurate result, or spelling mistakes, always make you appear as though you did not do a complete job. If you want to be viewed as a Quality Professional that can be counted on to be aware of even the finest details, you must ensure that you attend to those details. This includes spell checking your bugs.

Trust me…just run everything you type (bug, email, or report) through spell check. You can email me with the story of the first time you get caught not spell checking a bug if you like. Everyone forgets this eventually when they are under pressure from deadlines or a screaming, hyperactive boss, but the great ones don’t make this mistake more than once a year.

Do yourself the favor and…spell check everything you write – THIS INCLUDES YOUR BUGS.

Review Before Submitting
After you have written up your bug, go back and re-read it. Look for information that can be removed without compromising the integrity of the bug.

Once you hit "Submit" or "Enter" and your bug becomes a permanent record in the bugbase, you may not have a chance to edit what you originally wrote. So, read through your bug before you submit it and make any last minute adjustments that you think would help. Below are a few suggestions to keep in mind as you review your bug.

When reviewing your bug before you submit it:

• Think “Less is More” – can you make it more succinct?
• Make sure you haven’t left out any Setup or Steps
• Be sure you have included an accurate Reproducibility
• Does what you have written make sense?
• Do you need someone else to read it and give you feedback?

Once you are adept at writing and submitting a bug that no one questions, you will have enhanced how others on the project team view you professionally. They will become accustomed to the reliability of your work and how you report your data.

This is the most fundamental step for a Software Quality Assurance Tester. You must gain the trust of the developers and managers on your project so that they will trust you in helping to create solutions instead of questioning the validity of your bugs. Master this discipline and you will be well on your way to excelling as a Quality Assurance Professional.

Continuous effort--not strength or intelligence--is the key to unlocking our potential.
~Winston Churchill