By: Sachin Jain, Lead QA and Manager
Testing is an important part and phase of any software development life cycle. Equally important is reporting of bugs identified during testing. Whenever, tester finds any bug/ issues during his/ her testing, it is important for him/ her to report the bug. However, reporting a bug also not to be as straightforward as it seems to be. There is a certain process to be followed by a tester while reporting a bug. It has to be clearly defined and well documented before it is reported and sent to development team for fixing.
How To Write Bug Report
If a tester is not reporting a bug correctly, then the programmer will most likely reject it stating it as irreproducible. This can hurt the tester’s morals.
If the Bug report is effective, then its chances of getting fixed are higher. So, fixing a bug depends upon how effectively you report it. Reporting a bug is nothing but a skill, I will explain how to achieve this skill.
Anyone can write a bug report. But not everyone can write an effective bug report. You should be able to distinguish between an average bug report and a good bug report.
How to distinguish between a good and bad Bug report?
It’s very simple, apply the following characteristics and techniques to report a bug.
Characteristics and Techniques
1) Having a clearly specified Bug Number:
Always assign a unique number to each bug report. This will help you identify the bug record. If you are using an automated bug-reporting tool, then this unique number will be generated automatically each time you report a bug. Note the number and a brief description of each bug that you reported.
2) Reproducible:
If your bug is not reproducible, then it will never get fixed.
You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing steps.
The bug which is described step by step is easy to reproduce and fix.
3) Be Specific:
Do not write an essay about the problem.
Be Specific and to the point. Try to summarize the problem in minimum words yet in an effective way. Do not combine multiple problems even if they seem to be similar. Write different reports for each problem.
Effective Bug Reporting
Bug reporting is an important aspect of Software/Application Testing. Effective Bug reports communicate well with the development team to avoid any confusion or miscommunication.
Bug report should be clear and concise without any missing key points. Any lack of clarity can lead to misunderstandings and slows down the development process as well.
Defect writing and reporting is one of the most important but neglected areas in the testing life cycle.
Good writing is very important for filing a bug. The most important point that a tester should keep in mind is not to use an authoritative tone in the report. This breaks morale and creates an unhealthy work relationship. Use a suggestive tone.
The important information that a bug report must communicate is “How?” and “Where?” The report should clearly answer how the test was performed and where the defect occurred. The reader should easily reproduce the bug and find out where the bug is.
Keep in mind that the objective of writing a bug report is to enable the developer to visualize the problem. He/she should clearly understand the defect from the Bug report. Remember to provide all the relevant information that developers seek.
It should also be noted that bug reports will be preserved for future use and should be well-written with the required information. Use meaningful sentences and simple words to describe your bugs. Don’t use confusing statements that will waste the time of the reviewer.
Report each bug as a separate issue. In case of multiple issues in a single bug report, you can’t close it unless all the issues are resolved.
How To Report A Bug
Use the following simple Bug report template:
This is a simple Bug report format. It may vary depending on the Bug report tool that you are using. If you are writing a bug report manually then some fields need to be mentioned specifically like the Bug number, which should be assigned manually.
Reporter: Your name and email address.
Product: In which product did you find this bug?
Version: The product version, if any.
Component: These are the major sub-modules of the product.
Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.
Operating System: Mention all the operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, and Mac OS. Also, mention the different OS versions like Windows NT, Windows 2000, Windows XP, etc., if applicable.
Web browsers: Most popular web browsers that are used today are Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, Apple Safari, and the Opera browser.
Priority: When should a bug be fixed? Priority is generally set from P1 to P3 (High, Medium & Low). P1 – High – a defect must be primarily fixed; P2 (Medium) – it can be fixed later when a bug report contains no bugs with a high level of priority; P3 – Low – it's fixed last when all the bugs with a higher level of priority have been fixed.
Severity: This describes the impact of the bug.
Types of Severity:
Showstopper: No further testing work can be done.
Critical: Application crash, Loss of data.
Major: Major loss of function.
Minor: Minor loss of function.
Cosmetic: Visual imperfections in an app's graphical user interface (GUI).
Enhancement: Request for a new feature or some enhancement in the existing one.
Status: When you are logging the bug into any bug tracking system then by default the bug status will be ‘New’.
Later on, the bug goes through various stages like Open, Resolved, Verified, Reopened, , Closed, Deferred, Accepted & Not a Bug.
Assign To: If you know which developer is responsible for that particular module in which the bug occurred, then you can specify the email address of that developer.
Otherwise, keep it blank as this will assign the bug to the module owner. If not, the Test Manager will assign the bug to the developer. Possibly add the manager’s email address to the CC list.
URL: The page URL on which the bug occurred.
Summary: A brief summary of the bug, mostly within 60 words or below. Make sure your summary is reflecting on what the problem is and where it is.
Description: A detailed description of the bug.
Use the following fields for the description field:
Reproduce Steps: Clearly, mention the steps to reproduce the bug.
Expected Result: How the application should behave on the above-mentioned steps.
Actual Result: What is the actual result of running the above steps i.e. the bug behaviour.
Additional Information: Provide evidence (snapshot or small video) that the bug occurs.
Conclusion:
Bug reporting is not just something a part of the process. Effective bug reporting not only makes it easier for developers to identify and correct the bugs quickly, but also for testers as well for them to retest their reported bugs and check the re-occurrence. Also, this can serve as a repository as well for similar type of applications and testers can check for similar instances in the application.
Comments