Image may be NSFW.
Clik here to view.
Picture this, hotshot… You are working on a team that has recently made the transition to agile development. 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?
Ok, well if you stick to a traditional development 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 either notify the interested parties or just let the bug tracking system do that for you. At this time, it’s usually up to a development lead, 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:
- It 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.”
- It promotes throwing bugs surrounding a story back into the backlog, thus requiring the team 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 latter part of #2 is the biggest problem. If we find a problem with a story being implemented and then make 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.
- Finally, the approach may introduce waste surrounding the documentation of the issue.
Check out Part 2 of this discussion, where I’ll cover how the process of software testing looks different in an agile development environment – and what this change can do for you.
