QA Strategy and Test Planning
A QA strategy is the document written before testing starts, fixing what is in scope, what matters most and what a passing release looks like. GullySystem builds this plan for teams testing for the first time.
What a Test Plan Actually Settles
A QA strategy is agreed before a single test case is written: which modules, roles and journeys are covered, which risks are ranked highest, which environments and data are used, and what condition a build must reach before it is allowed to release. Without it, testing becomes whichever screens whoever is free that day happens to click through.
What Goes Missing Without One
- Two people check the same screen while a paid journey is never opened
- Nobody agreed what severity blocks a release, so the argument happens on release morning
- A new tester joins with nothing written down to read, only word of mouth
- The vendor decides for itself what counts as adequately tested
- There is no record to point to when a customer or auditor asks what was checked
What the Document Contains
Scope and Exclusions
Which modules, user roles, journeys and outside integrations are covered, and which are explicitly left out so nobody assumes they were checked.
Risk-Based Order
Journeys ranked by what it costs the business if they fail, so limited testing time goes to the paths that carry money or compliance first.
Entry and Exit Criteria
What state the build must be in before testing starts, and what result it must reach before a release is allowed to go out.
Environment and Data Plan
Which environment is used, how test data is sourced or masked, and which sandbox accounts are needed for payment or messaging partners.
Roles and Reporting Rhythm
Who raises defects, who agrees severity, and how progress is reported to the person taking the release decision.
Where a Written Strategy Pays for Itself
A regional pharmacy chain adding online ordering across its branches has stock rules, prescription uploads and delivery slots that behave differently branch to branch. Before any test case is written, the strategy fixes which branches, which payment methods and which failure paths — a rejected prescription photo, a branch marked out of stock mid-order — are in scope, so testing does not quietly narrow to whichever branch is easiest to reach.
Who Keeps the Plan Afterwards
The strategy is written in plain language your own team can read and question before testing begins, and it stays with you afterwards as the reference every future release is measured against, whether or not we are the ones running that release.
Frequently asked questions
Do we need a written strategy if our own developers do the testing?
Yes, because the strategy is not about who tests — it is about deciding in advance what gets checked and to what standard. Developers testing their own work still benefit from an agreed scope and risk order, otherwise the same familiar path gets exercised release after release while the rest is assumed fine.
How is this different from a plan for a single release?
A QA strategy is the standing set of rules — scope categories, risk approach, severity definitions, environments — that every release plan then follows. A release-specific plan is a narrower application of that strategy to one build and one date. Teams testing for the first time usually need both written together.
What drives the cost of putting a strategy together?
The main drivers are how many modules, user roles and outside integrations exist, how much requirement documentation already exists to work from, and how many stakeholders need to agree on risk priority before the document is final.
What decides how long writing the strategy takes?
Mostly the availability of the people who know the business rules. Where requirements are already written and one stakeholder can approve risk order, a strategy comes together quickly. Where the rules live only in someone's head and several departments must agree, the workshops take longer than the writing does.
Can you write a strategy for software you did not build?
Yes — this is common. We need a working build or at least a detailed specification, access to whoever knows the intended business behaviour, and a list of what the business cannot afford to have wrong. Being independent of the build team is usually an advantage here, not a gap.
Will the strategy work with the tools we already use?
Yes. The document names your existing tracker, environments and sandbox accounts rather than asking you to adopt new ones, and it is written so any tester or vendor you bring in later can pick it up without re-learning your setup.
What do you need from us to get started?
Access to the application or its specification, a short list of what the business cannot afford to have broken, and one person who can settle risk-order questions when the requirement is silent. Existing requirement documents or user stories, if any exist, shorten the work considerably.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private