Agile teams release to production much more frequently than teams using a traditional phased-and-gated process....
What’s a tester’s role in an Agile team’s release process?
When I joined my first Agile team back in 2000, releasing to production every two weeks seemed revolutionary. These days, some teams release to production several times per day.
In the age of automated deployment, testers still play an important role. The deployment process itself must be verified. A good practice is to deploy to test environments via the same process used to deploy to production. What with source code control and continuous integration, we can feel reasonably certain that the correct code will be deployed to production.
Still, we’re human, and mistakes can happen. It might seem old-fashioned, but there’s nothing like following a checklist to help ensure releases go so smoothly that end users only notice the nice new features. My team keeps a release checklist on our team wiki, so that we can easily keep it up to date.
On my team, we testers make sure that the correct build has been tagged for release. This provides a safety net for the rare occasions where a defect sneaks out into production and we have to release a patch. There are three testers on our team, and we rotate “release” duties. The tester “doing” the release makes sure that the system administrator knows the correct build to release. An automated deployment process cuts down that margin for error.
The first step in a production release is often releasing to a “staging” environment, where there’s more freedom to do tests that update data to verify the release. Automated deployment reduces the need for a staging environment. On my team, database updates are not as controlled and well-automated as we’d like, so verifying them in our staging environment is a necessity. We have a suite of automated GUI tests that verify critical functionality of the staging site to give us that extra reassurance that we’re ready to go live.
Once we start releasing to production, the value of our release checklist really kicks in. We run automated test scripts that verify external access to our production sites, internal administrative and operations functionality, and our Interactive Voice Response server. If we see any anomalies in our test results, we collaborate with the DBA and system administrator coordinating the release, and involve a programmer if necessary.
Testers fulfill an important role in keeping records for future audits. Once the release is done, we fill out the necessary paperwork. We’ve already demonstrated the newly released features to our stakeholders at our sprint demo, but we send out a detailed email to the whole company, for the benefit of anyone who couldn’t attend the demo.
As a tester, my role in production releases on an Agile team is not that different from when I worked on traditional Waterfall teams. The biggest difference is that with Agile development, we’ve already done so much testing, the release itself is routine. The more frequent our production releases become, the more work we’ll have to do on the other end: eliciting business examples and turning those into tests that drive development. I expect many of us will find ourselves monitoring production logs post-release to learn more about how real users experience our new software.
Discover where software tester roles begin.
Dig Deeper on Topics Archive
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading