But the flip side of frequent releases is the injection of several bugs into the system that need to be squashed before deploying the product to the end-users. No matter how skillful and experienced a team might be, or how minor the incremental features may be, bugs in a system are inevitable. And the challenge of cleaning the code to make it production-ready could be both; something as simple as a single-line code change or something that demands taking up a mammoth sprint-long task.
Being truly ‘agile’ implies predicting and determining required changes in the system and taking rapid yet calculated actions to adapt to those changes during the product development lifecycle. And it is the same philosophy that should drive all the product stakeholders – the management, design, development, devops as well as the test teams alike to produce high quality deliverables. Most team focus largely on elaborate planning and product grade development with the help of well defined, granularly broken down tasks, scenario based user stories, employing development best practices, setting up a scalable architecture, choosing the most appropriate tech-stack and user centric designs and UX. However, what is most often underestimated is the bug trail cycle and the impact of regression on product shipping. And despite reserving a time cushion to tackle and manage bugs before deployment, it is the unpredictable nature of the bug cycle that compels many agile teams to drop their guards against the impending sword of delivery deadlines. That is where the real agility of a team is tested.
Various teams employ different approaches to tackle bugs. The classic approaches include timeboxing bug trail and refining the user stories to take care of deviant software behavior. While most widely used, the former approach hardly ever guarantees fixing of each bug reported in a given timeframe. Teams simply use this approach to fill in the time between development and delivery to enhance the features on the critical path of the product. The result – a skirmish between the product owner and the scrum master as the latter tries to justify why the product has been shipped with “known issues” (or in some extreme cases – justifying the bugs to be features!) And refining the user stories hardly works as well. In fact, should it even be done in the first place? Assigning story points to bug tickets after capturing the user scenarios that were earlier missed would be equivalent to rewarding the developers for squashing a bug that shouldn’t have occurred in the first place!
The ideal approach that agile teams should follow to curb the bug turnaround time and hit the deadlines would be to prioritize and attack bugs along the critical path first. As soon as the bugs are identified, the QA team should work with respective program managers or tech leads to prioritize the bugs on the basis of their end-user impact, and add them into the development pipeline accordingly. An experienced program manager would always reserve about 30% of the time dedicated to development for bug resolution, and commit to deadlines accordingly.
Even after accurate bug-hunting, what is important to squash and fix issues in the system is to get as much contextual information about the bug as possible. It is often seen that despite assigning bug tickets/tasks to associated developers, the error remains unresolved until deeper insights or diagnostic information about the issue have been discovered. And perhaps that is the quickest way to get to the root-cause of the issue and resolve it at the source. Imagine obtaining crash and error reports, console logs, or in case of front-end development – an accurate comparison with the pixel perfect source design! Not getting an accurate repro of an identified bug is undoubtedly every developer’s plight, but imagine system information attached along with an accurate video backed repro – the operating system in which the issue was faced, the screen resolution and scripting languages supported among others! More than working on the solution, it is understanding the problem that eats up majority of the bug fix time. And the agile teams whose testers sweat hard to crisply communicate repro steps, expected results and provide contextual information to the developers while filing the bugs win half the battle for them from the backlines.
That said, the effort that would be required to squash bugs can never be predicted with a 100% accuracy. And when the little ants take over, they sure can cause a tremendous havoc in large systems. Here are a few numbers to back the same:
- 48% of the users are less likely to use an app for the second time if they face performance issues (source: Compuware)
- 79% of the users are less likely to purchase from a site for the second time if they experience performance issues (source: Kissmetrics)
- 48% of the people associate sentiments to a poorly performing site as a company that doesn’t care (source: Google)
- 44% of the users delete a native app immediately if it doesn’t work as promised (source: Apigee)
Every agile team follows their own strategy to combat post production bug trails and fine-tune their code quality. It is a fact that no product or a system can be a 100% bug free. Just like idealism in itself is an ideal, unachievable concept, believing that a product is error-free and perfect is in itself a false claim. But does that mean we push buggy code and deploy systems? I guess not. After all, constantly striving towards success and excellence is what makes us human, isn’t it?
So, how does your team tackle bugs?