In this post, I will discuss about bugs, defects or deviations from expected functionality in software testing. I will describe Bug Life Cycle along with a flow chart and Bug Severity Definitions with different severity levels like Critical, High, Medium and Low with examples. I will also discuss on how to find bugs while testing.
What is Bug?
Bug is a term used to describe any error, mistake, flaw, failure found in program or system which will cause unexpected behavior or functionality or output or result. Any deviation from the requirement causes due to faulty code or mistake or error from any resource will be called as bug.
What is Bug Life Cycle?
Whenever testers find a bug or any deviation from expected functionality which can be derived from requirement tester has to log the bug. Bug life cycle will going through different phases.
1) New: Tester logs any deviation from expected result while testing the application will be having status as New. New bug will be assigned to Test Manager or Development Manager or Project Lead.
2) Open: Bug will be having status as Open if the manager or lead approves that the bug is genuine.
3) Rejected: Bug will be having status as ‘Rejected if the manager or lead rejects when the bug is not genuine.
4) Deferred: Bug will be having status as ‘Deferred’ if the manager or lead if the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
5) Assigned To: Bug will be having status as ‘Assigned To’ when Lead or Manager assigns to reported bug to developer.
6) Resolved: When developer resolves the assigned bug then status of the bug will be changed to ‘Resolved Fixed’. Bug can be resolved in many ways which are mentioned below:
- Fixed: When developer makes necessary code changes and verifies the changes.
- Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to ‘DUPLICATE’.
- Cannot be fixed: If the bug cannot be fixed due to some technical difficulty then status will be changed to Cannot be fixed.
7) Need More Information: When developer is not clear about the bug reproduce steps provided by tester to reproduce the bug, bug status will be changed to “Need more information’. In this case tester needs to add detailed reproducing steps and assign bug back to developer for fix.
8) Not Reproducible: When developer will be unable to reproduce the logged bug then status will be changed to ‘Not Reproducible’ and same will be assigned back to tester who logged or assigned to manager or lead and manager or lead will assign back to tester. Tester has to recheck that if the logged bug is reproducible or not. If the bug is reproducible then tester has to add additional information and assign it back to developer.
9) Closed: Once the status of the bug is changed to Resolved and assigned back to tester, then tester has to test the bug. If the bug is fixed and bug no longer exists then tester has to change the status as ‘Closed’.
10) Reopened: Once the status of the bug is changed to Resolved and assigned back to tester, then tester has to test the bug. If tester is not satisfied with the fix and if bug is still reproducible even after fix then tester can mark it as ‘Reopen’ so that developer can take appropriate action and same life cycle will be continued.
Bug Severity Definitions:
Each deviation from requirement has to reported and identify the impact severity has to be assigned. Different naming conventions have been used like S1, S2, S3 or Critical, High, Medium, Low. Definitions for each severity must be very much clear to testers so that it will be easier to developer to prioritize the fixing part.
Critical – This group represents catastrophic failures where the application is either not functioning correctly or not performing according to design specifications. The exposure risk is high. These anomalies must be fixed before the product can be signed-off.
Examples:
- Service crash
- Incomplete Installation
- Data destructive failure
- Memory allocation errors
- Reports not generated
- Important functionality crash.
- Feature having major risk factors.
High – This group represents issues where the application is not performing according to the design specifications. The exposure risk is moderate. All attempts should be made to fix these anomalies before the product can be signed-off.
Examples:
- Breach in the functionality
- Tools associated with the main application not completely functional
- Incorrect license information
- Incorrect data logging
- Improper menu integration
Medium – This group represents issues where the application is not performing according to the design specifications. Although this definition is similar to the high severity definition, these issues are not as severe as the high severity classification. In other words, the exposure risk is low. All attempts should be made to fix these anomalies before the product can be signed-off, time permitting.
Examples:
- Help files need to be modified / updated.
- User Guide needs to be modified/updated.
- GUI interface changes/modifications.
- Fields are not being refreshed.
- Incorrect information is presented.
- Format of Reports
- Help files do not launch hypertext
Low – This group represents issues that do not affect the functionality of the application. It consists of cosmetic, aesthetic, grammatical, or consistency of “look and feel” issues. The exposure risk is minimal.
Examples:
- Capitalization errors
- Truncated text in labels or captions
- Spelling, grammar, incorrect formatting
- Variance from GUI standards
- Minor help file and User Guide changes
Informational – This group represents enhancements or design issues that would be beneficial to incorporate into future releases.
Examples:
- Internet connectivity
- Output Debug Messages
How to find bugs while testing?
To identify bugs it very difficult, in two conditions tester will be missing the bugs:
- Not Looking for bugs: Testing is not performed because of particular test condition is unknown.
- Looking but not seeing the bugs: Sometimes tester will be so very familiar with the system that they overlook the bugs.
Bugs are identified because of below mentioned situations:
- Requirement is misunderstood: In this case feature will not be as the requirement of End user or stakeholder but it will be as per the understanding of developers.
- Wrong requirement: Requirement given by stakeholders itself will be wrong.
- Requirement in documented wrongly: Requirement given by stakeholder is correct but while documentation it written wrongly.
- Design specification is wrong: System design itself will wrong and will not be as per the requirements given by stake holders, but the design specification is implemented correctly.
- Program specifications are incorrect: Even though the requirement is clearly understood and documented properly. A design specification derived from documented requirement is correct but while programming design specification are improperly implemented.
- Data Error: While testing tester will be entering improper data.
- Testing error: Testers wrongly identifies a feature and state it as a bug.
- Planting more bugs while fixing one: This is also called are regression bugs. These are the bugs which occur when developer plant bugs in the process of fixing one bug.