RallyDev.com
Thu 16 Sep 2010
Dev-Test Walkthroughs Prevent Defect Churn
What Agile team doesn’t recall the disruption and frustration of story defects being filed after the developers thought they were ‘done, done’ and had moved on to other things? It’s disruptive when developers need to stop what they are doing and dive back into the code they were previously working on. Testers feel frustrated that critical aspects of a story were missed, or implemented incorrectly. Product Owners see stories taking longer to get through testing to final acceptance.
Because we support many different web browsers, manual testing is a key part of development of our rich web application, and we struggled with these issues in the past. So, over the last year, our Agile teams have been employing the practice of having a tester walk through a story implementation with a developer on their localhost machine, prior to check-in. We’ve found that this practice reduces the number of defects found after the story has been handed off to the tester.
We’ve seen multiple benefits, to date:
- Having a second person review the acceptance criteria as the basis for this walkthrough can expose differing interpretations of the AC, some of which could have implementation implications.
- Asking questions about implementation challenges or performance on our four fully-supported browsers has helped to reveal problems.
- It helps to have a conversation about the story and where its impacts on the overall system might lie. Could another page in the app be affected by the recent changes/new implementation?
- If problems are discovered, the developer can remain focused on the story/code they were just working on, rather than having to switch context from the next story they had begun work on.
- Problems found during the Dev-Test walkthrough can be addressed quickly, or deemed to be out of story scope.
More recently, as we have been experimenting with Continuous Flow/Lean/Kanban, our usability expert has also been doing story UX walkthroughs with developers, prior to the dev-test walkthrough. It’s difficult to visualize exactly how the interactions will feel before they’re built, and the UX walkthrough is timed to allow adjustments before beginning cross-browser testing.
QA and dev meet to walk-through test cases is a good practice, but the timing is the key, I think work-through before release is too late. I had been a QA for a couple of months before I became a dev in Nortel (it die now).
Our practice was:
1. QA and Dev had their test cases ready (not need to be formal, just a list) independently based on their understanding of requirement .
2. We met to find the gaps, had a discussion/verification the requirement and thus we had the same base line.
3. Then Dev started coding and unit testing.
4. Release to QA.
Most of cases in CCS team, we have the step 1 & 2 done in the story grooming and sprint planning/tasking meetings, we may not need the walk-through before release. If we need one, we can schedule one before coding.