An Agile Test Strategy: Some Ideas
There are a couple of misconceptions when it comes to an agile way of working. Some people still believe you don’t need documentation (seriously, that myth has proven really hard to debunk). I also notice that a lot of focus is on automating everything when it comes to testing. I think that is a noble goal, but you will never be able to automate all testing tasks, since the ‘real testing’ happens inside a human brain.
So, even in an agile context it is a good idea to have some kind of test strategy. By this I explicitly do not mean a test plan. You know, those 50 page documents that nobody ever reads. An agile test strategy should be short and concise. It should explain to people who matter how you are going to approach testing in your context. It is also a good way to think about testing with your team.
Let me give you some ideas of what you can put in your test strategy.
The goal: what are you hoping to achieve with testing. What kind of risks are you trying to mitigate? What kind of information are you hoping to find? Are you going to do happy path testing only? Or are you also actively going to seek for failures and black swans? These are the type of questions you can answer here. Think about your own context. Maybe there are extra rules or legal rules that have influence on your test strategy.
Automation. Explain how you are going to do automated testing. Use the test pyramid and/or the agile test quadrants to think about which kind of tests you want to automate on which layer of your application (unit testing, API testing, GUI testing, e2e testing, etc).
Sapient Testing: (I use this term because I have a strong dislike for the term ‘manual testing’). How will you test the software yourself. Are you going to do exploratory testing and what kind of test techniques are you going to use? How are you going to structure those test sessions to avoid them from turning into unstructured testing?
Heuristics and Quality Attributes. You can use some of the test heuristics to describe what you are striving for as a team. Examples: The Always/Never heuristic (what should your system always do and what should it never do), Security, Scalability, Usability, etc. Research and pick what fits the context of your team.
Test Techniques: are there other test techniques you are often going to use? Examples: function testing, domain testing, stress testing, flow testing, claims testing, user testing, risk testing, performance testing, resilience testing, scenario testing etc. Research and pick what fits the context of your team.
Miscellaneous: if you are working with the scrum framework you probably have a Definition of Done (for user stories and/or for complete releases) and Acceptance Criteria (specific for a user story). Those Scrum artefacts are about quality! No need to repeat them in your test strategy, but it is wise to mention them.
This list seems really long already, and it is not complete at all, so make sure to pick the things that really matter to your team. Keep the test strategy short (but truthful) or nobody is going to look at it again. Be aware that testing activities should be picked out carefully, you only have so much time and money to do them. You should always try to pick the ones you think are going to give the most information about your software. Testing cannot be complete, it is sampling at best, so let that fact guide your choices.
Comments ()