Bugs are an inevitable part of software development and can cause disruptions and issues in the functioning of a program. By understanding the intricacies of bugs and their lifecycle, developers and testers can enhance their ability to create robust and reliable software.
What is a bug?
Everyone has probably heard the word "bug" at least once, but how much misunderstanding lies behind this word. Let's start with the definition of a bug.
A bug is a deviation of the actual result from the expected result.
Expected and actual results are something you will encounter many times a day. So it is important to understand these terms clearly. The expected result is the behavior of the system as described in the requirements. The actual result is the real outcome or performance of the system during testing. It is also important to understand the difference between defect, error, and failure:
- Error (bug) is a human (developer) action that results in a defect.
- Defect is a result of an error and can potentially cause a system outage or failure.
- Failure is a problem that can be self-corrected or fixed with minor intervention. For example, an application hangs but after a restart works again.
The chain is shown below for full understanding:
Bug lifecycle
The bug lifecycle is a sequence of steps from the moment a bug is discovered until it is finally fixed. The main stages a bug goes through are described below.
1. Submitted – the state when you have discovered a bug and been able to reproduce it at least 2 times.
2. Open – the initial state of the bug report when it is first created.
3. Assigned – the report enters this state from the moment the reporter (the creator of the report) assigns the developer responsible for fixing the bug.
4. Declined – the bug is not confirmed or is simply not relevant. There are many reasons why an issue may be assigned this status. Here are the main ones:
- The tester believes they have found a problem due to poor knowledge of the product but in fact there is no problem. This might be the correct behavior of the product or a feature of the system.
- The developer has not been able to reproduce the problem. But the developer may make a mistake and not consider all the conditions for reproduction. The tester can then re-assign the problem with a more detailed description of the problem.
5. In progress – this status means that the developer has started working on fixing the bug.
6. Fixed – the state when the developer has fixed the problem and returned it to the tester for testing.
7. Test in progress – the tester has started testing the fixed issue.
8. Reopened – the report moves to this state if the issue has not been fixed. In this situation, the tester switches the issue back to Assigned, i.e. to the developer responsible for fixing the issue.
9. Verified – testing has successfully confirmed that the defect has been fixed.
10. Closed – once the issue has passed the verification stage, or has been effectively rejected, it is closed.
Conclusion
So understanding the basics of bug handling and the stages a bug goes through will help in the early stages of being a tester. This is an opportunity to orientate yourself in the current position of the test team and to get into the project faster.