Introduction
We need to understand the following concept of bugs, bug reports and bug reporting software.
![bug]()
What is a bug?
A bug is a general term used to describe any unexpected problem with a software Application. According to Wikipedia, a software bug can be defined as:
“A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.”
Hence, in short, this means that a software bug in a software is a condition, which does not meet a software requirement or an end-user expectations, which causes a program to malfunction or to produce unexpected or incorrect results. A program which contains a large number of bugs is said to be a buggy program.
Where did the term computer bug come from?
This is really a great question. For it, we have to go way back to 1945.
According to Wikipedia,
In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.
![bugs]()
Thus, in theory, a bug is something, which is not allowing the program to work, as defined.
What is a bug report?
A bug report is a documentation, which clearly explains, how the product is broken. A bug report is something which stores all the information and data required to document, report and fix problems that occurred in a software or on a Website.
A bug report follows a simple formula:
“This is what we have, this is what we should have instead, so fix it.”
Every good bug report must answer the following questions:
- Exact URL of the Website?
- What do you expect to happen?
- What did actually happen?
- Browser you are using?
- Operating system, you are using?
- Steps to reproduce the error?
- Bug fixing urgency?
- Is the issue reproducible?
- Any additional information needed?
- Is screenshot of the bug present?
Good vs. bad bug reports
- A good bug report contains the proper information, required to reproduce and fix the problem, whereas a bad bug report does not contain the proper information, required to reproduce and fix the problems.
- A good bug report is the best way of communication between a bug reporter and a bug receiver, whereas a bad bug report creates a confusion between both.
- A good bug report is resolved very fast, whereas a bad bug report never gets resolved.
- A good bug report is filed in the defined way, whereas a bad bug report is filed in any medium available, but not in the defined way.
What is bug reporting system?
A lot of different expressions can be used to describe the bug reporting system and some of them are as follows:
- Bug reporting system.
- Bug tracking software.
- Issue tracking software.
- Defect tracking system.
No matter which name you prefer, a bug reporting system is a software Application, designed to keep track of the reported bugs in a software/Application.
A major component of a bug reporting system is a database which records all the reported bugs. A bug may include bug reporting time, its severity, steps to reproduce the bug, who reported it and who is fixing the reported bug.
Typically, a bug reporting system supports the concept of a bug life cycle, which is tracked through the status, assigned to the bug. The software should allow the authorized users to create, move the bug to another state or delete the bug, to configure the bug status and bug fixing urgency.
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed.
![bugs]()
- New: When a new defect is logged the first time.
- Accepted: When the newly reported bug is accepted by the developer to be fixed.
- Resolved: When the developer makes some necessary changes in the code to fix the reported bug and the bug is passed to testing team.
- Need information: If the developer is not clear about the bug, reproduce steps provided. He/she can mark it as “Need more information’. In this case, the testing team needs to add detailed reproducing steps and assign the bug back to the developer for fixing.
- Reopen: If the testing team is not satisfied with the bug fixing and the bug is still reproducible even after fix, the testing team can mark it as ‘Reopen’, so that the developer can take an appropriate action.
- Verified/Closed: If the bug is verified by the testing team, if the fix is OK and the problem is solved, the testing team can mark the bug as ‘Closed’.
- Duplicate: If the defect is reported twice, the status is changed to "duplicate."
- Rejected: If the developer feels the defect is not a genuine defect, he changes the defect to "rejected."
- Deferred: If the present bug is not of a prime priority and if it is expected to be fixed in the next release, the status "Deferred" is assigned to such bugs
- Not a bug: If it does not affect the functionality of the Application, the status assigned to a bug is "Not a bug".
Wrapping it up
I have shown you the basics of a bug, bug reports and bug reporting systems. No doubt your bug report should be a high quality document. The main focus of a tester should be on writing good bug reports and spending some time on this task, because this is the main communication point between the tester, developer and manager.