What the study answers
Four questions, in this order, because getting the order wrong is how most automation budgets get wasted:
- What is stable enough to be worth it. A flow that has not changed its structure in a year is a good automation candidate. A screen your product team is still iterating on weekly is not — you would be paying to rewrite tests, not to catch regressions.
- What it will actually cost to maintain. The build cost is the part everyone estimates. The maintenance cost — someone owns broken tests, someone updates locators when the UI shifts — is the part that sinks projects, and it is rarely written down anywhere before the tool is bought.
- What tool fits the team you have, not the team a conference talk assumes you have. A framework nobody on the team can debug at 6pm before a release is a liability with a subscription fee.
- What the realistic payback horizon is. Automation pays off when a suite runs often enough, and catches enough real regressions, to beat the cost of the manual checks it replaces. That crossover point can be calculated — roughly, but honestly — before you commit.
Why most automation projects fail the ROI test
Not because the engineers were bad. Because the decision to automate was made on enthusiasm rather than on the four questions above:
- Chasing a coverage percentage instead of the behaviours that actually break in production.
- Automating the UI end to end when a faster, more stable API-level test would have caught the same regression.
- Choosing the tool that was trending, not the one the team already knew how to debug.
- No one owns the suite once it is built, so failing tests get skipped rather than fixed — and six months later nobody trusts a green run either.
What you get
A written recommendation: automate, do not automate yet, or automate this specific subset first. It names the tool we would use in your context and why, with the realistic maintenance cost stated in hours per month, not hand-waved as "low."
If the answer is "automate," the document also gives you a rollout plan: the first target, in what order the rest follows, and the point at which the suite starts paying for itself. If the answer is "not yet," it says what needs to change first — usually a stability or a process problem, not a tooling one.
How it runs
The scoping session is free and lasts an hour: what you are considering automating, why now, and what has already been tried. It tells us whether a full study is justified.
The study itself reviews the target flows' actual stability history, the team's current tooling and skills, and the delivery cadence the suite would need to keep up with. A few days, not weeks — this is a decision document, not an implementation.
Before and after
If you already know you want to automate and the open question is how to structure the effort — scope, levels, environments, ownership — that is test strategy, not a feasibility study. If you are not sure where your test practice stands at all, start with the broader quality audit.
Once the study says "automate this," turning the recommendation into a running, maintained suite is process automation — the delivery side of the same engagement.