Once test cases are written, they are assigned to testers and executed. The testers find some bugs during execution of these test cases, record them in the bug tracking system, for example in such as Bugzilla, and mark the test cases in the test documentation system as:
- passed;
- bugs are found;
- blocked (can’t be passed because of more common bugs).
The bugs found should be fixed. However, there are situations when developers do not have enough time or, oh, the horror!, the skills to fix the bug. In addition, it happens that the same bug has already been found and entered into Bugzilla by another tester, or the bug has been reported by mistake (for example, the tester misunderstood the test case).
Ukrainian testing services companies provide their services to improve quality of digital products. They help customers to verify their investments and manage critical business processes to cut the total cost of building superior software apps and better ROI.
Thus, bugs are not always fixed. And if they are fixed a tester generally should check whether the bug has been fixed. The life of a bug is a journey of defect life cycle that a defect goes through during its lifetime. It can be extremely complicated when a bug does not occur as smoothly as expected. For better management of this process, in a good bug tracking system, every bug is assigned a status, and there is also a person responsible for it. A bug can be moved from one state to another and from one person to another until it is closed. In different projects, the life cycle of a bug (the state transition graph) and the such states are different, but basically the following states are used:
- NEW – just reported.
- ASSIGNED – a specialist is named and “on the hook” to fix the bug.
- RESOLVED / FIXED – the bug is confirmed as provisionally handled by a developer and assigned to another committer for verification (this state has several options). It is passed to the testing team.
- DUPLICATE – such a bug has already been entered into the bug tracking system. It gets repeated one or more time.
- INVALID – this is an expected behavior of the system.
- WORKSFORME – the bug is unreproducible.
- WONTFIX – the bug is recognized as a bug, but it will not be fixed. This usually applies to a minor bug that is not fixed quickly and easily, more precisely, in the case of too high cost-to-severity ratio (price / quality). Only the development lead or the project manager has the right to assign such a resolution of the bug.
Any status of the bug that has been fixed, other than FIXED and WONTFIX, most likely means that the bug was created in vain, the tester had wasted his time creating it – his own and time of the developer who dealt with this bug.
In order not to create duplicates, you must first make sure that the same bug is not recorded in the bug tracking system.
So that not to create WORKSFORME bugs, you should make sure that the same bug is reproducible, i.e. identify and repeat the sequence of actions that led to the bug.