Picture this hotshot, you are working on a team that has recently made the transition to agile. You are a traditional tester. A developer just let you know that you can start testing the story that the two of you are working on during the sprint. You start working through your test cases, and “BAM” you found a problem …what do you do? …what do you do?
Ok, well if you stick to a traditional approach, you would create a defect in a bug tracking system, spend some time documenting the replication steps, create and attach screen shots to the bug, add test data to the bug, and then you would either notify the interested parties or you’ll just let the bug tracking system do that for you. At this time, it’s usually up to a development lead or project manager or business analyst to review the bug and determine if it is really a bug. If it is, they would assign it to a (or the) developer to fix and you (as the tester) may create a new test case to verify the bug is fixed as well as re-execute the original test scenario.
Now you’re saying, “Matt, what’s wrong with this?” And I will say, “Nothing, if you don’t care about finishing the story or delaying delivery or incurring technical debt or just putting out crappy product.” Maybe that’s going too far, but what this approach does is a number of things:
- The approach instantly puts up a barrier between the Developer and the Tester of a story. If not by introducing the intermediary process, but by simply calling it a “bug”.
- The approach promotes throwing bugs surrounding a story back into the backlog; thus, requiring us to find some way to associate the two (creating administrivia) and requiring the intermediary step for someone to evaluate the bug and decide when it needs to be fixed.
- The later part of #2 is the biggest problem, if we find a problem with a story being implemented and then make it a decision about fixing it then we are doing two things — letting the process possibly delay just getting it done and we are setting ourselves up for delays and debt.
- The approach possibly introduces waste surrounding the documentation of the issue.
The way you would handle finding an issue using an agile approach, is that when you encounter an issue while testing the story — instead of creating a bug in a tracking system, you are going to talk. Yes, that’s right — you are going to rely on “Individuals and Interactions over Process and Tools.” When you find the issue, you are going to grab the developer that you are working with on the story and review the issue. Together you can decide, is this something that is not finished, it’s a bug that has been introduced and the developer simply needs to perform a task to fix it, and, maybe – you both are going to walk over to the product owner (customer) and discover is this a bug or a simply a missed design requirement. Nonetheless, you are going to deal with the issue instead of launching it into the ether to be triaged, verified, and resolved sometime in the future. If you cannot get in touch with the developer — maybe you are divided by geography and timezone, then you may flag the story as blocked and quickly document the challenge being presented by the issue. Let the product owner know about the issue and be sure to bring it up during the next daily stand-up if it has not been resolved.
Here’s what this approach does for you:
- Drives a “Team” atmosphere and makes the issue both the Tester and the Developers challenge.
- Ensures that we don’t amass Technical Debt. Not to mention, you can avoid having issues/defects possibly slip through the cracks due to oversight or purposeful decision to let it slide out the door.
- Makes for a better product by having another opportunity to discuss the solution. The challenge found might be a result of the design and or requirements that may be wrong or misunderstood. It’s best to discuss these things as they happen to keep them fresh and when the story is delivered, it looks polished versus having “known issues.”
- Reduces costs in the long run. By not pushing issues, even for a few days, you can prevent the possibility of propagating the issue and having it impact other areas of the product. Thus, reducing rework and eliminating waste.
Now, I’m going to guess you are saying, “Matt, that sounds good — but it wouldn’t work here.” Well, I say “Why Not?” Sometimes, this doesn’t work is when you’re team’s stories are still too big to design, build, and test in an iteration. Thus, your testing is happing in the next iteration and issues found are recognized as new work. This is simply an inspect-and-adapt thing where the team needs to continuously refine the stories until they can commit to finish it 100% during the iteration. The other reason this often occurs is a command-and-control culture which may be driven by processes that are already in place or simply people that feel they must have their hands on every aspect of the development cycle. There’s not much I can suggest about adjusting the culture side besides just starting taking a more agile approach to handling challenges and let that approach prove out that it works better — trust me, it does.
Let me know about your experiences — I’m interested about your challenges, ideas, and methods you’ve used to change the culture or ways you’ve instituted an approach to issues that promotes agile principles.