Agile Testing: Does involvement stop at the end of the sprint?

Posted: May 24, 2010 in Agile, Deployment, Testing
Tags: , , , ,

Being involved in an agile team, the emphasis on the tester is to become involved as early as possible in the sprint cycle; working with product owners, developers and business analysts to ensure the acceptance tests created provide sufficient information for the code to be written to meet the story requirement and the acceptance criteria agreed in advance of game planning.

The term ‘Zero Defect’ releases; at face value seems to be a contradiction to years of Quality Assurance and testing manuals. When you analyse the statement, if the team agrees the boundaries of a story, and all sign-up to the unhappy path criteria, then if all teams deliver to that contract then Zero Defects is achievable.

But does it end there? If you are developing new applications that integrate with a third-party or legacy back-end systems, can you assure that the shipped product at the end of the sprint will work in an end to end (E2E) fashion?

Risk Management needs to be factored in to the Agile teams approach, looking forward, appreciating the hidden cost of hardening an application for production readiness is a fundamental exercise; which will allow estimation of velocity to mature, and hopefully become more accurate. Having an appreciation of the amount of points needed to split between functional and technical debt stories earlier in the project lifecycle will ease the number of bottlenecks and dependencies in the run up to a release.

Other areas that are overlooked include business feedback (new backlog items) and defects that arise in Production; potentially related to the fact that the application has been allowed to ‘soak’ into an environment; maybe there is an overnight restart issue, that was overlooked during the game planning exercise of a story.

It is these examples where Agile testers can go back to the future; and add value. Defining processes; such as defect triage or scheduling pre-release soak tests etc. outside of the sprint cycle will capture many of these ‘isms’ that always occur when applications move to production. Maybe it was a configuration issue, maybe just human error; but edge cases that will either be of such low priority that they are overlooked when planning test activity; or what is more likely; the issue is found because a new environment has been used; with a slightly different configuration, leading to the need for extra resiliency to be built into the application to increase stability in the production environment.

Even though you could argue it is not the Agile teams responsibility; the counter to this is if these considerations are fed into the team planning early in the lifecycle; fewer surprises are likely to be uncovered. Agreeing processes such as triage for production defects or feedback, will ensure that the team can react to the need for an emergency patch fix or if the business priority is not immediate; the team are ensuring that the product backlog is being updated to allow future development cycles to be planned in line with changes or enhancements to the business thinking or change in market conditions.

In summary, risk management and traditional QA methods can have a role to play in future-proofing the agile deliveries. The most important thing to remember is that any process that is designed, must not inhibit the teams creativity and flexibility to deliver a sprint. Instead the process should complement the team, ensuring the backlog is maintained, based on business objectives or to provide a mechanism to allow the team to react to that emergency fix or patch.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s