In an ideal world, all software would have 100% test coverage and be thoroughly tested before anything is shipped. There would be a test case for every possible workflow, and no one would have to worry about bugs sneaking into production. Unfortunately, we live in the real world where time, budget, and engineering capacity limit how much you can get done each week.
When you’re in the first stages of building out your QA tests, it’s critical to consider these limitations and make strategic decisions. Since your goal should be to prevent the most critical and visible bugs first, we recommend going broad across your whole product before going deep on a single feature.
Start with the workflows your customers use most. Broad coverage provides your team with faster feedback, fewer brittle tests, and improved detection across the entire app. It creates a stable base to build from, and helps you decide where to go deeper next. Do it well, and you’ll get real value from every test you write.
Focus on high-impact workflows before deep edge cases
A common mistake teams make is over-indexing on the most complex features, assuming that’s where things are most likely to break. But complexity isn’t the same as criticality. The real risk lies in high-traffic, high-value workflows where users spend a significant amount of time. When those break, people notice.
Your team’s first 100 tests should be a broad survey of your application’s major customer-facing interactions. Not 50 branches of a multi-step form. Your primary goal should be a reliable check of the application's overall health. You’ll have plenty of time to go deeper later.
Breadth means testing every critical customer interaction
Imagine a banking application. Of the hundreds of workflows, five make up the core user experience:
- Logging in
- Viewing balances
- Reviewing transactions
- Depositing checks
- Transferring money between accounts
These five flows touch different services and components, but from the user’s perspective, they are the product. When one breaks, users hit errors fast. They file support tickets, become frustrated, and start to lose trust. That’s why these workflows would be your top test priorities—even if the implementation seems simple.
Now compare that to going deep on a single workflow, like money transfers. If you spend all your time building tests for internal transfers, external accounts, balance limits, retries, and a multitude of edge cases, you’ll remain blind to vast swathes of the user experience.
Start broad to get faster feedback and smarter tradeoffs
End-to-end (E2E) tests are expensive to maintain, no matter what tool you use. Each one adds overhead—investigating failures, updating selectors, and rewriting logic when the product changes. That maintenance burden multiplies with deep coverage in complex features, especially in the early stages. These areas change frequently, and the cost of upkeep often outpaces the benefits.
As stated above, when you go broad, you allow yourself to catch issues across the app sooner, and when something breaks, you know whether it’s isolated or part of a bigger problem. That early signal helps you spot patterns—like a bad deployment or a regression in shared code—without chasing ghosts.
It also shows you where to go deeper. If a test fails every week, it probably needs more coverage. If nothing ever breaks in a part of the app, it can probably wait. Such coverage provides you with real data to make informed tradeoffs. Without it, you’re flying blind.
Use a risk-based coverage model
You don’t need to test everything at once, but you do need to understand the surface area. Start by mapping all major workflows in your app, then use a risk-based model to identify the ones worth testing first. These are the workflows that break production, block releases, or drive support tickets when they fail.
This funnel approach—broad mapping, focused coverage—helps you allocate your test budget where it matters most, and add coverage just-in-time when new features or bugs emerge. These dimensions reflect where breakages cause the most damage—operationally, financially, and technically. Use them to make sure your first 100 tests cover the highest-value ground:
- User activity: Start with customer activity. Pull logs or analytics if available. Identify the 10–15 most trafficked workflows and cover those first.
- Revenue impact: Flag any flow that, if broken, stops the business from making money—checkout, subscriptions, billing updates.
- Dependencies: Prioritize workflows that rely on other systems. These tests catch upstream changes before they cause downstream failures.
- Security and compliance: If your product handles sensitive data or operates in a regulated space, build tests to confirm access control, encryption, and safe error handling.
- Recency: New code breaks more often than old code. Focus on recently shipped features while they’re still unstable.
- Product complexity: Complex features are tempting to test in depth early, but that can trap teams into low-impact coverage. Instead, include one or two tests that touch the core path through these features—enough to catch major breakage without overcommitting to edge cases. Save deep coverage for later, once you know where the real risk is.
No single test needs nor is likely to hit all six risk areas. But your early coverage should focus on workflows that score high in at least two or three. The risk-based coverage model helps you do that, so your first 100 tests reduce risk instead of just checking boxes.
Breadth now gives you room for depth later
Once you’ve established stable coverage around core workflows, expanding becomes significantly less risky. Adding edge case tests in the billing portal won’t distract from catching serious failures elsewhere. Testing new product areas won’t come at the cost of maintaining older ones.
In other words: breadth buys you time. It provides an alerting layer that doesn’t just validate behavior, but also protects developer velocity. And it stops you from blowing your test budget on a part of the app nobody uses.
.svg){kind=logo}
