Tag Archives: defect

Defect Management in an Agile Environment

 

The purpose of defect management is to identify bugs or defects of the software and provide information to improve the development process.

In Agile, the process of detecting defects works in parallel to the software development process, and once mastered, can prevent a lot of potential problems.

Scrum per se as a framework does not explicitly show you how to handle defects. With scrum you can bring more accountability to the entire project, however  one lacks clarity on how the teams should operate in the process of delivering the software. Some questions that arise are..

…When a bug is found does it become part of the sprint backlog

…What if adding it to the sprint skews the burn-down and makes it harder to meet the sprint goals?

…What by adding defects to the product backlog delays an important fix?

 

 Defect in Traditional Environment

Conventional Waterfall development consists of a system that can be included in the definition of ‘Done’ when it is analyzed, designed, and coded. Development needs to pass the quality testing phase. Bugs and issues detected during this stage are called defects. They are researched and re-tested by the developers before sending for finalization.

However, this method lacks the ability to preven

t the bugs. Developers are required to break down software code and check results. Once completed, they move on to another project and defects in the previous one causes unnecessary delays in the workflows. This adds stress and instability resulting in an impeded development process.

 

Problem Management in Agile Environment

Whenever an error occurs in the user story of a current or past sprint, it should be immediately identified and resolved to maintain  quality. The methodology may vary from one scenario to another. And so here we elucidate few scenarios:

 

Scenario 1: When a Defect is Detected During Acceptance Testing of a User Story:

In most of cases, it is better to detect and fix a problem as soon as it is discovered in the QA testing. When this isn’t possible, the user story should go back to the developer for resolving the defect. It is re-tested several times until the complete resolution of a defect. In this scenario, recording of a defect can also help. The teams stay abreast of the waste that takes place between the phase of development and testing. And metrics can be used for a better problem management.

 

Scenario 2: When the Team Conducts Regression Testing on the Functionality of Software:

Sometimes, developers may conduct a regression testing on the user stories that are already accepted by the product owner. In this story, there can be a defect that needs to be properly tracked and unraveled.

It is always a possibility to create a defect for such issues. However, you should resolve it immediately instead of creating a defect to be tracked.

 

Scenario 3: A Story is Noted as Done Despite Some Known Defects that are Deferred:

In a deferred defect, there lies a sub-feature of a user story that needs full implementation. Here, it is important to create a new story to fix the defect. These may include defects having requirement specifications. In Agile environments, such defects are sized and prioritized according to other factors.

 

Scenario 4: A Defect Found in the Demonstration of a User Story:

In every 2-3 weeks, developers demonstrate user stories to the stakeholders. If something is found to be broken during this demonstration, a defect is created, prioritized, tracked, and resolved for it. However, the issues in the unaccepted stories can’t be marked as Defects. In this scenario, the story isn’t complete and defect can’t be created.

As a matter of fact, follow a well-defined problem management practice to resolve the defects in the software.

In the end, the best way to manage problems is to prevent them from happening.