Agile Development

How to Effectively Capture a Defect in Agile environment

Unfortunately, many organizations struggle with lack of, too much, or unimportant information that people capture in these defects.
By implementing the defect-tracking best practices outlined in this article, teams will be in position to maximize overall defect resolution lifecycle while developing the agility necessary to overcome tomorrow’s challenges.

The Fundamentals

Before we jump into best practices, let’s review the fundamental parts every defect description should have:

Information About Defect:  A brief description of essential information describing a defect.

Reproduction:  A set of steps the team can follow to reproduce this problem. While it is possible to fix a non-reproducible defect, it can be a very difficult and time-consuming task.

Environment Found:  Some defects only exist in specific environments. Many companies have multiple environments, so it is essential to know in what environment the defect was found. 

Application Version Found:  Similar to environments, teams can have different application versions in different environments. If teams have too many versions, there is a usually a problem in their branching and/or code promotions approach; however, in this article we will only concentrate on defect tracking. It is important to document the application version in which a particular defect is found.

Severity:  After a defect is found, it must be assigned a severity level.

Best Practices

Now that we have covered main characteristics, we can review the best practices everyone should follow when creating a defect:

Agree on Defect Capturing Approach:  This means that team members, product owners, stakeholders, and everyone else is using the same approach to describe a defect, and the same tool to capture this defect.  Also, this means that defect severity levels are defined, approved, and understood by everyone.
To reach consensus, you will need to involve and get feedback from all groups who will be working with defects.

Keep It Simple and Not Time Consuming:  Even the most sophisticated processes or applications do little good if they are cumbersome and time consuming. That is why simplicity should be a top priority when we are thinking about capturing defects. This especially applies to the tools which teams will be using. You must make it easy for users to report defects, or they will not use a tool. This seems like common sense, but organizations often fall in love with all the bells and whistles that defect-tracking systems can offer, and in the end users end up with an overloaded, over-configured application that no one wants to use.

Use Common Terminology:  Defect information needs to be clear to everyone.  If defect information is unclear or hard to understand, it will lack essential data. Try to clearly define the most relevant information, and always keep in mind that a team will be actually working on your defects. 

Make Sure to Capture All Necessary Data:  Sometimes you will need to capture information that is not commonly needed just to provide enough information.  Information like the exact time and date that the defect was found often can be very useful when fixing a defect.

Write Clear and Reproducible Defect:  It is vital to capture relevant and useful information. When incorrect or incomplete information is captured, the team(s) that are working on fixing a defect will waste time tracking down defects based on bad information, or they may have to constantly request clarification about poorly-described problems.

The following information should be included in every defect:

-  Title:  The title should clearly describe the problem.

-  Summary:  A paragraph or two describing the defect.

-  System Information:  This usually includes device, system, browser, etc.   

-  Steps to Reproduce:  Explain how to reproduce the defect. This is a critical piece of information and is often inadequately described.

-  Expected Results:  Describe how the application should work. If it is hard to explain expected results using words alone, add a mock-up showing how the application should look.

Screenshots Are Your Best Friend:  Software defects often have a visual component that cannot be adequately described. Attach screenshots of failures to reduce ambiguity and confusion. A screenshot can simplify the defect-reporting process so dramatically that some organizations require them.

Avoid Defect Duplication:  One defect report is helpful; two to four is annoying; five or more is just plain rude. To minimize duplication, users should look into the defect tool prior to submitting a defect.

Meet Compliance Measures:  Yes, you can be agile and still meet compliance by capturing required defect information. Many organizations must meet these compliance measures, which usually put demands on information gathering, data integrity, process definition, and policy enforceability. A good defect-tracking tool with workflow capabilities will provide a system that meets compliance requirements by capturing relevant change information throughout the lifecycle of a defect.