Bug tracking systems are bottlenecks, they perpetuate the continuous handovers between testers and developers and they require extensive documentation to be maintained.
The standard life cycle of a bug is usually as follows: A QA tester finds an error in the application, creates a new bug in their bug tracking system and sends it to the developer, which in turn, as soon as he fixes the bug, notifies back to the QA tester, which then, notifies the product owner which then, closes the bug.
In paper, the previous process sounds wonderful, but there are quite a few drawbacks.
- Communication problems. Sometimes the description of the bug is poor, or the developer misunderstands the problem.
- Regression testing. This process requires the handover of code back and forward between QA and development, this causes versioning problems and duplicated testing effort.
- Low robustness. The process doesn’t guarantee that the error will appear again in the future.
- Bureaucracy.Traditional bug tracking systems switches the team focus to bureaucracy from quality.
The solution for this problems is simple. When anyone finds a bug, he/she immediately writes an automated test that fails based on the bug just discovered. This mechanism have the following advantages.
- Gets rid of versioning problems, everyone works on the head.
- Guarantees that the bug is never gonna reappear undetected.
- Eliminates uncertainty on what the bug exactly is.
- Eliminates bureaucracy
- Consolidates the development activities in one place, the code.
The challenges to switch to this process, where a bug tracking system is not necessary are:
- Requires an automated build. This build have to be in place and running all the automated tests, so when a new automated test is entered because of a bug, the build will break and the team will have to take a decision whether they will fix the fix now, or whether they will ignore it for the time being (That way you will know that all the ignored tests are non-fixed bugs)
- Requires cooperation. Developers and testers must work together so they can create new tests as soon as they find new bugs. You are going to require testers with programming skills.
- Requires discipline. The team must understand that without exception, for every bug found, a test is created, and for every time the build is broken, the priority is to fix the build.
- Requires organization. Tests must be created with criteria and using a common naming convention.
Summarizing, in my opinion, the future of bug management is to get rid of all the traditional bug tracking systems and all the bureaucracy, I also think, as explained just above, that there are quite a few challenges, but if you have the skills and tools in your team to overcome them, I would seriously think about getting rid already of your old bug tracking system.
- How to write a good test case: 5 tips to write better test cases
- Book review: xUnit Test Patterns
- How to write good tests. Top 5 considerations to build software without defects.
- Stop waiting to the end of the project to start QA!!! (And other QA principles)
- Continuous integration, going beyond continuous compilation.