Agile has introduced a flexible and iterative approach to software development by shifting from monolithic to more manageable, smaller, and incremental developments. In agile, requirements and feedback are constantly evaluated to quickly respond to consumer, technological and market demands.
All these attributes ultimately lead to a faster and flexible delivery pipeline without sacrificing the quality of the end product. This focused approach leads to increased software product quality with a noticeable reduction in production bugs or issues in most instances. However, it does not mean that there will be no defects in the delivery process, Agile will certainly help reduce defects even though it does not eliminate them.
What are defects in a system?
Defects can be defined as malfunctions, errors, or unintended behaviours of a system that cause unexpected results. Any deviation from the end-user or original business requirements can also be considered a defect.
Typically defects relate to the coding issues that will provide an incorrect or an unexpected result. These defects can also result from external factors such as database errors and infrastructure configurations due to the tightly interconnected nature of modern software.
Why do defects appear?
The iterative approach in agile developments breaks software development into smaller chunks with sprints focused on a specific bug fix, new feature, or optimisation. This focused development method allows sprint teams to put all their effort into a specific development.
During development, the software undergoes a testing process to identify if it is fit for purpose and highlight any deviations from expected behaviour that might be considered as defects. Defects can arise in the feature currently under development, or perhaps current work may have had a detrimental effect on other, previously working areas of the project (i.e., regression of functionality).
In agile methodology, when a defect is detected, it is quickly communicated to the developers with all the relevant information, without the need to log the defect in a defect management or tracking tool. Instead, clear two-way communication helps the team analyse, debug, and resolve the issue together and often quickly. Typically, newly discovered defects that affect the product release will be prioritised within that same sprint while moving non-critical tasks to the backlog.
However, there are a few scenarios where defects are discovered that cannot be fixed in the current sprint. A larger, over-arching fix may be required, or perhaps there are more critical bug fixes or feature releases that need to be prioritised before this fix.
Another scenario might be that it cannot be properly tested or reproduced in the current development or test environments. Perhaps a more integrated, downstream environment is necessary. Changes to the underlying configurations, platform/software updates, authentication changes, or token renewals could be the underlying cause for the identified defect. The defect may be tackled in an upcoming sprint as there is no capacity in the current sprint to fix that defect.
In any of the cases noted, it may be necessary to log and track the defect in a defect management tool so that the details are not lost as the sprints progress.
How to track and manage defects?
How should we effectively deal with the defect without compromising the system functionality or impacting end users?
The short answer is to utilise a proper defect management process. A defect management process will include the following stages:
- Defect discovery
- Categorisation and prioritisation
- Implementing resolution or fix
- Fix verification
- Retest and closure of the defect
This process takes an identified defect from discovery to fix in a managed and trackable manner. While most of these stages are self-explanatory, the ‘Categorisation and Prioritisation’ stage is one area that we should focus on. It is the stage where the triage person/team decides whether the defect warrants immediate attention or can be worked on later, perhaps after more pressing issues are resolved.
Once defects are categorised and communicated to the relevant parties (considering factors like criticality, impact, etc), they are assigned into sprints depending on the priority of each defect (bug). If the team does not have the capacity to fix the defect within that sprint, they might deprioritise another less critical task to make way for this one.
If the defect’s impact on the solution is minimal, or a workaround is available, the defect may be assigned to the backlog to be picked up on a later sprint, after the current delivery cycle has been completed.
If key stakeholders disagree with assumptions made about a defect’s business impact, or the effectiveness of a suggested workaround, the delivery team may be tasked to explore alternatives. Other teams or resources may be called upon to work through a resolution.
In such instances, a properly implemented and understood delivery pipeline process is crucial for managing the workload between different teams without drastically changing their individual goals and objectives.
Conclusion
Agile methodology is a powerful framework to create a faster and more flexible software solution delivery that allows teams to deal with evolving requirements.
Reducing the occurrence of defects, and reducing the time taken to resolve such defects are the primary goals of adopting this type of methodology.
While Agile provides us with the flexibility to effectively handle these defects with minimal overhead and impact on the delivery team and their cycles, sometimes it may be necessary to adopt a more traditional approach to raising and tracking defects through to their resolution.
If you are looking for guidance in agile defect management best practices, get in touch with luvo’s testing experts via [email protected]
