1. Home
2. Blog
3. Common Mistakes that Entry-Level Testers Make - part 2

In the first part of the article we talked about writing a correct description of defect summaries. In the second part we will look at a few more tips and tricks about improving the way we write a defect summary.

Be brief, but not too much.

Don’t forget that the summary is a brief description, so you don’t need to write a short essay in that field. Generally, 7-10 words would be enough (excluding prepositions and articles). But don’t go overboard – you won’t be able to describe a bug clearly with 1-3 words.

Get rid of filler-words, don’t waffle.

For example: "The opening of each new image when viewed on a new tab.”
Too many words, but only a symptom is described, and obscurely at that.

And the point here is that each image, when you click it, will open in a new tab, which is not very convenient and does not meet reasonable expectations of users. The same thing could be expressed in a shorter and clearer way: "On click each image opens in a new tab."

It would be also good to specify in what section of the site that happens (obviously not in every one).

Another example:
"Entering the purchase section on the site, an error occurs when trying to give feedback.”
“Approaching the train station, my hat flew away.” Avoid dangling participles. If you feel unsure about participial phrases, don’t use them. And better avoid bulky constructions.

Adding "on the site" is absolutely unnecessary. All bugs arising in the project software relate to that site, so why mention it in the defect description?

Cut it down:
"Error when trying to give feedback." What kind of error, by the way? It would be good to identify it somehow – class, code… There’s no need to reproduce the full error message in the bug summary.

Reporting bugs with obscure titles creates difficulties for the testers themselves. Before logging a bug, you should make a search in bug-tracking system to ensure that it is not a duplicate.. Here we need short, clear, and unambiguous titles of defects.

2. Absence of expected results

When testers log a defect, they sure have an idea of what should be right. But there’s a catch: developers, like all other human beings, are not mentalists! And if expected results are not explicitly described, there’s always a chance of misunderstanding.

There is also another risk. The developer may make their own conclusions on what should be right, then “fix” the code and send it for verification. Now controversy would arise: “It’s corrected!” – “No, it is not!” - "But we have made changes here!” – “There was no need to do that!” As the result you have wasted the time and efforts of several people...

It would be much easier to explain in the very beginning what outcomes you expect. Even if it seems obvious and clear for all. One of Murphy’s laws says, “Everything that can be misunderstood will be misunderstood." I would advise neophyte testers to make it a habit to always describe expected results explicitly. (It would be even better if you can support your description by a reference to a specific requirement.)

3. Unarticulated steps of reproduction

It’s a commonplace to say so, but you’d better describe steps step-by-step: one line – one step, numbered or unnumbered, as you wish. Do not write everything in one long paragraph, heaping up when, while, which, then, etc. Looking at such a long and sophisticated sentence, it would be difficult to reproduce the bug. Even a very simple thing could be overcomplicated, if you describe it like that:

"When purchasing products, when you press a button to buy, pop-up window, which when pressed to continue shopping, throws on the orders page"

This can be well described as follows:

“Continue shopping” button redirects to “Orders” page”

Pressing the button must not, of course, redirect you to the order page, the user should remain on the initial page to continue shopping. Such details can be specified in the description.

4. A screenshot instead of the actual result

Of course, it’s very useful to add screenshots to defect descriptions, especially those that describe UI problems. But! No screenshot would replace an intelligible textual description.
"Actual result: "Request failed validation (see screenshot)"

It should not be done like that. Judging by my experience, I would say that a situation where you can’t describe the actual result with words is extremely rare. Yes, I have come across some bugs that needed video to illustrate the problem. But that happened just a couple of times in 10 years. If you have some difficulties, then perhaps you don’t thoroughly understand what is happening. A screenshot is always an additional source of information.

By the way, in that case, if you lost the screenshot for some reasons, it would be impossible to find out what the bug was about.

Sometimes, a screenshot itself needs to be improved, the more so if the interface is complex. Occasionally, you have to peer into the screenshot for a long time to see where the bug is. Draw an arrow, circle or underline it to point to the place where the bug appears. Or it may be better to cut off unnecessary elements and leave only those that are useful to show the bug.

Generally speaking, testing can be viewed as an information service: our task is to provide clear and unbiased information about the product quality. To identify a bug is not enough; you must be able to describe it correctly. Therefore, testers need to be capable of expressing their ideas in a logical, comprehensible way, in a few words, but precisely.

To be continued...

Victoria Slinyavchuk
Consultant on Software Testing