Acceptance criteria for a use case should include one test case for the main path and one for each alternate path

What should the acceptance criteria for a use case include, at minimum? A quick answer you’ll hear in many teams is: one test case for the main path and one test case for each alternate path. Yes, that’s the gist. It may sound straightforward, but it’s a principle that keeps software reliable when real people start using it in a variety of ways.

Let me explain why this matters, and how to apply it without fuss.

The core idea: main path plus every alternate path

Think of a use case as a story of how someone uses a feature. The “main path” is the story that goes as planned—the normal, successful flow. The “alternate paths” are the variations that can happen along the way, such as wrong input, exceptional conditions, or optional steps that change the usual flow.

If you want a solid baseline for acceptance, you set up test cases that cover all those routes. The main path confirms the core function works. Each alternate path confirms the system handles deviations gracefully. When you combine them, you get a fuller picture of how the system behaves under real-world conditions.

Two reasons this approach pays off

• It catches the obvious and the edge. The main path is the most common scenario, but life isn’t always smooth. Users make mistakes, systems time out, data is missing. By testing the main path and every alternate path, you reduce the risk of surprises after release.

• It creates a shared mental model. Developers, testers, and stakeholders all benefit from a clear, explicit set of cases. When everyone can point to “main path” and “alternate path 1, alternate path 2,” communication is faster and decisions are more grounded.

A practical example you can relate to

Let’s walk through a real‑world‑friendly use case: user access to an online portal.

Use case: User logs into the portal

• Main path test case (the path that should work smoothly)

• Preconditions: User has an active account; user knows username and password.

• Steps: Go to the login page, enter valid username and password, click Log In.

• Expected results: User is authenticated, redirected to the dashboard, a session is created, and a welcome message appears.

• Why this matters: This verifies the core mechanism—authentication and access to the main feature set.

• Alternate path test case 1 (invalid credentials)

• Preconditions: Same as above, but the password is incorrect.

• Steps: Go to the login page, enter valid username and wrong password, click Log In.

• Expected results: An error message indicates invalid credentials; the user remains on the login page; no session is created.

• Why this matters: It confirms the system doesn’t grant access when credentials are wrong and that feedback is clear and actionable.

• Alternate path test case 2 (account locked)

• Preconditions: The user account is marked as locked in the system.

• Steps: Go to the login page, enter valid username and password, click Log In.

• Expected results: A message states the account is locked and guidance is provided, such as how to contact support or unlock the account; no access is granted.

• Why this matters: It ensures the system handles security conditions gracefully and communicates next steps.

What to include in acceptance criteria for clarity

• Specific test cases for every path: As shown, the minimum is one for the main path and one for each alternate path.

• Clear inputs and expected outcomes: Don’t leave room for guesswork. State exactly what the user enters and what the system must do in response.

• Preconditions and postconditions: Precondition sets the starting state; postcondition describes the final state after test execution.

• Non-functional hints where relevant: If performance, security, or reliability is a concern for a path, add a line about the target behavior (e.g., response time, encryption use, or audit logging).

• What success looks like: A short, unambiguous statement for the acceptance of the path.

A note on scope and balance

• Don’t overdo it with every tiny variation. The goal is coverage that reflects real usage, not an exhaustive catalog of every possible micro-edge. If a path is highly unlikely or trivial, you can fold it into a broader negative scenario, but make sure the main path plus the meaningful alternates are still present.

• If you have multiple alternate paths, keep the test cases proportionate. Too many tiny branches can blur the focus. The line you want to walk is: enough to reveal issues without creating chaos in the test plan.

How to write good acceptance criteria in practice

• Start with a simple template. For each use case, outline:

• Path name (Main path, Alternate path 1, Alternate path 2, etc.)

• Preconditions

• Steps (numbered)

• Expected result

• Notes or risks (optional)

• Use precise language. Replace vague phrases like “the system should behave properly” with concrete outcomes: “the session is created and the user is redirected to the dashboard.”

• Include boundary conditions. If there are limits (for example, maximum length of input), note what happens when the limit is reached.

• Tie criteria to user goals. Frame outcomes in terms of user value, such as “the user gains access,” “the user receives helpful feedback,” or “the user can recover from an error smoothly.”

• Make it traceable. Link each test case to a specific step in the use case diagram or a workflow. That helps when someone asks, “Where does this fit?”

Common pitfalls to avoid

• Ambiguity: If the acceptance criteria aren’t crystal clear, testers will interpret them differently. Clarify inputs, flows, and expected outcomes.

• Missing alternates: Failing to cover a key deviation leaves gaps that can simmer into bugs later.

• Too prescriptive in a brittle way: Avoid tying the criteria to a single implementation detail that might change. Focus on behavior, not exact UI labels if they aren’t essential.

• Ignoring non-functional aspects: Security, performance, and accessibility can matter for some paths. Mention them when relevant so they’re not an afterthought.

A lightweight template you can adapt

• Use case: [Name]

• Main path

• Preconditions: [conditions]

• Steps: 1) [step], 2) [step], …

• Expected results: [outcome]

• Alternate path A

• Preconditions: [conditions]

• Steps: [steps]

• Expected results: [outcome]

• Alternate path B

• Preconditions: [conditions]

• Steps: [steps]

• Expected results: [outcome]

Bringing it all together

Here’s the heart of the matter: the acceptance criteria for a use case should, at a minimum, specify one test case for the main path and one test case for each alternate path. This approach gives you a robust baseline that mirrors how people actually interact with systems. It helps teams catch issues early, reduces back-and-forth, and builds confidence that the software behaves as expected across common and varied scenarios.

If you’re working on modeling these scenarios, you’ll often use simple diagrams to keep everyone aligned. A straightforward use case diagram, a sequence of the main path, and a couple of alternate-path stories can make the intent crystal clear. Tools like JIRA or TestRail can help you organize these test cases and track coverage. And if you’re documenting in Confluence or a similar wiki, a clean, repeatable template makes it easy to keep things consistent across a product line.

A few last thoughts to keep the momentum

• Start small, then expand. Get the basics right with a single use case, its main path, and two alternates. Once that feels solid, roll out a few more scenarios to broaden coverage.

• Talk with your teammates. The best criteria emerge when testers, developers, and product folks share a quick chat about real-world use and edge cases.

• Revisit and refine. As features evolve, re-check acceptance criteria. A path that was once critical might fade, a new one might appear. The goal is staying current, not locking in yesterday’s plan.

In the end, it comes down to clarity, coverage, and courage to test what users might actually do. The main path confirms the heart of the feature works. Each alternate path checks how it behaves when things aren’t perfect. Together, they form a practical, human-centered approach to defining what “done” looks like.

If you’re ever unsure, ask a simple question: “What could a user try next, if something goes wrong?” Answer that for each path, and you’ve built a solid set of acceptance criteria that makes teams stronger and software more trustworthy. And that’s a story worth telling across every project.