The process of sending the identified bugs to the Developer is known as Bug Reporting.
The Bug Reporting is done by two types:
- Bug Reporting by using an Excel file.
- Bug Reporting by using any Reporting tool.
Bug Reporting by using an Excel file:
In this Reporting process, a Test Engineer update the Bug related information in an excel file and it will send to the Developer.
- It is called Bug Tracking Template or Bug Reporting Template or Bug Template.
The serial no. of the Bug will be mention in this column.
The Actual Result of the Bug will be described in this column.
The Status of the bugs is given below:
- New, 2. Open, 3. Fixed, 4. Re – Open, 5. Closed, 6. Rejected / Not a Bug.
Whenever the Test Engineer identified any Bug on the new build, so initially the Status of the Bug is New. This New bug will send to the Developer.
The developer will check whether the New bug is really a Bug or not. If it is a Bug then Developer will update the Status from New to Open in the Status column of Bug List. Once the Bug Status is Open means the Developer accepted it is a Bug.
The Open Bug will be fixed by the Developer, if it really works then he put the Status as Fixed and the fixed bug will be sent to the Testing Team.
- Re – Open:
The fixed bug will be tested by the Test Engineer, if is not working as expected then Tester will update the Status from Fixed to Re – Open and send back that Bug to the Developer.
- The Developer will check the Bug, if it is a Bug then he will update the Status as Open, then he will fix the Bug and again send that Bug to the Testing Team.
The Test Engineer will check the Fixed Bug that whether it is working as expected or not. If it is working as expected then he will update the Status from Fixed to Closed.
- Rejected / Not a Bug:
Whenever the Test Engineer reports any New bug to the Developer, the Developer will check whether it is really a Bug or not. If it not a bug then he will update the Status as Rejected / Not a Bug and send it back to the Testing Team.
Severity means the Seriousness of the Bug, it describes how seriously the Bug impacted the application for Testing, it is of below types:
- Blocker, 2. Very High, 3. High, 4. Medium, 5. Low.
If the Bug is blocking the entire Test Case Execution of the Specific Module, then the Severity of the Bug is Blocker.
- Very High:
If the Bug is blocking partially the Test Case Execution for the Module, then the Severity is Very High.
If the Bug is blocking only the specific Scenario, then the Severity is High.
All GUI Bugs’ Severity is Medium.
If the Test Engineer provides any suggestion about the application to the Developer in the form of Bug then the Severity will be Low.
It describes in which order the Developer has to fix the Bug. The Test Engineer will provide the Priority to the Bug based on the Severity.
There are five types of Priority:
P1, P2, P3, P4, P5
Note: – Priority will be given by the Test Engineer but depend on the situation, the Development Lead can change the Priority also.
The detailed steps will provide by the Test Engineer to produce or get the bug.
- Based on these steps the Developer will check that whether the reported bug is really a Bug or not.
We can also provide the Screen shot because it is a proof that the Reported bug is valid and also the Developer will use the Screenshot to analyze the Bug.
It is the build no. on which the Test Engineer executes the Test Cases and identifies the bug.
It contains the Test Engineer’s name who identify the Bug.
It contains the Developer’s name who is going to fix the Bug.
Once all the Bugs are updated in the Bug Tracking Template, then it will send to the Developer through an email and CC to all Team members or Test Engineer can use Google Spreadsheets.