A bug is identified, now what? Fix it. Of course that is an obvious answer. This post is intended towards a better approach of addressing a bug with long-term gains in mind. Addressing a bug is a given thing, but what you do as a follow up act is important. A bug can be reported at any stage of the development process, we will consider one that is reported after releasing the product to the client.
Assessing the root cause of the issue is the key. The metrics available from this exercise are so valuable that the time spent is an extremely valuable investment that an Organization can make. Wikipedia defines Root cause analysis as:
Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized.
How can we apply this concept to Software development? Extend the life-cycle of a bug. Once a bug is fixed don’t just close it in the tracking system. Move it to something like a Root cause analysis stage. Only after completing the analysis close the bug. Okay, so what consists of analysis? It actually depends on what phase of SDLC the bug is more associated with. More often than not a bug is associated with more than one phase — like an issue that is missed during design/implementation phase and also missed during the testing phase.
Requirements Phase
In general, a bug or defect is something that is not compliant to the agreed upon requirements. So if an issue is reported and the requirements explain the behavior to be something different, user-misunderstanding of the requirements could be the issue.
- User misunderstanding: This is relatively easy one, but still requires some action from the teams involved. Leadership may have to verify if the user training material needs any update based on this experience.
Design/Implementation Phase
Whether developers or their managers like it or not, in many Organizations more “blame” is attributed to them if a bug arises. That is debatable, but what is more important is to pro-actively address as many issues as possible in the given time frame. They need to make good use of the tools available at their disposal. Perform static analysis, code reviews, maintain good code coverage with unit tests (More on each of these in separate posts). One most important aspect, unfortunately not given utmost priority, is automated functional/integration tests. There are many tools available, including open-source free options that can be used. The tools being too expensive to afford is no more an excuse. My thoughts on some of my experiences evaluating these tools are published here.
Coming back to RCA, when a defect surfaces the teams must identify which areas can further be strengthened. For example,
- Code Review: Perhaps doing better code reviews could have addressed this issue long time ago. Static analysis can be automated with tools like PMD, FindBugs, etc. If you already have these processes in place then add an additional rule in PMD (or similar tool) related with the issue in question.
- Unit Test: If you determine that a JUnit (or some XUnit framework) test case can better track the issue — the next action is to write a unit test and add it to your test suite. The assumption is that you run the unit tests more often in the spirit of Continuous Integration. If you already have a unit test that did not catch the issue, fix it.
- Functional Tests (automated): With the advent of open-source tools developers can do themselves a favor by writing an automated test or ten. If they get into that mode, tests can be written considerably faster and saves significant time later on in the SDLC. The concept is very similar, if you determine that an automated functional test could have identified the issue sooner, by all means add one.
Testing Phase
Ideally, testing group should be the first line of defense when a bug arises. An introspection from the testers on how they could have identified the issue (during the testing phase) would certainly help.
- Regression Suite: Regardless of the processes followed testing teams usually will have a set of test cases and test plans that they use to certify a build is good for release. When a defect is reported, regression suite is what you would examine first and make any necessary updates.
- Acceptance tests: Ideal to automate as explained above, and perform the similar actions as described above. All that it requires from the leadership is to identify if this is the area that has to be strengthend for achieving maximum results.
Is it a Reactive Approach?
It appears that the approach is more reactive in nature, you are performing certain actions only after a bug is reported. Wouldn’t you like to find the issues sooner than later. An analysis of this sort, if done correctly, can provide you with certain patterns, trends and metrics. For example, while adding a test scenario you may identify a related scenario or another variation of the issue, and you address that by adding additional tests or adding another unit test. You may also identify a particular pattern emerging, say more issues are being reported in a specific module or certain kinds of design issues are emerging more often.
As explained in Wikipedia:
RCA, initially is a reactive method of problem solving. This means that the analysis is done after an event has occurred. By gaining expertise in RCA it becomes a pro-active method. This means that RCA is able to forecast the possibility of an event even before it could occur.
It would be intersting to know how many Organizations take this kind of long-term approach in their development process. The emphasis should be more on improving the processes than to “scapegoating” individuals by taking short-term band-aid approaches.
You may also like:
Follow on Twitter