Why do you need a QA strategy?
Quality assurance is full of strategic choices steering the daily work. There are lots of questions you need to think of and answer, to assure quality and to organize testing etc. Should I hire professional testers or use in-house people? How much should I budget for test automation? What approaches and methods should I use for testing the product? How should I manage test data and technical debt? The list is long, almost never ending.
If you don’t make the decisions, then someone else will.
Strategic thinking around QA is often forgotten, the strategy might be hidden or not broadly understood. It is super easy to jump directly to the test execution, without thinking how and what to test in your context. However, a strategy always exists. Even if it is not recognized, written, communicated or consciously used. A hidden QA strategy is usually based on unproven preconceptions and other unstructured experiences. Not using a QA strategy is a strategic choice too, though in that case you can’t get the outcome and impacts you desire, like you can with a well known and communicated strategy. If you do not make the decisions, then someone else will. So the question is, who decides how to run your QA.
Strategy is the steering wheel that guides action. It is the underlying process that defines all quality and testing activities and methods. It describes the factors that affect the QA process and the means to address those factors in a way that your context requires. It is important to keep the steering wheel in your own hands, even when the actual testing is outsourced.
What are organizational and
operational QA strategies
and why are they important?
They affect both, the line management and operations like product development and support functions. Let’s look at these two strategy perspectives in more detail.
What is an organizational level QA strategy?
Organizational level strategy is mainly targeted to help in QA governance. It sets the scene and explains the context for the people in the operational level from an organization point of view. Organization here can be a company, domain or department - it doesn’t matter. The typical target group is directors and managers, who purchase, steer or manage testing services in their organization. These people are not necessarily leading testing on an operational, daily level. For example, an internal IT department (led by a CxO), or any domain under it (led e.g. by Head of or a Director), can have its own QA strategy which guides all QA activities in all projects within the same organization. A QA strategy harmonizes the terminology and practices the organization uses. It can have many names depending on the company, e.g. testing principles, test policy or QA guidelines.
While organizational level strategy serves many projects and teams within the organization, It is not general purpose and reusable in other organizations. The strategy should tackle the specific challenges of the organization and not be built out of tools you can find faster with a quick internet search. This also poses one of the main challenges its creation. How to make it not too generic and, at the same time, not too detailed? It is important that the target group gets value from it, but it leaves enough space for the people at the operational level.
What is an operational level QA strategy?
Strategy as the Foundation
Understanding the important factors for quality assurance allows one to create a cohesive strategy from which a plan can be designed.
Usually a strategy exists in qa but it is seldom written down or communicated; or even understood.
By understanding the context and the variables, a quality assurance strategy can be formed. It’s easier to navigate through the project lifecycle when you have a map to follow.
Operational level QA strategy is targeted at developers, testers, product management and business people within the same program, project or product they all work for. The target group could be one or several development teams and the scope of the strategy should be fairly wide.
It should help
Internally with setting and measuring QA goals and onboarding new people.
Externally to maximize the impact of QA activities to product management and business.
Operational level QA strategy defines the quality goals, test design guidelines, tools and methods used on a daily, practical level. It has many names too, like QA or test strategy. We think that this kind of a test strategy, combined with the definition of done (DoD) and test charters for testing sessions will eventually replace traditional test plans.
You can start building a QA strategy by thinking of these six dimensions:
Risks:
What threatens product value?
Missions:
What are we trying to achieve?
Quality Aspects:
What kind of things are valued?
Product:
What limitations or opportunities does the product set?
Project:
What limitations or opportunities does the project set?
Testing:
What methods can we use in testing?
At Hidden Trail we’ve used one-to-one interviews and the model above to co-create strategies together with our clients. This model is a tool for gathering as much data from the relevant people to enable the creation of a balanced strategy.
It is important to understand that the strategy is living documentation, it evolves over the product lifecycle and when the context around it changes. These changes can be things like business environment changes, changes to the ways of working resulting from a retrospective etc. This way the strategy will be actions, not just words in a document. A good operational QA strategy is a guidebook and a source of inspiration for everyday work in the development and testing teams.
Need sparring with your strategy? Contact us
Watch the following video for a more detailed talk from Jani And Marko on the subject of strategies and their benefits (in Finnish). The Video was recorded on 16.2.2022 as part of Prove Expertise Oy’s live-event series. The Session was hosted by Antti Niittyviita (Prove).
Video recording by: testauskoulutus.com