Posted by: Divya Pandey
How to write an Ideal Bug Report for Mobile App Development
Many beta testers and end users don’t know how to write a bug report that includes the details a mobile app developer needs to know in order to fix the bug. Bug reporting is an important thing in software testing. An effective bug report is a medium to communicate well with the app development team and testing team to avoid confusion.
A bug report or defect report is a list of bugs found out by mobile app testers while testing the software in testing phase under a testing environment. The test environment created at development site is same as the actual environment in which the software is supposed to run or work in a live situation. Bugs or defect report is the most important tool for mobile app developers understand where the product that has been built by them is lacking in its performance or functionality. Testers have to be very careful in studying business and customer requirements while building their test cases and test plan. The quality of test cases will clearly enhance the core performance and functionality of the product built.
Ideal Bug Report
First of all, we should know how an ideal report looks like and what important information it contains? While there may be a small variation in report based on the application, but basically the bug report contains these things like Bug Name, Bug Id, assigned to, Status Reported by, Reported date, etc. Before creating the bug report, we should have knowledge of the Severity and the Priority because mobile app developers solve the bug based on the Severity and Priority. Now, you must be thinking of what severity and priority is:
Severity and Priority
Severity is defined as the degree of impact a defect has on the mobile app development or operation of a component application being tested. The priority of the bug shows that in which order bug should be fixed. Higher the priority shows that the defect should be resolved sooner. The usual classification is:
Defect severity can be categorized into four classes
- Critical: This defect indicates complete shutdown of the process, nothing can proceed after that. E.g. Crash in the mobile application
- Major: It is a highly severe defect and the system collapses. However, certain parts of the system remain functional
- Medium: It causes any undesirable change in the software, but the system still works functionally
- Low: It don’t cause any major break-down of the system
Defect priority can be categorized into three classes
- Low: The Defect is a problem but it can be fixed by repairing
- Medium: During the normal mobile app development process defect should be resolved. It can wait until a new version of the software is created
- High: This defect must be resolved as soon as possible because it affects the system and cannot be used until it is fixed
Here is How You Can Create a Simple Bug Report:
Bug Name: Application crash on clicking the Save button after editing the profile.
Bug ID: It will be automatically created by the BUG Tracking tool once you save this bug and it’s always unique
Area Path: Splash screen> >login screen>>home page>>profile
Build Number: Version Number 5.0.2
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-X
Reported By: Tester Name
Reported On: Date
Status: New/Open/Active/Fixed (Depends on the Tool you are using)
Environment: Windows / IOS
Title: It should be a short explanation about the issue. A good title should have information about what is the problem or steps you were doing when it failed.
For example: Assume, you have found a bug in the profile page while uploading a profile picture that took a particular file format (i.e., png file). System is crashing while uploading a png file.
Title: “Uploading a png file (Profile Picture) in the Profile Page crashes the application”
This is an overview of the bug and how and when bug occurs, written in shorthand. This part includes more details in compare to title, like how frequently the bug appears if it is an intermittent error and the circumstances that seem to trigger it.
Mobile application can have completely different behaviour depending on their environment. This part should include all the details about the environment setup and configuration on which the application is running.
- Device manufacturer and model number
- OS version
- Application version
- Network connectivity
- Battery state
- Screen orientation
Steps to reproduce: It is most important because by using these steps mobile app developer can easily reach to the bug. You should have to describe how to reproduce that bug step by step.
Assume, you have found a bug in the profile page while uploading a profile picture that took a particular file format (i.e., png file). System is crashing while uploading a png file.
Steps: Splash screen>>login page>>profile page
Expected Result: What should be the result when you make an action? Expected result is usually mentioned in the requirement specification documents.
Actual Result: Actual result is the output when you check out the software in real time environment.
Status: It’s showing the status of a bug in any bug tracking system. At the beginning status of bug will be “New”. After that status can changing like Fixed, Verified, Reopen, Won’t Fix and etc.
Attachments: If you take a screenshot then attach it in the report it’ll be a huge plus for app developers to see what you were seen before the bug and after. There is no need of attaching all screenshots just attach few important screenshots for the bug report.
Contact Detail: An email address where you can reach the user submitting the bug should be provided in case any further details are needed about the issue.
Compared to manual mobile app testing, automation in mobile application quality assurance offers many benefits. Automated mobile application testing is the best way to ensure that new mobile app versions do not hinder the functionality or create new bugs.