How to Convince Testers to Work with Incomplete Specs
How to Convince Testers to Work with Incomplete Specs
This is another “tough question” from our customers at our last RallyOn Europe conference. If you’re a tester in a traditional environment, you’re often expected to use detailed specs to determine whether software works. Agile teams often don’t produce the same kinds of documents, so what’s a tester to do?
It’s all about sprint planning. When a team plans a sprint, or iteration, they’re examining each story in detail. The product owner is there to answer all kinds of detailed questions about what they want out of each story. Testers are a key part of making this meeting work.
Now, I spent five years in the Product Owner role, and I’m not a detail-oriented person. When I prepared for sprint planning (or story grooming, when we moved to Kanban) I would come with three, maybe five pieces of acceptance criteria. I relied on the testers to aggressively ask questions about additional details. We’d spend five or ten minutes discussing each story as a team, and we’d end up with a lot more detail written out in the story. If our tester was out sick during a planning meeting, we’d miss a lot of these details and we’d have a rough time during the sprint.
As your sprint proceeds, these detailed acceptance criteria turn into acceptance tests -- ideally automated. At Rally, testers are heavily involved in the process of automated test creation. Some teams have standard working agreements that before coding starts on a story, a developer and tester pair will sit down together and work out the testing strategy.
All this requires that testers are full-time members of the teams they’re on, able to work directly with developers throughout the entire project. If your testers aren’t part of the team, this isn’t going to work for you, and you might need to rely on the waste associated with more formal specs. Your projects will be slower, riskier, and more expensive. Plus, written specs are never perfect. Developing them incrementally with the help of testers is the way to go.
To learn more about Iteration Planning, see the Iteration Planning Toolkit and the Planning Guide.
Comments
Successful testing is the objective, not sucessful development..
Alex,
I agree - the development team needs to be multi-discipliniary: some development staff should be testing experts - and also the development staff need to make testing their priority.
The natural conclusion is that development should be test driven - there can be no evidence that development is successful until tests are passed, so they should come searly and be comprehensive...
In New Zealand the concept of "Test Driven Development" (TDD) is now part of the IT High School curriculum
Read more here:
http://books.google.co.uk/books?printsec=frontcover&id=7cZyrdr6CaIC#v=snippet&q=%22concepts%20of%20test-driven%22&f=false)
Brian
http://brianwernham.wordpress.com