The Struggle

Tell me does this sound familiar:
[Dev]”Hey! I can’t reproduce this bug on my local end. So bug rejected”

[Me] „Did you try test2.env.com? I was testing it there.”

[Dev] „You didn’t say that in the bug!”

Or this

[Me] „Hey This bug was on all paths on some specific one?”

[Tester 2]”I don’t remember that… Probably it was on all of them”

[Me] „Do you remember what was this bug? I can’t figure it out from the report.”

[Tester 2] „Not sure I think it was, {here goes semi-accurate description of issue}”

We all make mistakes.

When devs make a mistake, there is a bug in the software. When Testers make a blunder in a bug report, it gets rejected.
I have seen quite few bug reports, both during work or while interviewing testers. And I could point quite a few technical issues with them; I found out the cause is a combination of those three reasons bellow:

Inexperience:

This one is obvious If you don’t know how to write a bug report, you will write few rotten before you learn but I am here to give you few hints.

Laziness:

Sometimes we are too lazy to write the proper full bug report. Or even to reread what we have written. It happens the only remedy for that is realizing how many problems and wasted time it will create.

Wrong Assumption:

This one is most dangerous one! There is a lot article why an assumption is dangerous (not only for testers). And they are correct; assumptions are our bane.

Few examples of a poor assumption that may occur when writing a bug report:

We Assume that:

Devs know what we are talking about.
We will remember how to reproduce this bug.
Generals steps will be enough.

Assuming something is my biggest sin as the tester. A few years ago I realized how many of my shortcomings could be traced back to wrong assumptions. Now I am trying my best to „Assume Nothing when it comes to testing.” Of course, it is not easy I am still often catching myself assuming things – no matter if they were wrong or right.

How to improve your bug report?
I won’t teach you how to write a bug report. Look at your bug tracking tool and what fields you must fill in it. It is a good start.

Here I have 4 Pieces of advice for you:

Don’t assume anything, Good Title, Pictures/animations and Kiss.
We talked about Assumptions already so let’s move to

Title

It is most important part of the bug report. It is visible to the biggest group of people, so it has to present as much information with as little words as possible.
It should be short and answer three questions: Where it is broken, What is broken? And What happened? WWW for short.

[Testenv] Search Service returns result ignoring,
prize range filter in the query.

Where?: [Testenv]. – In most bug tracking tools, there is a separate field for that. But even then you should add it to the title so it could be visible without opening bug itself.

What broke?: The search engine.

What happened?: It ignored arguments for filtering price range.

Is it ideal? No, I would prefer it to be shorter, but it is not always possible.

Pictures/animations

„One Picture is worth a thousand words. ” And an animation is thousand of pictures.

This part is obvious, but I noticed some of us are too lazy to do that.

And it is a shame since we have so many useful tools: Lightshot, Jing, Screen to gif, the list goes on….

But having screen shot is not all it has to be a good one! And tools come with the help too! They allow you to select exactly part of the screen you need. Most of them have simple image edits so you can add your highlight. And this is important it helps to focus the attention of people that will read this bug.

Gifs and Flash animation are also useful, but they have one problem – size. Some of the bug tracking systems have a problem with the too big files.

But if you know what you want to record it shouldn’t be a problem which leads us to next point:

KISS

Kiss stand for „Keep it simple stupid.” It is Engineering principle nearly as old as computers. Convinced by Designer of SR-71 Blackbird – Kelly Johanson.

It means that beauty is in simplicity. If it is simple, it is easy to understand. And this is what we want from our bugs.

How to achieve that? Well, I have bad new for you. Hard work and learning how to write (and believe me as Dyslexic I tried everything else first.)

But there is one thing you can trim first before we start editing our text.

It is our understanding of bug.

Let take our example from The Title section.

You were doing some smokes, on Website of your shop.

And you noticed that on search page results are wrong.

You try to reproduce it – success same search input same bad result.

Title: Search is not working correctly

Repro steps:

Go to a search page.
Search by, good book, range 1 to 100 euro, fantasy,
The prices of returned book are wrong.

Well at this point you could leave it in this form, or you can dig deeper.
First, do some other test to see which criteria is broken.

It turns out the problem is only with range.

Title: Search Price Range filter is not working correctly

Repro steps:
 Go to a search page.
 Search by, range 1 to 100 euro.
 Bug On search result page there are books more expensive than 200 euro.
 (order by highest price to find them easier)

But is information about Search result page good enough? Where is the problem? Is search widget broken and doesn’t send proper parameters? Or search service? Or is something wrong with search result page? (Unlikely but I’ve seen that)

So after using fiddler, we see that it is not our search widget – it creates proper rest API request.

So since we have Fiddler open let’s see a response. Bingo!

To be sure let do our test using postman.. – result reproduced!

Title: Testenv] Search Service returns result ignoring,
prize range filter in the query

Repro steps:
1.Send GET Request with price range arguments
example: api.search.testeng.com/?from=1&to=100
2. check response
Bug! There are books with price bigger than 100.

Service belongs to another team. So we will finish here.

Bug Report is necessary.

I believe that bug report is most important test artefact, definitely most used. So we need to make sure it is good.

But unfortunately great bug report cost time, but bad bug report cost, even more, time. My advice it takes you time especially while you learn.

With an experience, you realize where you can cut. For example, not all bugs need detailed „repro steps.” Some can go just with title and screenshot (for example typos). The other will live too short to even bother writing them down (although this is an easy point to make a mistake)

But there is one point when you can’t cut your time, making sure that bug does exist. The false positive bug is wasting the time of developer that tries to check what going on. It will also hit your credibility.

So to sum it up:

Title. Pictures/animation, kiss and Don’t Assume anything.