I think the Agile testing quadrants could be used as a guideline to find a balance to which test cases to define , which to automate and which to execute manually.
Our current user story high level test strategy template boils down to the following bullets:
- Test cases and examples: Key is here to question what are the things we want to test for this user story and to create a checklist to verify we tested them?
- Risk assessment: Do a risks analyses for the feature and check if they are covered by tests
- Automated test coverage: Question which of the test cases are we going to automated.
- Checklist based code review
- Usability: Execute a usability test if applicable
- Performance: Question possible performance issues with the team
- Security: Question possible security issues with the team
We copy this template and at the start of an user story we start filling the template with test idea's and discuss them with the full team. We push to do this in parallel to coding to prevent mini waterfalls.
This list is dynamic as we learn more and find new types of issues we want to prevent. For each defect that does reach production we execute a root-cause analyses and update our template to prevent similar issues in the future. Also we check our template regularly to see if items on there are still relevant.
Keep in mind that in Agile:
Testing no longer means testing
Confused? We can imagine! The purpose of testing used to be fairly
clear – “Testing is the process of executing a program with the intent
of finding errors”. This changes when adopting agile and
lean development
read more...
Suggested reads: