Avoid complex sentences and participial constructions. Divide the sentences into parts.
Take a less number of obvious actions. For example, you are testing a graphics editor. It is available on the “Edit and View” page. In the bug report, you can omit the obvious steps:
- Log in to the site.
- Go to the “Edit and View” page.
- Start the editor.
Limit all actions to basic things: keystrokes, mouse movement, keyboard input. For example, do not write phrases such as “Block content,” it is better to write “Click the [Lock] button.”
Use common terms. If members of your team call a text box placeholder Placeholder, then you should call it this way too. This is especially true for English speaking teams. Over time, you will notice that the team uses a limited set of words. Be careful while adding a new word to the general lexicon. This can lead to ambiguity.
Outsourced testing services are provided to ensure that a given software project is developed in accordance with its requirements specification.
Make sure that you really need each step. Every unnecessary step causes confusion.
“Be responsible for every word you say.” If you write that a bug is played back for the manager, then check that it is reproduced only for this purpose and not for others. This should also apply to the browser – if there is Safari Mac, it means only Safari Mac is to be used, and you have verified that the bug is reproduced in all the other browsers.
Reproduce any bug, introducing several examples. For instance, try to do the same action involving multiple users. If the bug is not played back by all users, try to establish the difference. If there is no difference between the situations, then it is most likely that you are dealing with Data issue – a bug which is associated with data integrity violation, but not with the code. In either case, you need to specify the account for which the bug is played back. Firstly, the programmer does not waste time trying to reproduce it. Secondly, you localize the bug more precisely, and, as a result, it will be easier to repair it.
Introduce a bug only if the behavior of the system contradicts the requirements. If the requirements do not include this step, then discuss it with your team or write a letter to the client. Avoid subjective judgments. It happens that programmers repair something that was not actually broken. Then they redo everything from the beginning at the request of the tester, who thinks differently, etc.
Attach screenshots images to the description of the bug. Use the colored border to mark the parts that seem wrong to you. Another person will be completely unaware of what is wrong with the picture if it has no comments. Also add a screenshot of what you want to see (you can draw it in a graphics editor or correct the layout of the site in the tools of your browser developer). Ideally, combine these pictures into one big picture.
Add Comment