What is Bug?
A defect/bug is the actual cause of error in software, e.g. incorrect statement, logical or semantic error.
How to report a Bug?
Bug reporting is an important aspect of software testing. An effective bug report communicates well with the development team and avoids confusion or miscommunication.
- Use meaningful sentences and simple words to describe your bugs.
- Don’t use confusing statements that wastes the time of reviewer.
- The bug report should be clear and concise. 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.
- It is best to split the issues into separate bugs. This ensures that each bug can be handled separately. Well written bug reports help developers to reproduce bug at their terminal. This helps them to diagnose the issue. o It is also important before reporting to check for the same bug has been reported or not.
- Bugs need to be reported in Bug tab of project board o Every bug needs to be logged with all mandatory details with correct steps, summary, category etc. in specifically defined Fields.
- If the same bug is observed in different device configurations, please report one issue with all details mentioned in the same bug.
- Bugs will be reviewed on first come first serve basis in the review process, and duplicate bugs will not be rewarded with the payout. So, we would recommend having a look at already logged bugs to avoid duplicate bugs and your effort.
- Oprimes team will review every bug that has been logged and can request you for additional bug information in case required. Also, can update severity based on our standard bug severity definition.
- All bugs need to be reported in English language only.
Bug Severity Definition:
Bug Reporting[/caption]
- Blocker: Blocker bugs are those where the app stops functioning or freezes either through Happy, alternate or sad path scenarios on the application under test for a user and his individual configuration and hence unable to test other functions or proceed further.
Example:
- In the email service provider application, after typing the correct Username and the password, instead of logging in, the system crashes or throws the error message, this defect is classi?ed as Blocker as this defect makes the whole application unusable.
- Unsuccessful installation, complete failure of a feature.
- Critical: Critical bugs are those when the app crashes or one or more areas of the app has a significant functionality flaw or performance issue making it unavailable/unusable and no workaround is available.E.g: In the email service provider application, if unable to set the profile image.
- Major: Any part of the app with high impact functionality issue but other areas of the app are functional and usable.E.g: In the email service provider application, when you are not allowed to add more than one recipient in the CC section, this defect is classified as the Major defect as the major functionality of the application is not working properly.
- Minor: Minor functional issue with low impact with the easy workaround.
- Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience.E.g: Example: Petty layout discrepancies, spelling/grammatical errors. UI related issues (misspelt words, misaligned texts, formatting, layout, graphical design improvement suggestions).Bug reporting template fields and examples:
- Bug ID: A bug ID (like Bug_001) makes bug reporting and referring to a bug easier. The Bug review team can easily check if a has been fixed or not. It makes the whole testing and retesting smoother and easier.
- Bug Title/Summary: A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution. The title should describe the problem as best as possible. Remember that the title is read more often than any other part of the bug report.Good: “Cancelling a File Copy dialogue crashes the application”
Bad: “Software crashes” - Platform/Environment: The OS and browser configuration is necessary for a clear bug report. It is the best way to communicate how the bug can be reproduced. Without the exact platform or environment, the application may behave differently and the bug at tester’s end may not replicate on developer’s end. So, it’s best to mention clearly the environment in which bug was detected.
- Steps to reproduce: Steps to reproduce are the most important part of any bug report. If a developer can reproduce the bug, the bug is very likely to be fixed. If the steps are unclear, it might not even be possible to know whether the bug has been fixed. The steps should include actions that cause the bug. Don’t make generic statements. Be specific on the steps to follow. A good example of this would look like the following: -Steps: 1. Launch the application
2. Tap on the Menu button
3. Observe, no action takes place on tapping the menu button - Actual Results: What the application did after performing the above steps.
- Expected Results: What the application should have done, were the bug not present.
Bug Rejection reasons:
- Invalid: This is also termed as “Not a Bug”.
- Duplicate: The bug is a duplicate of an existing issue reported by other testers.
- Out of Scope: The features/functionalities mentioned were deemed out of scope or no longer necessary to fix or work on.
- Not reproducible: All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue.
- Works as designed: This is how the feature has been designed and implemented. This is as expected.
