Common Mistakes that Entry-Level Testers Make - part 1

While teaching people who are just starting their way in QA, I now and then come across typical mistakes they make. In this article I would like to analyze some of them and give some advice how to avoid such common mistakes.

First of all, let’s discuss how to document defects. Since this is the most common artifact in the testing process, any tester must be able to document bugs correctly. You can do without test cases, but not without defects.

1. “Empty” Summary

A lot has been said about how you should and how you shouldn’t write defect titles, but novices keep making the same mistakes. A common recommendation is that a defect title should answer three questions, "What? Where? When?" .The advice is very good, but why is it so difficult to follow?

So, the first thing you should keep in mind is that the defect title must describe the heart of the problem. You often do that with a sentence built according to the rules of whatever language you use. Remember your grammar lessons? What is a sentence?

"A sentence is a textual unit consisting of one or more words that are grammatically linked and express a complete thought."

In general, a brief description (summary) of a defect must answer the question, "What is wrong?" or, in other words, "What is the problem?" The title itself should contain enough information for the reader to get an idea of the issue. To make it understandable, at least in rough terms, you should give an answer to each of the three questions in the title:

"What?" – You should at least describe the software behavior that you believe to be incorrect, non-compliant with requirements/standards/expectations. Roughly speaking, this is a symptom.
"Where?" – In which part of the product or system (module, page, feature)? Let’s call it location.
"When?" – That is, under what conditions the defect is reproduced. This is a trigger.

Look into some examples of defect titles to see whether they reflect the essence of the problem.

“Incorrect Site Search”

What is this description about? We can only see that the defect is somehow related to certain a functionality, namely the site search function. It answers the question "Where?" But what is wrong with the search function? How does the incorrect behavior manifest itself? It’s a head-scratcher. Under what condition is the defect reproducible? That’s another head-scratcher.

Here’s another summary of the same bug: “The result of the action of the empty site search”.
You are getting hotter... We can understand what function the bug is related to and even identify the conditions under which it is reproducible. But not a word about what goes wrong. Just "the result" – some result without any specifics... And this should be the most delicious thing!

To understand the problem, one has to read the full description and then try to reproduce the bug. In case of an empty search request, in front of the product list there appears a window with category view in which one image is too large and does not fit in the UI. You can briefly describe that in the summary as follows:
“After empty search request too large image is shown in “category-view” div.”

Of course, a screenshot should be attached to the bug description.

Yet another example:

"comment".
Yes, just like that... One word that hints to a functional area.

It would be more comprehensible like this:

"Fatal error:463 on attempt to post review at product description page."

"broken layout"
This describes a symptom, an incorrect behavior, so it could be viewed as an answer (very rough though) to the question "What (happens)?" But where exactly does it happen? On what page? On any page? It’s not clear. And what is to be done for the layout to be broken? Not a hint.

The correct brief description of the same bug:

“On 150% zoom images at all pages are superimposed”.

And one more example:
"Registration with invalid email."

Perhaps, this title would do for a test case. It’s clear what feature the bug refers to – “registration”, and we know the trigger – “invalid email” (of course, it should be clarified what the word “invalid” means here). But what is the bug about?

A more correct description would look like that:

“Registration is possible with invalid email address”

Or

“Email is not validated upon registration.”

In the second part of our article we will look at a few tips on how to write good defect summaries.

Victoria Slinyavchuk
Consultant on Software Testing