Earlier I outlined what the process looks like for a traditional software tester, and some of the problems it can cause. Today let’s look at how different that would look in an agile development environment and what it can do for you.
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 with whom you’re working on the story and review the issue. Together you can decide, is this something that is not finished — a bug that has been introduced, and the developer simply needs to perform a task to fix it? Maybe you are both going to walk over to the product owner (customer) and discover it’s a bug or a simply a missed design requirement?Nonetheless, you would deal with the issue instead of launching it into being 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 standup meeting if it has not been resolved.
Here’s what this approach does for you:
- It drives a “Team” atmosphere and makes the issue a challenge of both the Tester and the Developers.
- It 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.
- It 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; when the story is delivered, it looks polished versus having “known issues.”
- Finally, it 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 when your team’s stories are still too big to design, build and test in one iteration. Your testing then happens 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 percent 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 who 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 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 promote agile principles.