The ISTQB defines a defect as:
- An imperfection or deficiency in a work product where it does not meet its requirements or specifications.
It’s not uncommon in practice, to see that definition stretched to:
- An imperfection of deficiency in a work product where it does not meet its requirements, specifications or a new set of specifications that are created after testing reveals gaps in the initial specification
This approach is mislabelling change requests as defects and this can have a negative impact on a team and their work.
While the output of this practice means that the delivered increment will provide the maximum value to the user, it skews the test reporting used by the team to better understand it’s processes and make improvements.
The downsides of disguising change requests as defects
If you pass change requests off as defects you’ll lose sight of your real defects (‘true bugs’) as the change requests may be prioritised over fixing the defects and it’ll be harder to gauge an accurate severity for the items.
If the change requests are prioritised then there’s a potential for the additional functionality to be built using defective behaviours and this could lead to even more defects.
These change requests are also likely to be poorly defined, having not been through the same process to meet the ‘definition of ready’ that they would normally go through if created during analysis and written quickly in order to patch the requested behaviour into the feature being built.
Without having the time to define the change request properly there is a potential for the changes being made to have knock-on effects leading to other defects (and more rework), and as the behaviour change is defined in a defect this might lead to the definition of the behaviour not being documented in the way it would otherwise be if it was a change request.
Additionally, raising change requests as defects will hide the amount of rework created due to poorly defined specifications, making this rework appear to be a problem with the implementation stage, instead of the analysis stage.
Approaches that can help prevent this
There are a number of practices that the team can use to make it easier to raise change requests to work on outside of delivering an increment.
Feature toggles
If the functionality is being built behind a feature toggle then merging the code in with just the ‘true bugs’ being fixed becomes an easier discussion to have as there’s very little impact on merging the functionality minus the change requests.
The change requests for the missing functionality can then be created following the team’s normal process and those change requests can be expedited in order to be delivered at a high priority.
The feature can then be turned on once all the functionality has been merged in.
Use prototypes when doing analysis
In order to find gaps in functionality before development starts it might be beneficial to create a prototype of the feature that can be tested and iterated over by the team during the analysis stage.
It will cost less time and resources to build a lo-fi prototype that catches gaps in functionality than it will to find those gaps after a developer has built the functionality, and the prototype also acts as a tool to build shared understanding for the team when it comes to doing the development.
The initial prototype might feel like a lot of effort to build but as more and more prototypes are created, a common design language and library of components will be built up that makes subsequent prototypes easier to pull together.
Keep track of which defects are not ‘true bugs’
Changing processes take time so it’s unlikely that a fix for this problem will be implemented perfectly overnight. While the team transitions toward a better process it will be worthwhile keeping track of which defects are actual defects and which are change requests.
This will help the team to understand what is a defect and what is a change request and will make conversations around classifying new ‘defects’ easier as there are examples to reference.
Keeping track of the number of change requests that were raised as defects will also allow the team to carry out root causes for those work items and understand what processes led to the mislabelling.
The benefits of change requests
Once the team has the tools in place to decouple the change requests from the initial feature development the reporting of defects found during development will become a lot clearer.
This clarity in reporting will allow the team to focus on understanding the root cause of these bugs without their analysis being clouded by other issues and this in turn will result in a greater understanding of the codebase.
The velocity of the team will increase as developers will no longer be forced to implement new behaviours and can merge a smaller change set into a deployable codebase.
Lastly, with reporting in place to track the number of change requests that come out of feature development the team will be able to understand if they need to invest more effort in the initial analysis of the stories they work on.
Summary
Not all defects are ‘true bugs’, some are change requests in disguise and this mislabelling of a change request as a defect can have a negative impact on the team’s ability to deliver increments and make the processes the team follows hard to work with.
By using development techniques such as feature toggles and utilising prototyping to explore features in the analysis stage a team can catch potential functional gaps early and lessen the impact any change requests can have on their velocity.
It’s important to distinguish defects and change requests when they are raised during testing as the root cause is different so the team needs to be able to know how to fix the issues in the process that lead to them.
@AvermentDigital on Twitter, Facebook and Instagram