20 Test Case Examples for Web, Mobile & API Testing

Writing test cases from scratch is hard when you are staring at a blank page. Most QA teams do not struggle with the idea of testing; they struggle with turning that idea into clear, reusable, executable test cases that another tester can pick up and run without confusion.

That is why concrete test case examples are so useful. They show what "good" looks like: a clear title, realistic preconditions, actionable steps, and an expected result that leaves no room for interpretation.

In this guide, we will walk through 20 practical test case examples across web, mobile, and API testing. Use them as inspiration, adapt them to your product, and add them to your test case management process.

What a Good Test Case Looks Like

Before we jump into examples, it helps to align on structure. A useful test case is specific enough to be repeatable, but short enough to stay maintainable when the product changes.

Rule of thumb: If the expected result could be interpreted in two different ways, rewrite it. Ambiguous expected results create flaky manual testing just as surely as brittle selectors create flaky automation.

5 Quick Rules Before You Copy These Examples

• Write for your product, not a textbook. Replace generic names with real screens, endpoints, fields, and business rules.
• Separate one assertion from another. A single test case should validate one main behavior, not an entire workflow universe.
• Always include negative scenarios. Happy paths are not enough.
• Keep test data explicit. If the scenario depends on a specific user role, locale, plan, or payload, say so.
• Store examples in a real tool. Spreadsheets are fine at the beginning, but structured platforms like QA Sphere make reuse, execution, and reporting much easier as the library grows.

8 Web Application Test Case Examples

Web applications combine UI flows, business logic, browser behavior, and session state. These are the kinds of examples most teams need first.

1. Login with Valid Credentials

Preconditions: Active user account exists.

Steps:

1. Open the login page.
2. Enter a valid email address.
3. Enter the correct password.
4. Click Sign In.

Expected Result: User is authenticated and redirected to the dashboard.

2. Login with Invalid Password

Preconditions: Active user account exists.

Steps:

1. Open the login page.
2. Enter a valid email address.
3. Enter an incorrect password.
4. Click Sign In.

Expected Result: Login is blocked and a clear error message is displayed without revealing whether the email exists.

3. Required Field Validation on Sign-Up Form

Preconditions: User is on the sign-up page.

Steps:

1. Leave all required fields empty.
2. Click Create Account.

Expected Result: Required field validation messages appear for each mandatory field, and the form is not submitted.

4. Password Reset Flow

Preconditions: User account exists and mailbox is accessible.

Steps:

1. Open the login page.
2. Click Forgot Password.
3. Enter the registered email address.
4. Submit the request.
5. Open the reset email and follow the link.
6. Set a new valid password.

Expected Result: Password reset completes successfully and the user can sign in with the new password.

5. Add Product to Cart

Preconditions: User is on an in-stock product page.

Steps:

1. Select a product variant if applicable.
2. Click Add to Cart.
3. Open the cart page or mini-cart.

Expected Result: Selected product appears in the cart with the correct quantity, variant, and price.

6. Checkout with Promo Code

Preconditions: Cart contains eligible item and valid promo code exists.

Steps:

1. Open the checkout page.
2. Enter the valid promo code.
3. Apply the code.

Expected Result: Discount is applied correctly and the order total is recalculated in real time.

7. Session Timeout After Inactivity

Preconditions: User is logged in.

Steps:

1. Stop interacting with the application for the configured inactivity window.
2. Attempt to navigate or refresh the page.

Expected Result: Session expires securely and the user is redirected to login with an informative timeout message.

8. File Upload with Unsupported Format

Preconditions: User is on a screen that allows file upload.

Steps:

1. Choose a file with an unsupported extension.
2. Submit the upload.

Expected Result: Upload is rejected and the UI explains which formats are allowed.

6 Mobile App Test Case Examples

Mobile testing adds device state, gestures, permissions, interruptions, and network variability. These examples cover the most common risks.

9. First Launch Onboarding Flow

Preconditions: App is installed fresh on the device.

Steps:

1. Launch the app for the first time.
2. Swipe through onboarding screens.
3. Tap the final CTA.

Expected Result: Onboarding screens display in the correct order and the user lands on the expected next screen.

10. Push Notification Permission Handling

Preconditions: App prompts for notification permission on first use.

Steps:

1. Launch the app.
2. When the OS permission prompt appears, tap Don't Allow.
3. Continue using the app.

Expected Result: App remains usable, handles the denied permission gracefully, and shows appropriate in-app messaging if notifications are required for a feature.

11. Login Persistence After App Restart

Preconditions: User has successfully logged in.

Steps:

1. Close the app completely.
2. Reopen the app.

Expected Result: User remains logged in if the session is still valid and is returned to the correct screen.

12. App Behavior on Poor Network Connection

Preconditions: The device's network can be throttled or switched from good to poor connectivity.

Steps:

1. Open a data-heavy screen.
2. Reduce the network quality or switch to a weak mobile connection.
3. Retry the same action.

Expected Result: App shows loading and retry states correctly, avoids freezing, and communicates connection problems clearly.

13. Screen Rotation During Form Entry

Preconditions: User is entering data into a multi-field form.

Steps:

1. Fill several form fields.
2. Rotate the device from portrait to landscape or vice versa.

Expected Result: Entered data is preserved and the layout remains usable after orientation change.

14. Deep Link Opens Correct Screen

Preconditions: Valid app deep link is available.

Steps:

1. Open the deep link from an email, browser, or messaging app.
2. If prompted, open it in the app.

Expected Result: App opens directly to the intended screen or resource, with authentication handled correctly if login is required.

6 API Test Case Examples

API testing is where many teams are either very disciplined or very vague. Good API test cases define request details, expected status codes, response structure, and side effects.

15. Successful GET Request Returns 200

Preconditions: Valid endpoint exists and authentication token is available if required.

Steps:

1. Send a GET request to the target endpoint with valid headers.

Expected Result: API returns HTTP 200 and the response body matches the documented schema.

16. POST Request Creates Resource

Preconditions: Valid payload is prepared.

Steps:

1. Send a POST request with all required fields.
2. Capture the returned resource identifier.
3. Retrieve the created resource with a follow-up GET request.

Expected Result: API returns HTTP 201 Created, stores the new resource correctly, and the resource is retrievable afterward.

17. Missing Required Field Returns Validation Error

Preconditions: Endpoint enforces required request fields.

Steps:

1. Send a POST or PUT request with one mandatory field omitted.

Expected Result: API rejects the request with the correct status code and returns a meaningful validation message identifying the missing field.

18. Unauthorized Request Is Rejected

Preconditions: Endpoint requires authentication.

Steps:

1. Send a request without an auth token or with an invalid token.

Expected Result: API returns HTTP 401 or 403 as designed, and no protected data is exposed.

19. Rate Limit Enforcement

Preconditions: Endpoint has documented rate limits.

Steps:

1. Send repeated requests that exceed the configured threshold within the time window.

Expected Result: API returns HTTP 429 Too Many Requests and, ideally, returns retry information in headers or response body.

20. Idempotent Retry Does Not Create Duplicate Data

Preconditions: Endpoint supports idempotency key or documented retry-safe behavior.

Steps:

1. Send a create request with a valid idempotency key.
2. Retry the same request using the same key.

Expected Result: Only one resource is created and the repeated request does not produce duplicates.

Reusable Test Case Template

If you want your team to create examples consistently, use a standard template like this:

Teams using a dedicated test management platform can turn this template into a reusable custom test case format, making it much faster to create high-quality cases at scale. If you want to speed up authoring even further, AI-generated test cases can produce the first draft from a user story or requirement in seconds.

Common Mistakes When Writing Test Cases

• Too much detail in one case. If a case validates login, checkout, email delivery, and reporting all at once, it is too broad.
• Missing preconditions. Testers should not have to guess account state, permissions, or environment setup.
• Weak expected results. "Should work" is not a valid expected result.
• No negative coverage. Teams often over-document happy paths and under-document error handling.
• No maintenance workflow. Examples become stale quickly if nobody owns them.

If your current library feels messy, the fix is not to stop writing cases. The fix is to introduce structure, review, and tooling. Our test management tools comparison can help if you are deciding what to use beyond spreadsheets.

How to Organize These Examples in a Real QA Workflow

The best way to use example test cases is not to keep them in a document forever. Move them into your working QA system and organize them by product area, platform, and release value.

• Group by module: Authentication, Checkout, User Settings, Notifications, Reporting, API.
• Tag by platform: web, mobile, api.
• Tag by execution type: smoke, regression, sanity, negative.
• Assign priorities: run critical flows first for every release.
• Review after feature changes: every product update should trigger test case review.

This is where a platform like QA Sphere helps. Instead of rewriting similar cases over and over, you can create folders, reuse templates, launch test runs, and track results across the whole team.

Conclusion

Strong test case examples do two things: they save time for the person writing them, and they reduce ambiguity for the person executing them. That is true whether you are testing a web checkout flow, a mobile permission prompt, or an API rate limit.

If you are building a new QA library, start with these 20 examples and adapt them to your product. Then standardize the format, add priorities and tags, and keep everything in a system your team can actually maintain.

Want to create structured test cases faster? Try QA Sphere's AI test case generation to turn requirements into reusable test cases in seconds.