The Govt.nz project isn’t just about building a website. It’s about government doing things differently. The project approach involves using Agile development, focusing on plain English, and embedding a tester within the project team. It turns out that when you combine these elements, you get a wide range of unexpected benefits. In this post, Siobhan Cotter talks about her experience as tester on the Govt.nz team.
On the Govt.nz project, one of the guiding principles being followed is that a full time tester be embedded within the project team to test throughout the Sprint — and that’s why I’m here. Although I have been working as a tester for nearly 15 years now, this is my first truly Agile project. While what I need to achieve remains the same, the way I go about it has to change.
I am part of the development stream of the project, so I need to be involved in making sure that changes made both to the underlying code and the structure and appearance of the site are tested to make sure that what we think will happen actually does.
A fundamental part of this process is creating a test plan that outlines what testing needs to happen as part of the project, how it will be carried out, and who will be responsible for certain activities. Once that is written and agreed to, the testing on the project will be easy and problem free. (This is not always true in real life!)
1) Write the test plan in plain English
I know Agile projects are known for not requiring a lot of documentation, but as the organisation is gradually undertaking projects using the Agile delivery methodology, we are trying to strike the balance between what we need within the project, and what the project manager will need to report in order to ensure accountability.Therefore, I was afforded a refreshing opportunity to think about what information needed to be in our test plan and how it could best be presented to the intended audience.
Sometimes, using ready-made templates restricts our thinking to those sections contained in the template. Starting from scratch involved a lot more consideration of the information that needed to be included — and just as importantly, what didn’t need to be in the plan.
As my user story involved getting the test plan signed off within a single sprint, I knew it had to be clear and concise while still containing all the information required by the stakeholders (who are all busy people who don’t have much spare time for reading wordy technical documents) .
2) Talk about the test plan
Once the plan was drafted, we held a walkthrough with the people who would be signing off the plan to deal with all questions and feedback in the one forum, thereby avoiding the rounds and rounds of different versions of the plan being sent out, because who has time to actually read them?!?In the end, the conversation helped to develop a shared understanding of what we were doing.
The process we followed resulted in the quickest and most painless sign-off process I have experienced in over a decade of testing. Long live plain English test plans.
3) Improve your test process as you go
Like most things on the project, the test process is constantly changing and evolving as we are learning from hands-on experience what works well and what needs to improve.One of the great things about this project team is the willingness to acknowledge things that need to change and the openness to try new ways of working to achieve that change — it’s a far cry from the ‘Lessons Learned’ sessions held at the end of some of the traditional Waterfall projects I’ve worked on. Some fantastic ideas and strategies come out of those sessions, but are then filed away and lost and never implemented.
On this project, the lessons learned are identified and discussed at the end of each sprint at the retrospective meeting, and put into practice as early as the day after with the start of the next sprint!
4) Involve the tester early
Another advantage of the Govt.nz project set-up is the opportunity for testing to have early input into the planning of activities we will be involved in. As a tester, I’m in the room when the acceptance criteria are being written, and I can contribute to ensure they’re clear enough to test against. Also, as I’m part of the product team, I can have conversations with the developers, the designer, the content people, and the product owner to clarify how things are expected to work.At the sprint planning meetings we are urged to commit only to what we reasonably expect to complete within the two week sprint duration, and making sure that within the development stream we understand the implications and timings of the stories assigned to each of us.
