Day #4: Bug Writing: An Introduction

Bug writing is the most common day-to-day communication you will have with the rest of your development team. Make sure you are an expert at it.

In Day #1, we looked at the flow of the testing process and your role in it.
In Day #2, you learned how to execute tests and unearth bugs.
In Day #3, you learned how to define and quantify your bugs.

Now in Day #4, I introduce how to write a bug

A more detailed, step-by-step explanation of each of the critical parts of a bug and can be found in the courses 10 Critical Elements of a Bug and 5 Keys to a Bulletproof Bug, but let’s start with a basic introduction to bug writing. Below is your beginning guide to bug entry.

So you’ve found a bug and have determined exactly what steps to take to reproduce it. Now you get to enter it. A very important part to keep in mind when you write bugs is this: You are about to communicate to someone that their creation, their baby, is not perfect. The way that you communicate this is very important as you strive to build a relationship of trust with other members of your team.

When you tell someone that there is something wrong with the work that they have done, they may become defensive. The first reaction that most people have (yes, even developers) is to claim that they have not done anything wrong at all.

There must be something wrong with the way that you have used their creation! Their creation must be error-free. That’s what they get paid for and they are extremely good at what they do (their degree on the wall says so, doesn’t it?), therefore the problem must be you.

By writing a bug in the bugbase, you are telling not only the developer that something is amiss with what they have created, YOU ARE TELLING EVERYONE!

You have created a permanent record in a database, that the entire project team uses, that documents one person’s (potentially) perceived shortcomings. When this happens, the developer can become very defensive toward you and may not trust your work in the future.

In order to avoid this type of reaction, you need to communicate issues with objectivity. Your bug writing must be a statement of fact, assigning no blame, and clearly stating the behavior you expected to encounter – which is clearly documented in the specs used to create the test cases you are executing.

If after entering a bug in this way you still get a defensive or otherwise unkind response, respond with objectivity, clarity, and politeness. No matter how snarky a response you get to a bug you have written, be nice.

If someone responds to your bug by writing that it is stupid, be nice. Never get caught up in any personal debates or attacks in your work. Respond as a professional even if the person you are dealing with won’t. Be a professional and be nice.

Open your bug writing template and begin writing your bug. Start with the Brief Description. Your Brief Description should be a concise, one sentence description of the issue.

Then you move onto the body text of the bug and write your Expanded Description. Here you will use as much verbiage as necessary to clearly state the issue you have found.

Next, write the Setup. In the Setup you will explain any circumstances that must be present before anyone attempts to reproduce the bug.

Now you will write your Steps to Reproduce. Clear, numbered actions that the person reading your bug will take.

After the Steps you will write your Result. This is the issue at hand. This is what happened.

The last part of the body of the bug is your Expected Result. Here you clearly state what exactly should have happened and, if appropriate, why.

At this point you should have a complete bug. So what do you do? Run a check on your spelling. This cannot be overlooked!

Bug writing best practice tip: Always check your spelling and grammar.

Any detail to which QA does not pay proper attention casts doubt on the rest of QA’s work, so ALWAYS SPELL CHECK. Few things look worse than a bug that QA has entered that has spelling mistakes throughout it. This is a preventable mistake – don’t make it.

Fix any errors that are identified by the spell checker. And now…

Once you have written your bug, go back and review it. Read over it to see if there is anything missing or if you included information that should be removed. Think “less is more”.

As you read over it, make sure that you have a clear, succinct Brief Description. Make sure that your Expended Description makes sense. Is your bug writing getting any better yet?

When your spell check is complete, copy the bug from your word processing document (the bug writing template) into your bugbase. Once you have done that, select the correct Reproducibility, Status, Assignee, etc. and, voila, you are done entering this bug.

During your first week or two on the job, it’s a great idea to have your lead (or another very experienced tester, perhaps even your manager) review all your bug writing before you submit them. Once they give you the green light, submit your bug! Then onto your next tests.

There it is! Your first foray into bug writing. Please remember that this is just an introduction, but should be enough to introduce the idea to you and help you begin to understand the importance of writing your bugs like a professional.

So far you have seen the process (Day #1), learned how to execute tests (Day #2), defined and quantified your bugs (Day #3), and been introduced to proper bug writing (today!). You may think that’s the whole deal: You know when to test, how to test, and how to enter a bug that makes sense. What else is there?

Tune in tomorrow to learn how to cap it all off and position yourself above the rest of your testing brethren. In Day #5 I will show you how to show off all the work you just did and create the (accurate) perception that you are an elite Quality Assurance professional. That you are destined for greatness and that any company would be lucky to have you.

See you tomorrow…