The Test Case Trap
Every QA team I've seen in early stages does the same thing: they start counting.
How many test cases do we have? How much coverage? What percentage is automated?
These are reasonable questions. But they're not the right first questions. They're outputs. What produces them — the structure, the thinking, the decisions about what to test and how to organise it — that's the architecture. And that's almost never discussed until something breaks badly enough to force the conversation.
What Test Architecture Actually Means
It's not a diagram. It's a set of decisions.
- ▸Where does each type of test live?
- ▸Who owns it, and what triggers it?
- ▸What's the contract between test layers?
- ▸When a test fails, can you trust the signal?
- ▸How do you add the tenth feature without slowing the suite to a crawl?
These decisions compound. Make them thoughtlessly early and you'll spend years paying down the debt — slow builds, flaky tests, no one willing to touch the suite.
The Test Pyramid Is Not Enough
Everyone knows the pyramid: lots of unit tests, fewer integration tests, even fewer E2E tests.
What the pyramid doesn't tell you:
- ▸Who decides which tests go where?
- ▸What do you do when a feature spans all three layers?
- ▸How do you handle tests that are "unit-ish" but need a database?
- ▸What's your policy for tests that keep flaking?
The pyramid is a starting point, not a strategy.
What I've Learned Leading QA
The most valuable thing I do isn't writing tests. It's making the decision framework that lets others write the right tests without asking me every time.
That means:
1.**Clear ownership** — every layer of testing has a team that's accountable for it
2.**Written entry and exit criteria** — not assumptions, actual documents
3.**A flakiness budget** — how many retries are acceptable before a test gets fixed or deleted
4.**A "delete first" culture** — a test that doesn't provide signal is worse than no test at all
The Uncomfortable Truth
Good test architecture means you'll write fewer tests. Not more.
It means some things you'd naturally want to test at E2E level belong at unit level. It means some test cases should just be deleted. It means being comfortable with the gaps that remain — because you've thought about the cost of covering them.
That restraint is harder to sell than a 2000-test automation suite. But it's what actually ships fast with confidence.