How to describe similar bugs or the same bug in different browsers

Sometimes there are situations when the same bug is encountered on different pages or the same type of bug is shown in different places in the application or on the site . If you'll describe similar issues as separated bug reports you can take up a lot of extra space in the bug tracker, confuse yourself and the developers, or spoil all the statistics of the defects.

Similar bugs in different places

During testing of both sites and applications, you can encounter several defects of the same type. For example, if you change the localization, some elements are not translated or the text goes out of the allotted area.

Let's consider these situations in detail:

1. Some elements are not translated after changing the localization.

As we can see in the screenshot, after switching the  language of the  site to Russian, the section titles and banner text are still displayed in English. This is a great example of a localization bug. In this case, it would be better to group the elements into separate blocks (a block with section buttons and a block with banners) and create one bug report for each of them:

• The names of the «Women», «Dresses» and «T-Shirts» sections are not translated on the main page of the site after switching the language of the site to «Russian».
• The text of the «Excepteur occaecat», «3 Days sale» and «Only online summer» banners is not translated on the main page of the site after switching the language of the site to «Russian».

If the items with a defect are located at a certain distance from each other and cannot be grouped, then you can create one bug report for one such item and in the «Description» field specify another element with the same bug on this page. Attention! If there are several or quite a lot of such elements with the same type of bugs, then their list is indicated in the «Additional information» section. For example:

Summary: The cursor is not changed to the «Pointer» on the main page after hovering over the «Feedback» button.

Description: The cursor is not changed to the «Pointer» on the main page after hovering over the «Feedback» button. The defect is also reproduced for the «Add to cart» button .

or

Summary: The cursor is not changed to the «Pointer» on the main page after hovering over the «Feedback» button.

Description: The cursor is not changed to the «Pointer» on the main page after hovering over the «Feedback» button. 

Additional information: The defect is also reproduced for the «Add to cart» and «Favorites» buttons.

2. The text is shown outside the allotted area.

The screenshot clearly shows that the text of the «Toista panos» and «Toista panos x2» buttons is shown outside the allotted area. In this case, it is not necessary to report separate bug reports for each individual item. It is better to create one bug report where you should list the found items with defects:

• The text of the «Toista panos» and «Toista panos x2» buttons is shown outside the allotted area on the «Table» screen after switching the language to «Finnish».

If the defect is reproduced for several languages, or for all except one of them, then in the «Additional information» section they must be listed or this information must be briefly stated in one sentence. If the bug is reproduced only for one language, in this case the selected language should be specify in the «Preconditions» (added in the «Steps to reproduce» section before the steps). The «Additional information» section can be filled in as desired. For example:

Summary: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.

Description: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.

Additional information: The issue is reproduced with all languages, except English.

or

Summary: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.

Description: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.

Preconditions:  English language is set on the site.

Steps to reproduce: 1. Open the site...

Additional information: The issue is reproduced only with English language.

Let's also consider one of the typical mistakes that beginners make. Pay attention to the location of the «Cart» button. The element is not aligned both horizontally and vertically. Look how you should write it in the bug report:

• The «Cart» button is not aligned horizontally and vertically on the main page.

We described the whole bug report in one sentence, short and clear. Do not report bugs separately for horizontal alignment and separately for vertical alignment.

What if the bug can be found in different browsers?

Sometimes there are situations when the same bug is reproduced in different browsers or on different operating systems. What should be done if the bug is encountered in different environments? You just need to list all browsers/devices/OS in one bug report where the bug is reproduced in a separate «Environment» field if any or in the «Additional Info» field. For example:

Additional info:

Environment: Safari 4.1.3 IE 11.435 Chrome 43.567 (56)

If the same bug occurs in several places, the solution is also extremely simple. The «Additional Info» section contains a list of pages where a bug was found, for example, in case of defects in the translation of site elements into the selected language. For example: The «Login» button is not translated and appears as the «Enter» on the «Register», «Menu», and «Search» pages. On the rest, it is displayed as translated. If in the steps we indicated how to reproduce the bug, for example, on the «Search» page, then in the «Additional Info» you may see: The bug is also reproduced on the «Registration» and «Menu» pages. It should be understood that you can combine several incidents of the same bug into one report, but it's better to create one bug report for one bug. 

Let's revise the basic concepts while reporting a bug:

A bug is a discrepancy between the actual result of the program execution and the expected result. Defects are detected at the software testing stage when the tester compares the results of the program (component or design) with the expected result described in the requirements specification.

A bug report is a document describing a situation or a sequence of actions that led to the incorrect operation of the test object indicating the steps and the expected result.

Bug tracker is an application designed to help the software developers to  take into account and control bugs that were found in programs, user wishes, as well as monitor the process of fixing these bugs and fulfilling or not fulfilling suggestions.

Bug attributes in the bug tracker:

ID is a unique identifier for the bug in the bug tracker. It’s automatically assigned by the system.

Summary is a short and concise description of the bug answering the question «What? Where? When?»

For example: «The «404 Page not Found» error message is shown (what?) on the «Contact us» page (where?) after clicking the «Contact us» link (when?)». That is, the description of the bug should be such that the developer could not even open it but immediately look for the bug. But more often, there are still complex bugs that require descriptions inside additional actions and explanations of how to reproduce it and how it really should be, so it can be difficult to understand the problem only from the Summary. Therefore, there are the following fields below:

Preconditions are a field where usually written what needs to be done before reproducing steps. Also, you can specify the data for steps to reproduce (login and password, link, product ID, etc.). For example, you need to create a special structure or users with different roles needed to reproduce this bug.

Let's imagine that the essence of the bug is that a newly created administrator cannot enter into the admin panel with the valid data, but old admin users can. So, in this case, you should write in the preconditions that you need to create a new admin user.

For example: «A new admin account is created».

Steps to Reproduce

The field is used to describe the steps to reproduce this bug.

For example:

1. Open the login page of the admin panel
2. Enter the valid credentials into the «Username» and «Password» text fields
3. Press the «Enter» button.

That is, this field describes the detailed steps until the moment when the bug is reproduced. After the last step, we should see the result which is a bug in this situation.

Actual Result – describes what result was obtained after the last step. For example, it can be described like this:

The «You have entered incorrect user or password» message is displayed on the login page after entering valid credentials

Expected Result – the correct behavior of the system after the last step. It seems that this field is not important, but the system can be performed correctly, but not meet the stated requirements described in the documentation or provided by the customer. Therefore, it is necessary to indicate the expected result of the system operation.

Priority – a service to determine the priority of the bug and is usually set by the project manager, thus determining the priority of fixing the bug against the rest. In different bug trackers the priority can be determined by different levels (from «Immediate» to «Low», or numbers from 1 to 4), the principle from the highest priority to the lowest. Some trackers may not have such a field at all (for example, Pivotal tracker).

Severity – indicates the severity of the error in terms of impact on the software.

There are several levels of error severity, such as:

• Blocker. The bug blocks further application operation or blocks further testing. For example, after creating a user, any user cannot log on to the system with an existing name since an SQL error is displayed on the main page and prevents all attempts to log in.
• Critical. The bug has a significant impact on the operation of the software but does not block its operation. For example, a user can log in without entering a password.
• Major. The bug has a minor impact on the software. For example, the number of records in the list of records is not counted correctly.
• Minor. The bug does not affect the functionality of the software. For example, a grammatical mistake in the name of something.

Also, as in the case of Priority, different trackers may have different severity levels, but they all reflect the above essence. It should be noted that in many cases the Severity of a bug will be approximately equal to its Priority. But it is not always the case

For example:

• The company logo is displayed incorrectly or not displayed at all on the main page. This kind of defect does not have any effect on the functionality of the site, but from a business point of view it is very serious. As a result, we have the lowest severity and the highest priority
• A 404 error is displayed when trying to navigate to one of the sections of the site. It would seem that it is necessary to set the maximum Severity and Priority but let’s imagine that the project manager two days ago said that in the current iteration of work that functionality is not planned because this is not the most important functionality and there are more important tasks. As a result, Severity = Blocker but Priority = Low.

Assignee – a field that specifies the person responsible for fixing this bug. A project manager is assigned often and he already distributes bugs further, or a developer is responsible for the section where the bug was found.

Status – automatically set as «New» or «Open». Then it can be changed by the developer, tester, or project manager, depending on the stage where the bug is.

Also, you must add a screenshot / video to the bug report that shows the problem. At the same time, it must be remembered that the bug must be described in such a way that the developer can reproduce it without looking at the attachment.This is due to the fact that there are cases when problems arise while trying to view an attachment (slow Internet, limited traffic, service interruptions), and if the defect is described inappropriately it will block the developer's work to fix the error.