In this section, we will learn about the bug life cycle and the different status of bugs and bug report template.
Here, we will talk about the complete life cycle of a bug from the stage it was found, fixed, re-test, and close.
We have some different status of bugs like new/open, assigned, fix, re-open, and closed.
As soon as the test engineer finds the bug, status is given as New, which indicates that a bug is just found.
This new bug needs to be reported to the concerned Developer by changing the status as Assigned so that the responsible person should take care of the bug.
Then the Developer first go through the bug, which means that the Developers read all the navigation steps to decide whether it is a valid bug or not.
Based on this, if the bug is valid, the Developer starts reproducing the bug on the application, once the bug is successfully reproduced, the Developer will analyze the code and does the necessary changes, and change the status as Fixed.
Once the code changes are done, and the bug is fixed, the test engineer re-test the bug, which means that the test engineer performs the same action once again, which is mentioned in the bug report, and changes the status accordingly:
Close, if the bug fixes properly, and functionally working according to the requirement.
OR
Re-open, if the bug still exists or not working properly as per the requirement, then the bug sends it back to the Developer once again.
This process is going on continuously until all the bugs are fixed and closed.
Note1:
The test engineer cannot tell the bug orally to the Developer because of the following reasons:- Developers might ignore the bug
- Developer misunderstood the bug
- Forget the bug
- The bug may not be found in the exact location
Whom to assign the bug
The bug can be assigned to the following:
- Developers
- Developers lead
- Test lead
Developers: If we know who has developed that particular module.
Developer lead: If we don't know the Developer who has developed the particular module.
Test lead: When we don't have any interaction with the development team.
When the bug is fixed and closed or if it is having any impact on the other module, then we go for a new bug report.
OR
When the status of the bug is Re-open (not fixed) and affecting another module, then we have to prepare the new bug report.
Note2:- Whenever we find a bug and Developers fix it, we have to check one round of impact area.
- If the old bug is fixed correctly, change the status to Close.
- And if we find a bug in the impact area, then reported as a new bug.
- If the old bug is not fixed properly, then change the status to Re-open.
- Or, if we find a bug impact area, then change the status to New or reported as a new bug.
Another status of the bug
Once we prepared a bug report and send it to the Developers, the Developer will accept the bug and starts doing the necessary code changes that become the positive flow of the bug life cycle.
There may be a serval conditions where Developers may not do the necessary code changes and depend on the situation, which becomes a negative flow or status of the bug life cycle.
Following are the different status of the bug life cycle:
- Invalid/rejected
- Duplicate
- Postpone/deferred
- Can't fix
- Not reproducible
- RFE (Request for Enhancement)
Invalid / rejected
When the Test Engineer wrote an incorrect Bug Report because of misunderstanding the requirements, then the Developer will not accept the bug, and gave the status as Invalid and sent it back. (Sometime Developer can also misunderstand the requirements).
Any bug which is not accepted by the developer is known as an invalid bug.
Reasons for an invalid status of the bug
The invalid status of the bug is happened because of the following reasons:
- Test Engineer misunderstood the requirements
- Developer misunderstood the requirements
Let's see one example where the test engineer and developer misunderstood the requirements as we can see in the below image:
Duplicate
When the same bug has been reported multiple times by the different test engineers are known as a duplicate bug.
Reasons for the duplicate status of the bug
Following are the reasons for the duplicate status:
- Common features:
For example: Suppose we have test engineer P and Q which are testing the software, the test engineer P and Q will test their features like login the application.
Here, the test engineer P enters the valid username and password, and click on the login button.
Once P click on the login button, it opens a blank page, which means that it is a bug.
After that, P prepares a bug report for the particular bug and sends it to the developer.
Then the test engineer Q also login the application and got the same bugs. Q also prepare a bug report and send it to the developer.
Once the developer got both test engineers bug report, he/she sends back the bug report to the Q and say it is duplicate. - Dependent Modules
As we can see in the below image, that the test engineer wants to compose a mail, so first, the test engineer needs to login, then only he/she can able to compose a mail.
If the bug is found in the login module, the test engineer cannot do further process because the composing module is dependent on the login module.
- To avoid the duplicate bug
If the Developer got the duplicate bug, then he/she will go to the bug repository and search for the bug and also check whether the bug exist or not.
If the same bug exist, then no need to log the same bug in the report again.
Or
If the bug does not exist, then log a bug and store in the bug repository, and send to Developers and Test Engineers adding them in [CC].
Note1:- Generally, we don't search for each bug in the repository to check the duplicity.
- To save time, we only search that bug that has the common feature and dependent features.
Note2:
Whenever we are comparing two bug reports to find out if it is duplicate or not, we should always look at two things, which are as follows:- The navigation steps should be the same.
- Apart from the close status, any other status should exist, we should not log a bug, and else it will become a duplicate bug as we can see in the below image:
Not Reproducible
The Developer accepts the bug, but not able to Reproduce due to some reasons.
These are the bug where the developer is not able to find it, after going through the navigation step given by the test engineer in the bug report.
Reasons for the not reproducible status of the bug
Reasons for the not reproducible status of the bug are as follows:
- Incomplete bug report
The Test engineer did not mention the complete navigation steps in the report. - Environment mismatch
Environment mismatch can be described in two ways:- Server mismatch
- Platform mismatch
Server mismatch: Test Engineer is using a different server (Test Server), and the Developer is using the different server (Development Server) for reproducing the bug as we can see in the below image:
Platform mismatch: Test engineer using the different Platform (window 7 and Google Chrome browser), and the Developer using the different Platform (window XP and internet explorer) as well.
- Data mismatch
Different Values used by test engineer while testing & Developer uses different values.
For example:
The requirement is given for admin and user.
| Test engineer(user) using the below requirements: | the Developer (admin) using the below requirements: |
| User name → abc Password → 123 | User name → aaa Password → 111 |
I.e., both are using a different value for the same login module.
- Build mismatch
The test engineer will find the bug in one Build, and the Developer is reproducing the same bug in another build. The bug may be automatically fixed while fixing another bug. - Inconsistent bug
The Bug is found at some time, and sometime it won't happen.
Solution for inconsistent bug:
As soon as we find the bug, first, take the screenshot, then developer will re-confirm the bug and fix it if exists.
Can't fix
When Developer accepting the bug and also able to reproduce, but can't do the necessary code changes due to some constraints.
Reasons for the can't fix status of the bug
Following are the constraints or reasons for the can't fix bug:
- No technology support: The programming language we used itself not having the capability to solve the problem.
- The Bug is in the core of code (framework): If the bug is minor (not important and does not affect the application), the development lead says it can be fixed in the next release.
Or if the bug is critical (regularly used and important for the business) and development lead cannot reject the bug. - The cost of fixing a bug is more than keeping it.
Note:- If any bug is minor, but the Developer can't fix it, which means that the Developer can fix, but the bug is affecting the existing technology because it was present in the core of the code.
- Each can't fix bugs are the minor bug.
Deferred / postponed
The deferred/postpone is a status in which the bugs are postponed to the future release due to time constraints.
The deferred status of the bug was not fixed in the initial build because of the time constraints.
As we can see in the below image:
The Bug ID-B001 bug is found at the initial build, but it will not be fixed in the same build, it will postpone, and fixed in the next release.
And Bug ID- B0024, B0025, and B0026 are those bugs, which are found in the last stage of the build, and they will be fixed because these bugs are the minor bugs.
Note:- All minor bugs can't be deferred, but all deferred bugs are minor bugs.
- Whenever there is no future release, then the postpone bug will be fixed at the maintenance stage only.
RFE (Request for Enhancement)
These are the suggestions given by the test engineer towards the enhancement of the application in the form of a bug report. The RFE stands for Request for Enhancement.
As we can see in the below example image that the test engineer thinks that the look and feel of the application or software are not good because the test engineer is testing the application as an end-user, and he/she will change the status as RFE.
And if the customer says Yes, then the status should be Fix.
Or
If the customer says no, then the status should be Close.
Bug Report Template (excel)
The bug report template is as follows:
Let see one example of the bug report:
|
Bug ID |
Boo12 |
|
Module |
Logina |
|
Requirement |
1 |
|
Test case name |
Gmail_login_compose
_mail |
|
Reporter |
Test engineer name |
|
Release |
delta |
|
Version |
3.0 |
|
Status |
assigned |
|
Date |
23-02-2020 |
|
Assign to |
YY developer |
|
CC |
Test lead, developer |
|
Severity |
critical |
|
Priority |
P2 |
|
Platform |
Window XP, internet
explorer7.0 |
|
Build no. |
B02 |
|
Test data |
Username=xyz,
password= 123 |
|
Brief description |
|
|
Navigation steps |
|
|
observation Mail |
not found in inbox |
|
Expected result Mail |
should also be in
the inbox. |
|
Actual result |
Mail not found in
inbox |
|
Additionalcomments |
------ |
Here, we are describing some important attributes of the bug
report.
Bug ID: it is a unique number given to the bug.
Test case name: When we find a bug, we send a bug
report, not the test case to the concerned developer. It is used as a reference
for the test engineer.
Severity: It is the impact of a bug on the
application. It can be a blocker, critical, major, and minor.
Priority: In this, we have to decide which bug has
to be fixed first. It could be P1/P2/P3/P4, urgent, high, medium, and low.
Status: The different status of the bug which
could be assigned, invalid, duplicate, deferred, and so on.
Reporter: In this, we will mention the name of the
person who found the bug. It could be the test engineer, and sometime it may be
a developer, business analyst, customer, etc.
Date: It provides the date when the bug is
found.
Release/Build Version: It provides the release number in which
the bug occurs, and also the build version of the application.
Platform: Mention the platform details, where we
exactly find the bug.
Description: In this, we will explain the navigation
steps, expected and actual results of the particular bug.
Attachments: Attach the screenshots of the bug, which
we captured because it helps the developers to see the bug.
The Drawback of a manual bug report
Following are the disadvantages of manual bug report:
- Time consuming
While searching every bug in the bug report, it will be time taken process. - Possibility of human error
A bug may be repeated, wrong data mentioned in the bug report, and miss something to add on the bug report. - No security
Anyone can change it or delete it. - Tedious process
- No centralized repository
0 Comments