5 Keys to a Bulletproof Bug:
Day #1

Quality is not an act. It is a habit.
~Aristotle

We are now going to take this to the next level and get down and dirty with the detailed information you need to write great bugs. Below I describe, in as much detail as you will need, each of the 5 Keys so that you can master the art of writing high-quality, value-added, Bulletproof Bugs.

The 5 Keys to a Bulletproof Bug

1. Descriptions (brief and expanded)
2. Reproducibility (X-out-of-Y)
3. Steps
4. Result
5. Expected Result

Learn the importance of each Key and strive to understand how they work together to complement each other. Once you have an in-depth understanding of each Key and the interrelation of all the Keys, you will be on your way to knowing how to write a bug that your team will understand and respect.

Strive to practice as perfectly as you can. Soon these 5 Keys will be second nature to you and every bug you write will be unquestioned. You will be able to write any bug, at any time, about any issue that everyone can understand and trust.

As you read through this course, use the sample bugs that you can download from our Forms & Templates page as a reference. This will help enhance your understanding of what to write and how to write it as well as increasing your comprehension speed.

Let’s look at each Key, one day at a time.

Key #1: Descriptions

Brief Description

Remember, this is often the only information displayed when searching a bugbase until the user opens each bug one at a time. So make sure that anyone scanning a list of 500 bugs can easily differentiate the bug you are writing from every other one line descriptor.

If you find it too difficult to write this Brief Description first, use an old QA trick and write the Brief Description last. This may seem a little counterintuitive, but once you have finished writing the rest of your bug, it will be much easier to break it down into a simple description.

Practice improving the brevity and clarity of your Brief Description until anyone can easily understand the bug from just this one sentence. You will save your project team time and your company money if you are able to explain your bug in just one clear sentence.

Once you can do this with regularity, people will notice that your bugs are easy to understand and trust your work. This is because you will be saving everyone time in the many meetings they must attend to sort through all of the bugs. The less time they need to take understanding your bugs, the better. Be a professional.

Expanded Description

The Expanded Description should go at the top of the text field in which you are writing the main body text of the bug. It should be the first piece of information a reader sees when they open the bug and begin reading it.

Use as much verbiage as you need to clearly state the issue. Since the reader has already had a chance to scan the Brief Summaries of the bugs, this is the place you can explain the issue in more depth.

You may find that you will need to edit the Expanded Description before officially submitting the bug, but it is good to write out what the issue is to help keep you focused on what you are writing about.

Write clearly what the bug is. Just write it. Get it all out.

It is easier to edit a bug to have less information than to attempt to write the perfect explanation in the first place. So write out all that you need to. Once you are ready to submit the bug, review your Expanded Description and using a “less is more” mentality, delete or edit your text so that it is as clear and succinct as possible.