Agile Test Strategy

[THIS POST HAS BEEN UPDATED: Please visit Agile Test strategy Updated!]

Over the years I have had to design really heavy weight test strategies to help sell/communicate to the business the reasons why we are testing and what we will do during each project. However, I have always found that no matter how good the intention set out in the test strategy is, what actually occurs during the test phase of a project is almost unidentifiable. Fortunately, on the last project I worked on I had the opportunity to develop a lean test strategy that was useful, practical, reusable, and above all, CMMi friendly!

Although not strictly a company that practised agile or lean development, we were trying to reduce the bureaucracy of traditional technical processes. The following is probably as light weight as a test strategy can get, but it works.

The idea was to make a statement of intention that loosely binds some of the more important test practices that can help a team move forward. The phases are fairly typical of agile development, although they do not represent a definite task execution flow.

Phase: Project Set Up

• Understand the project
• Collect information about the project
• Create a test knowledge repository

Phase: Planning & Analysis or Release Planning

• Assist in the definition and scope of stories
• Develop test plans based on planning session

Phase: Development Iterations

• Risk analysis during the sprint/iteration planning
• Construct acceptance tests for each story
• Develop business functionality validation plan
• Document and write tests for defects
• Automate with both unit and UI tests
• Assist in functional review/demo
• Accept User stories

Phase: Hardening Iterations

• Regression test
• Business acceptance testing
• Develop release readiness plan
• Run performance tests

Phase: Release

• Assist in release readiness
• Plan test release data and tests
• Accept the Release

Using this basis for every project we can deliver software that has undergone rigorous testing but has not been delayed through the burden of traditional test documentation.