If a bug report is written well, you have a chance that the defect will be fixed. Bug correction depends on how effective it is reported. Bug reporting is just a skill and we look through the question of its improvement.
The purpose of writing a bug report is to fix the defect. If a tester reports on the bug incorrectly, most likely, the programmer will reject this defect because it is not reproducible.
Everyone can write a bug report but not everyone can write a good bug report. We will examine some of features and methods on it:
- The presence of a unique defect number.
Always assign a unique defect number to each of bug report. It will help you to identify the bug easily. If you use any automatic bug report tool, this unique number will be generated automatically each time you write a new bug report.
- Reproducibility.
The defect is not fixed if it is not reproducible. It is necessary to indicate clear steps to reproduce the bug. Do not write anything unnecessary and do not skip any steps for reproducing. The step-by-step described problem is easy to reproduce and fix.
- Be specific.
Do not write an essay on the defect, be specific and accurate. Try to formulate the problem using the minimum amount of words. Do not combine several bugs, even if they seem similar, write different reports for each of the errors.
How to report on the defect?
It is a simple format of a bug report. It can vary depending on the tools you use.
Reporter: Your name and e-mail.
Product: the product where you identified this bug.
Version: product version if available.
Component: these are the auxiliary product modules.
Platform: Mention the hardware platform where you identified this bug.
Operating system: Mention all the operating systems where you identified the bug. Such operating systems, as: Windows, Linux, Unix, SunOS, MacOS. Mention various operating system versions, for example, Windows 7, Windows 10, MacOS 10.0.1 etc.
Priority: When the bug should be fixed? Priority is usually set from P1 to P5. P1 as «Fix the bug with the highest priority» and P5 as «Fix when the time allows».
Severity: It describes the effect of the bug.
Types of severity:
- Blocker: the further testing work is impossible.
- Critical: application failure, data loss.
- Major: a major damage to functionality.
- Minor: a minor damage to functionality.
- Trivial: some improvements of the user interface.
- Enhancement: request for the new feature or improvement of the existing.
Status: When you register a new bug in any system, it is designated to «New» by default.
Later, the bug goes through various stages, such as Fixed, Verified, Reopen, Won’t Fix etc.
Assign To: If you know which developer is responsible for that particular module, in which the defect occurred, you can assign this developer. In other case, leave this field blank to assign a bug to the project owner or the project manager will assign a bug to the developer.
URL: The URL of the page on which the error occurred.
Summary: A short bug description, mostly 15 words or less. Make sure that your summary reflects: what is a bug? where is a bug? when does a bug occur?
Description: A detailed bug description. Use the following items for the description field:
- Reproduce steps: Indicate the clear steps to reproduce a bug
- Actual result: Indicate the actual result when performing all the above steps, that is a bug behavior
- Expected result: Indicate how the program must behave when performing all the above steps
These are important aspects when writing a bug report. You can also add «Type of the report» as the one more field which will describe the error type.
Error types:
- Coding error
- Design error
- New suggestion
- Documentation issue
- Hardware problem
And some more tips for writing a good bug report:
- Report on the problem immediately.
If you identify a bug during the testing process, write a report on it, immediately. It will provide a good and reproducible bug report. If you decide to write later, so, you have a chance to miss important steps of your report.
- Repeat the error three times before writing a bug report.
A bug must be reproducible. Make sure that your steps are reliable enough to reproduce a bug without any ambiguity. If the error is not reproduced each time, you can still write a bug report, indicating the frequency of the error.
- Test the same error in other similar modules.
Sometimes a developer uses the same code for other similar modules. That’s why, there is a possibility that an error from one module can occur in other similar modules. You can even try to find the most serious version of the identified error.
- Write a good bug report.
A summary of the errors will help developers quickly analyze the nature of the errors. A low quality report will unnecessarily increase the development and testing time.
- Read a bug report before clicking the «Sent» button.
Read all the sentences, formulations, steps, used in the report. See if any sentence creates an ambiguity that can lead to a wrong misinterpretation. Avoid misleading words or sentences.
- Do not use offensive phrases.
It is nice that a work has been done well and a bug was identified but do not use this fact to criticize the developers.
Conclusion:
Undoubtedly, the bug report should be a high quality document.
Focus on writing good reports and spend some time doing this task, because this is the main communication point between the testing specialist, the developer and the manager. Managers should create an understanding for their team that writing a good bug report is the main responsibility of any tester. Your efforts to write a good report will not only save the company’s resources but also create a good relationship between you and the developers.
Comments are closed.
