Agile Test Strategy (Updated)

A couple of years ago I posted a  very simple test strategy for agile based projects, here is an updated version.

Test and quality objectives


Objectives are a fundamental part of any strategy as they show us where we need to be going, and they allow us to invest in the right activities. My test strategies typically include the following objectives

• Provide the customer with a system that they really need with quality baked in
• Automate as much of the testing, configuration, and deployment as possible
• Engage the business and customers in testing
• Provide the business with the ability to confidently deliver features or complete systems without considering lengthy or multiple test iterations

Phase – Project conception & early estimation meetings


This is the most important part of the project. The wrong idea here could result in many man hours down the drain and a lot of money for your business. Who is really bothered about reducing the defect detection rate in a product or system that no one will ever use? Idea bugs are the most costly bugs and the ones that we should really focus on. This is sometimes out of the hands of most QA and test engineers, and is usually down to either having a very strong willed architect or a product manager that really understands what the customer needs and how to prove those ideas. I believe that this warrants a completely separate post, but you can find a very good explanation of idea bugs here. Whatever happens, there are tasks that we can take on.

• Encourage pretotyping to prove the product concept over writing stories for unproven ideas
• Understand any technology
• Begin to sketch out a test strategy for the project

Phase – Early stage sprinting


During the early sprints our focus should be on proving the architecture and system concepts, building the team, and putting in place development and test frameworks.
Planning

• Write technical stories or ensure the following tasks exist (These are all MUSTS)
• Set up a CI project on your CI server
• Set up unit test framework
• Set up framework for front end script automation (JSUnit)
• Set up build scripts
• Set up all the necessary environments for now and think about what you may need for the future (Identify any needs you have further down the line)
• Help scope out the stories and product
• Get acceptance criteria clear in each story
• Engage architects and technical experts in all planning discussions, never make assumptions on how things should work
• Liaise with test leads or test managers to ensure you have covered off any global test strategies or ideals
• Raise any performance considerations

Sprint

• If the architecture is not yet baked then get to understand proposed solutions, arguments for and against. If it is decided, get to know why it was chosen, capabilities, etc
• Ensure that plans are in place to make the code testable at more than just the unit level
• Work with the product owners to get more insight on what the product is supposed to be doing
• Update and test build and deploy mechanisms into the QA environments
• Look for opportunities for early automation
• Pair program / test / analyse

Phase – Normal sprinting


During normal sprinting we shape the product and deploy to UAT or beta environments on a regular basis to get feedback from customers, we may even be deploying direct to production. Regression testing is a key part of this process so must be efficient as possible. Throughout the strategy we are automating every process we can. Unit, integration, front end, and build scripts all combine to provide a high level of confidence in what we are delivering. 


Planning

• Clarify acceptance criteria
• Write testing tasks for all user stories
• Unit
• Integration
• Scripting
• Plan exploratory strategy
• Ensure environments are ready
• Plan crowd source testing
• Ensure that the correct people are involved in the different planning activities. The tester should become a conduit during the planning, ensuring that information is passing to the right people.
• Ensure UAT or beta environments are ready
• Set up performance environments

Sprint

• Write acceptance tests based on acceptance criteria
• Carry out automation tasks
• Maintain build scripts and environments
• Carry out exploratory testing
• Pair up with developers
• Performance test
• Test release mechanisms
• Write post release test plans

There are probably a lot more activities that we can include, and I would encourage folk to experiment. If you understand your objectives, you will definitely understand what activities you will need to implement.