Take a random testing book or manual from 20 to 5 years back, and you will encounter the concept of the test strategy. A companywide description of “how” testing should be done, regardless of the product, project or process you should be testing. You could of course deviate from that test strategy when defining your test approach in your test plan, but you needed to have valid reasons for doing so.
Nowadays, with multi-disciplinary teams, CI/CD pipelines and vibe testing, that old test strategy seems a relic from very dark, far-gone ages. However, overall software quality has not improved due to all of the above. Yes, we’re able to release faster, and we have cut costs on manual testing, but customer experience has certainly not improved and neither did our technical (code) debt.
It’s time to let the old test strategy respawn. It’s time for a (software) quality strategy. Quality not identified with testing, but in the evaluation of the software and its related products and services. It all starts with a clear understanding between stakeholders about goals (the why). Next, we need to identify the problem(s) that we’re trying the solve (the what), together with our stakeholders (the who). All of that should result in a comprehensive overview that should translate to the “How”.
It’s the pivotal question, not even looking at an operational level: how can we provide adequate level of quality to our stakeholders? It’s a mix of requirements engineering (business analysis, functional analysis, modelling), software architecture practices and coding guidelines, topped off with a combination of both shift-left and shift-right testing.
Whoever joins the organization should be able to take the (software) quality strategy and translate/apply it their projects. What kind of elicitation techniques should we use? Which design patterns should be respected? What level of configuration management is recommended? Which branching practices should be adhere to? Do we advise to perform non-functional testing during or after every iteration? The list is not exhaustive and under continuous improvement.
The software quality strategy is not an endpoint, but a starting point. To start communication. To start a think process. To reconsider the efficiency and effectiveness of existing processes and approaches. To serve as a basis for a product, project, or phase test plan / test approach. To help new people on the team to focus on the essential parts that contribute to product quality.
