Yunhao Jiao
Flaky tests, questionable CI results, and engineers bypassing the suite are signs that shipping has become messy. You have tests, but some fail when button text changes. Your most experienced engineer skips the local suite because they know which tests cannot be trusted. The underlying issue is strategic, not catastrophic.
That is not a discipline issue. It is a strategy issue, and you can fix it.
What a test strategy really means
A test strategy is not a document. It is a set of team agreements about the guarantees your suite should provide and how it will keep providing them as the codebase evolves.
Without a QA org, those agreements often stay unwritten. Senior developers know them, junior developers guess, and new hires overlook them. Eventually, trusted tests sit beside known gaps that nobody has time to address.
Writing the strategy down takes about two hours. It makes you decide which layers to test, what enough coverage means, and who owns a broken test.
Getting the test layers right
The pyramid model is sound, but teams often misuse it. They turn "many unit tests" into tests of implementation details, so refactoring breaks the suite. Then they add end-to-end tests everywhere, creating a suite that takes 40 minutes to run and fails during network blips.
Without a QA org, use this rough split:
- Unit tests for pure business logic: data transformations, validation rules, and computation functions. If one test needs more than one mock dependency, reconsider its layer.
- Integration tests for system contracts: API endpoints, database queries, and external service calls. In CI, run these against a real database rather than an in-memory stub.
- End-to-end tests for three to five essential user flows: sign-up, the core action, and the critical checkout or submission path. Test the flows whose failure makes the product unusable, not every happy path.
The exact percentages matter less than the rule: test behavior, not implementation. A renamed internal function should not break a useful test.
Setting a meaningful coverage floor
Coverage thresholds seem objective, but they are easy to game. Tests that assert almost nothing can still produce 80% line coverage. The CI dashboard stays green while the suite offers little protection.
A better approach is to identify your ten riskiest user flows, where bugs could cost money or user trust. Test those paths directly, then measure their coverage instead of chasing an aggregate line-coverage threshold.
After those critical paths are stable and covered, the percentage becomes useful because it rests on tests that catch real regressions.
Ownership: who fixes a broken test
One decision matters more than any technical choice: a broken test is the team's problem. If you skip failures or wait for someone else, the suite can become useless within months.
We built TestSprighte after seeing this pattern repeatedly. A broken test becomes pending, stays there, loses its context, and gets deleted. The coverage loss goes unnoticed because nobody tracks the flow it protected.
Two rules help. First, every failing test blocks the build. If it is intermittent, fix it instead of retrying until it passes. Second, the developer whose change caused the failure owns the fix, not the original test author. That creates fast feedback and prevents "I didn't write that test" from becoming an excuse.
Where automation helps a small team
Automated test writing helps where manual writing struggles: frequently changing UIs with drifting selectors, features shipping faster than tests can be updated, and teams too small to assign test maintenance to one engineer.
Manual test writing is not wrong. The maintenance burden simply grows faster than feature velocity. Four engineers shipping daily cannot treat maintenance as background work. Automate it, or the suite will quietly collapse into something nobody trusts.
Two questions to ask each quarter
To maintain a test strategy without dedicated QA, ask two questions about the suite every quarter.
First: in the last 90 days, which failures did the suite catch before production? If you cannot name a few, it is missing the things that actually break.
Second: which production bugs should the suite have caught? For each, decide whether to add coverage. If not, record why. Choosing not to test something is a valid strategy decision; missing the gap is what costs you.
A test strategy without a QA org can last. It takes more deliberate effort, and that effort is the practice. You cannot delegate thinking to a function that does not exist. Review the suite on a cadence, make it serve your decisions, and treat it as infrastructure, not overhead.