How to write test cases that actually find bugs

A good test case has three things: clear steps someone else can follow without asking questions, an explicit expected result for each step, and coverage of edge cases that real users will hit. That's the whole framework. Everything else is detail.

Most test cases fail at finding bugs not because teams don't write them, but because they write them poorly. Vague steps. Missing preconditions. Assumed knowledge. The Katalon State of Quality 2025 report found that 82% of testers still perform manual testing daily, yet 55% cite insufficient time for thorough testing as their top challenge. When you're short on time, every test case has to pull its weight.

Here's how to write test cases that actually catch problems before your users do.

What makes a test case actually useful#

A useful test case finds bugs that would otherwise reach production. That sounds obvious, but here's the distinction: a complete test case covers a scenario. A good test case covers the scenario in a way that makes failures impossible to miss.

James Bach puts it well: "Good testing is a challenging intellectual process." Writing good test cases is the same. It requires thinking about what could go wrong, not just confirming what should go right.

The best test cases share four things:

• Atomic -- they test one thing. If it fails, you know exactly what broke.
• Independent -- they don't depend on another case's outcome. Any case can run in isolation.
• Repeatable -- anyone can execute them and get the same result on the same build.
• Specific -- no room for interpretation. Steps, data, and expected results are all spelled out.

The four parts of a test case#

Every test case has four parts. Skip one and you're leaving room for confusion.

Preconditions#

What must be true before the test starts. The environment, the user state, any data that must exist, which page the tester should be on.

Bad: "User is logged in" Good: "User is logged in as admin@example.com (role: Admin) on the staging environment. At least one project exists in the account."

Steps#

The specific actions a tester performs, in order. One action per step. Not two or three bundled together.

Bad: "Fill out the form and submit it" Good:

1. Navigate to /settings/profile
2. Clear the "Display Name" field
3. Enter "Test User 2026" in the "Display Name" field
4. Click the "Save Changes" button

Expected result#

What should happen after each step, or at minimum after the final step. This is the part teams skip most often, and honestly, it's the whole point. Without an expected result you don't have a test, you have a walkthrough.

Bad: "Profile is updated" Good: "Success toast appears with text 'Profile updated.' Display Name field shows 'Test User 2026.' Refreshing the page preserves the change."

Test data#

Concrete values the tester should use. Never write "enter a valid email" when you mean "enter testuser@example.com." Ambiguous test data leads to inconsistent results. I've seen two testers run the same case on the same build and one passes, one fails, purely because they picked different input data.

Same scenario, two ways#

Let me show the same scenario written poorly and written well.

Bad test case#

Title: Test checkout Steps: Go to checkout and complete a purchase Expected: Order is placed

This tells the tester almost nothing. What product? Which payment method? What address? What does "order is placed" look like — a confirmation page, an email, a database entry?

Good test case#

Title: Checkout with credit card — standard shipping Precondition: Logged in as buyer@example.com. Cart contains 1 item (SKU: WIDGET-001, price: $29.99). Shipping address saved in account. Steps:

1. Navigate to /cart
2. Click "Proceed to Checkout"
3. Verify shipping address shows "123 Test St, New York, NY 10001"
4. Select "Standard Shipping ($5.99)"
5. Enter credit card: 4242 4242 4242 4242, Exp: 12/27, CVC: 123
6. Click "Place Order"

Expected result: Order confirmation page displays with order number. Total shows $35.98 (item + shipping). Confirmation email arrives at buyer@example.com within 2 minutes. Order appears in /account/orders with status "Processing."

Night and day. The second version can be executed by anyone on the team, including someone who's never seen this feature, and they'll know exactly whether it passed or failed.

Write for someone who doesn't know the feature#

Here's a test I use: hand your test case to a teammate who hasn't touched the feature. Can they execute it without asking you a single question? If not, it needs more detail.

This catches the most common problem in test case writing: assumed knowledge. You know the "Save" button is at the bottom of the page. You know the confirmation email takes 30 seconds. You know the dropdown only appears after selecting a specific option. The person running your test case doesn't know any of that.

Writing clear test cases takes discipline at first. After a few weeks it becomes automatic, and you'll start noticing vague steps in other people's work too.

In TestRush, test scripts use a nested structure: headers group related scenarios ("Payment Methods") and child items are the individual test steps underneath. This forces clarity because each item has its own expected result in the notes field.

Edge cases checklist#

Happy paths are easy to test. Bugs live in the edges. Here's the checklist I come back to for almost every feature:

Input validation#

• Empty fields — submit every form with each field blank, one at a time
• Maximum length — paste 10,000 characters into a text field meant for 255
• Minimum length — enter a single character where a longer string is required
• Special characters — <script>alert('x')</script>, emoji, Unicode, SQL injection patterns (' OR 1=1 --)
• Leading/trailing spaces — " email@test.com " should be trimmed or rejected

Permissions and access#

• Wrong role — try the action as a viewer when it requires admin
• Expired session — let the session timeout, then try to save
• Concurrent access — two users editing the same record simultaneously
• Direct URL access — paste a restricted URL while logged out or as a lower-permission user

State and timing#

• Double submission -- click the submit button rapidly twice
• Back button -- complete a flow, hit back, try to complete it again
• Timeout behavior -- what happens when an API call takes 30 seconds?
• Empty state -- view the page when there's no data at all. Zero items, brand new account
• Pagination boundaries -- page with exactly 0, 1, and the max items per page

Data boundaries#

• Zero and negative values — enter 0 or -1 in a quantity field
• Date boundaries — Feb 29 on a non-leap year, Dec 31 to Jan 1 transitions
• Currency precision — amounts like $0.001, $999,999.99, and $0.00

You won't write separate test cases for every item on this list for every feature. But scanning it before you finalize your test cases catches gaps that cause production bugs.

When NOT to write detailed test cases#

Not everything needs a scripted test case. Exploratory testing, where you investigate the software without predefined steps, finds bugs that scripted tests miss.

Skip detailed test cases when:

• You're investigating a new feature for the first time. Explore freely, take notes, then write test cases based on what you discover.
• The UI is changing rapidly. Writing detailed step-by-step cases for a screen that redesigns every sprint is wasted effort. Write high-level scenarios instead and detail them once the design stabilizes.
• You're testing usability. "Is this confusing?" can't be captured in a pass/fail step. Exploratory sessions with notes work better here.
• You're chasing a specific bug. When reproducing a reported issue, you don't need a formal test case. You need to experiment until you find the trigger.

The best QA teams use both: scripted tests for regression and critical paths, exploratory sessions for new features and creative bug hunting.

Common mistakes#

1. Writing steps that are too vague. "Test the search feature" is a reminder, not a test case. If a tester has to guess what you meant, rewrite it.

2. Skipping expected results. A test case without an expected result is just a task list. "Click Submit" isn't a test — "Click Submit and verify the success message appears within 2 seconds" is a test. The expected result is what makes a step verifiable.

3. Bundling multiple verifications into one case. A test case that checks login, profile update, password change, and logout is four test cases duct-taped together. When it fails, you don't know which part broke. Keep cases atomic.

4. Copying test cases without adapting them. AI tools can generate test cases fast. The PractiTest 2025 report found that 40.58% of testers already use AI for test case creation. But generated cases need human review. AI misses your domain context, your business rules, the weird edge cases that only exist because of how your product evolved.

5. Never updating old test cases. Features change. A test case written six months ago for a UI that's been redesigned three times will confuse testers and produce false failures. Review and prune quarterly.

6. Writing test cases after the feature ships. By then, the details are fuzzy, the urgency is gone, and the developer who knows the edge cases has moved on. Write test cases during development, ideally while reviewing the requirements or design spec.

FAQ#

How many steps should a test case have?#

Aim for 3 to 10 steps. Fewer than 3 usually means the case is too vague — you're skipping intermediate actions or verifications. More than 10 means you should split it into focused cases that each test one specific thing. Long test cases also cause "tester fatigue" — by step 15, attention drifts and bugs get missed.

Should I include test data in the test case?#

Always. "Enter a valid email" means something different to every tester. Specify the exact email, password, credit card number, or whatever data the test requires. If your team uses shared test data, reference it by name or link to the test data document. Concrete data ensures consistent execution.

How long does it take to write good test cases?#

Industry estimates put manual test case writing at 40-60 hours per 100 test cases when done thoroughly. AI-assisted generation can draft initial cases in minutes, but review and refinement add time. Don't let perfect be the enemy of good. A decent test case that gets executed beats a perfect one sitting in a backlog.

What is the difference between a test case and a test scenario?#

A test scenario is the "what" — "verify user can reset their password." A test case is the "how" — the specific steps, data, and expected results for executing that scenario. One scenario often produces 3-5 test cases: reset with valid email, reset with unregistered email, reset with expired link, reset twice in rapid succession. Scenarios are for planning. Test cases are for execution.

When should I update existing test cases?#

Update when: the feature's UI or behavior changes, a tester reports confusion during execution, a bug slips through that your cases should have caught, or during your quarterly review cycle. Stale test cases are worse than no test cases, because they waste execution time and create false confidence. In TestRush, you can update test script items directly and the changes apply to all future runs. Check the FAQ for more on managing test scripts.

Want to try this in practice? Start a free trial or open the live demo to see keyboard-driven test execution.