Many times, in agile projects/teams, we don’t write testing strategies based on assumptions such as:
There is so much uncertainty that we cannot plan.
Everything changes very quickly, it is not worth writing documentation.
But it is precisely in these environments where we most need to think, plan and design how we are going to test, what is the goal of our testing and what are our needs. Of course, those needs are going to change constantly and that is why we also plan:
How are we going to keep up to date ourselves?
How are we keeping up with these changes?
How do we maintain our quality standard across the different challenges that arise?
but… what is a Testing Strategy?
A testing strategy is based on, words more, words less, planning how we are going to test an application, mainly defining Scope and Coverage
With a testing strategy, we clarify the full picture, reduce uncertainty about the quality of a product, and how to implement testing activities throughout the entire software development process:
Defining good user acceptance criteria.
Planning and designing the tests that we are going to apply/execute.
Defect/error tracking and their resolution.
Auditing our tests.
Receiving feedback from users/customers.
What are the basics our testing strategy should consider?
Automation or manual?
What is the purpose of our testing? what is the product/process we are testing and what is its purpose?
What is our quality concept/philosophy? and I mean the team and the company/organization, because we cannot be the only ones responsible for the quality of a product.
How do we involve the entire team in quality?
Is it a mobile app? is it a website? only one API? the tools we will choose depends on this.
Automation or manual?
What types of tests are we going to apply (functional and non-functional)?
Can we automate? which tools suit best the product/process?
Was testability taken into account when the application was designed?
Which software are we going to use for tracking stories and bugs? How and where are we going to document our activities? where do we register and organize our tests?
What are the risks of our product? and the risks of our tests? is everything testable?
What risks can we identify in all and each one of the phases of the software development process?
How long do we have to test and automate? How often do we release? Which types of tests are we going to apply (functional and non-functional)? how long do we need to achieve adequate coverage (not perfect but adequate)?
Which are our time constraints and how do we prioritize?
Which resources do we have? not only tools but humans. What types of tester profiles do we need to achieve our goals? What training and experience should they have?
Which is our budget and how do we stick to it?
What are we going to test and what not?
How are we going to measure quality? what gets measured, gets managed
If you cannot make a strategy like this for reasons of time or project uncertainty, a summary like this one will be efficient:
No strategy is standard nor set in stone, it depends on the needs of your project and team, but with no doubts, establishing a strategy helps us define the scope of our testing, and as such, the entire team must contribute.
We are not quality police and therefore we do not make decisions related to the quality of our products by ourselves. Scope and Coverage are our keywords.
It also helps us to be on the same page, which is crucial to the success of any project.