What are the fields in a bug report?
What are the various essential and non-essential fields in a bug report?
SAMPLE BUG REPORT:
Bug Name: Application crash on clicking the SAVE button.
Bug ID: It will be automatically created by the BUG Tracking tool
Area Path: Eg: USERS menu > New Users
Build Number: Version Number
Assigned to: Developer-NAME
Reported By: Your Name
Reported On: Date
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Windows 2010/SQL Server 2014
Fields in a bug report include
- Bug Name - what bug has been found
- Bug id -generated automatically by BUG tracking tool
- Title/Summary - title of the bug report should be be short
- Assigned to -name of the developer
- Reported by -name of the one who found the bug
- Reported on - date
- Project name - the bug reported belong to which project or product
- Build version - on which version did it occur.
- Reason -defect/enhancement
- Environment -details of Operation Systems, Browser Details and any other related to the test environment in which you have encountered the bug.
- Priority -defines how soon the bug should be fixed. High /medium/low
- Severity - talks about the impact of the bug on the customer’s business. Blocker/critical/major/minor/trivial
- Status -of the bug. New/open/verified/closed/cannot be fixed.
- Description - a brief description about the bug
- Steps to reproduce - steps from beginning to end so developers can easily follow through by repeating the same process.
- Expected result -What should happen when you trigger the call-to-action?
- Actual result -Does the application crash? Does nothing happen at all? Is an error displayed?
- Proof/ attachments -screenshots, videos, or log files should be attached
In IT industry, the bug report template could be a standard one defined by the company's processes OR a custom one defined in accordance with the stakeholders or clients. However there are few must have fields in any bug report -
Bug ID: Essential during automation testing and bug reviews
Steps To Reproduce: Unless detailed steps to reproduce a bug are mentioned, it's very difficult for the QA engineers and testers to understand the bugs filed in the past. I've seen this happening. Many times, software testers do not write detailed steps and are unable to reproduce a bug they themselves had filed in the past.
Software / Feature / Module Version: Yet another commonly overlooked, but extremely fiend in the bug report. It's very essential that the bug report mentions the version of the feature , module or the software on which it was reported.
If this field is omitted, it becomes difficult to track the origin of the bug. This is extremely important when an old bug is 'reopened'.
Severity: Severity is very essential but needs to be marked carefully. Severity simply means how severely does the bug affect the software being tested. Typical entries are -
- Show Stopper
Priority: Priority is determined by the QA in-charge or project manager depending upon the urgency of the fix required. We'll have a separate discussion on varies types of bugs with varying severity and priorities.
Expected Result: Again, the field that many QA engineers take for granted. For example, if testing for login functionality - QA engineers will simply assume that entering the correct credentials will log the user in as 'expected' result.
But that may not be the case always. For example, there could be several 'dependent' actions on user's login. Which could be -
- Sending a mail to the user
- Updating the user in search cache
- Notifying other users or performing an action through middleware.
All these 'expected results' should be taken care of and clearly mentioned in the bug report's "Expected Result" field.
Screenshot is not an absolute 'must', but it often helps the developers and software test engineers quickly find out what's wrong quickly. Extremely helpful in functional, UI and browser compatability testing.