Bug – a slang notation for a program error. Bugs are identified as a result of testing. To eliminate them, you need to report the problem to the developer, and therefore – make a bug report.
What is the purpose of the bug report?
- Reproduce the detected problem.
- Understand what the problem is and how important it is.
To reproduce the problem, you need to describe the steps that you can perform to see it. Therefore, do not start the bug immediately, as soon as you see the error. We must first repeat it. You cannot repeat – it means, perhaps, important steps are missed. We remember what we did. Once the order of actions is identified, which leads to an error, it is necessary to minimize the number of steps: remove unnecessary ones that do not affect the outcome. Then we start a bug in the system of bug-tracking:
Summarize in the topic of the essence of the principle of “What? Where? When? “: What is not right, where exactly, under what condition.
In the description, we give the playback steps. Superfluous we do not write, we do not miss necessary. We are guided by the principle “What did we do? What have you got? What should you get? “
If you need the original data for playback – attach the files. If the problem is visual, then insert a screenshot (for this you can use, for example, the application Light shot), and as an expected result – a link to the design. In the screenshot, you must specify the arrows/signatures, what’s the problem (preferably directly on the parallel with the design snapshot):
If the problem cannot be caught by the screen (flicker/shifts) – write a screencast (using, for example, screencast). If you need to attach the error text (from the console or sniffer), then, in any case, we do not copy the text into the Description, but save it to the notepad and attach the file.
Then you need to specify the environment in which the problem appears: device model, OS version, and browser. If in several – enumerate all. For example Win8 Chrome, MacOS 10.9 Safari, Sony Xperia Z Android 4.4.2 Chrome.
Priority of the bug depends on the specific project and its features. But in the general case it is exhibited in importance:
- Blocker – the problem blocks functionality.
- High – serious problems of functionality, affecting the main script / main features that need to be fixed in the first place.
- Normal – standard functional / layout bugs.
- Low – typos, small bug’s layout.
A bug should be assigned to the developer who is involved in the relevant functionality/layout: the fact that he executed the part in which the bug was detected. In the Version, we indicate the version of the product in which the problem was detected. In Development Category type: functional, backing, front, layout, etc. In the Observers, we put the project manager.
What cannot be done?
- You cannot start a few problems in one bug.
One problem is one bug in the bug tracker. If the problems are related, refer to the same module – you can create them in the form of related tasks. But in any case not in one!
What’s wrong with a bug-report with several bugs in one task? This significantly slows down the process of eliminating them. After all, after fixing a bug, the developer reassigns the task to the tester for verification. Thus, if he has several problems in one task – he will not be able to give them for verification until he corrects everything. When each bug is issued in a separate task, the tester can begin to verify much earlier. Thus, the life cycle of a bug (re-opening, closing) is faster, and the software moves faster to release.
- You cannot start as a bug that is not related to the Project Specification.
Those. If the behavior of the program is not spelt out in the Specification as we believe it should be – this is not a bug. Do not need to take away from developers the time to work, which is not agreed. Such things can be started as a Feature, having coordinated preliminary with the project manager.