STANZ 2012 – From the back of the room (Auckland)

03 October

During STANZ in Auckland, I had the opportunity to listen to Alan Kan as he spoke on “How to Make Your Testing More Agile”. Why does testing need to be Agile? Because testing needs to respond to the shorter and shorter delivery cycle that is the norm these days but testing still has to balance quality & speed. Alan identified that the majority of time spent in testing is on setting up the test environment. He talked about automating earlier (not just when UI is available but going directly to the interface), having automated continuous integration into our test environment, testing earlier with virtualisation, ensuring good configuration management is in place, revisiting our automation tool regularly to make sure it is still providing a return on investment and doing what we need it to do. He talked about tools assisting testers to become more Agile and allowing them to focus more on exploratory testing and leave the checking to the automated tools.

Later that afternoon, in Elisabeth Hendrickson’s workshop on “Beginning with the End in Mind: Acceptance Test-Driven Development (ATDD) in Practice”, she talked about what ATDD is, the ATDD Cycle (Discuss, Distill, Develop, Deliver) and why you would use ATDD. Unlike TDD which is a design practice, ATDD is a shared understanding of what the user story is about. A user story is a placeholder for a conversation to take place on what it is we’re supposed to build. ATDD captures this in examples with expectations creating executable specifications. This means that there is a one-stop-shop for requirements, which is great because previously we needed a traceability matrix to tell us which documents to update whenever there is a change. With ATDD, the requirements are expressed in acceptance tests. If there is a change in requirements, we update the tests directly and we can easily see how close to done we are at any given point in time by looking at what acceptance tests have been passed and what is left to do.

With ATDD, we no longer have to argue about whether an issue is a bug or not – if it violates the letter or spirit of the product owner’s expectations for the story then it is a bug. Other benefits of ATDD highlighted by Elisabeth included the ability to clarify intent & drive out ambiguity early (while the user story is being defined); high visibility of progress (how done are we); ability to leverage the artefacts for multiple purposes (e.g. use as requirements and tests); and ability to automate the regression checks.

It was a great workshop and good to see ATDD in practice with an actual user story and taking it through the process.


Posted by Donna Chin