Until recently I worked at the Test, Design and Consultancy Services (TDCS) as the testing lead for the Home Office visit visa application. This was the first project I’ve ever done agile testing on.
My colleague Mat wrote about what it was like to implement from his perspective, and I have to say I wouldn’t go back to waterfall.
Two of us were assigned to work alongside the team during the alpha; myself (a test lead) and John Green, a test engineer who worked on things like automation and scripted tests.
Initially though I worked on the project on my own. I worked closely with the developers in a continuous integration environment. My main role, in that team, was exploratory testing. Whenever a story was ready for testing, I'd deploy it to the test environment and try it out.
Responsibility was shared throughout the team; myself, a product owner, a scrum master, about five developers, a designer and a researcher. Everyone took on a share of the responsibility for testing the service and making sure it met the criteria we’d set for each story or iteration.
Get the most out of specialists
I also worked closely with Leonie and Josh, who are GDS’s accessibility experts. We'd share the application whenever we felt we’d made changes significant enough to merit further input from accessibility specialists.
We learned early on that sharing feedback over email didn’t always work. People might have a different interpretation of different defects, or the solutions.
We've changed the approach for the Beta so the team will work as a group to review and improve the site whenever specialists are helping us test the service. The important thing is getting everyone in one place - around a monitor if necessary - so we have a shared understanding of the problem, the context and what the solution might be.
At the same time we’ve realised how important it is that people work using common tools. We’re building up some recommendations internally so that teams at TDCS have access to shared tools, and we find the right things to use when we work with external suppliers so we can monitor progress on the defects we surface in the service.
No more waterfall
The old way, you occasionally felt like developers saw you as the enemy - trying to break the things they’d built and leaving them to fix it - but working together, sharing problems as a team, felt much more productive.