Test Case Examples: 30+ Real-World Examples for Web & API Testing

Writing test cases from a blank page is slow. You know the feature, you know the expected behavior, but translating that knowledge into structured, executable test cases takes time — especially when you are trying to cover positive flows, negative scenarios, edge cases, and boundary conditions.

This guide provides 30+ concrete test case examples you can use as starting points. Each example includes a title, numbered steps, and expected results in a format you can copy directly into your test case management tool or spreadsheet. The examples are organized by category: login and authentication, registration, search, cart and checkout, API endpoints, and form validation.

These are not theoretical samples. They are based on patterns that catch real bugs in production applications — the kind of scenarios that slip through when QA teams only test the happy path.

Login and Authentication Test Cases

Authentication is the front door of every application. Bugs here affect every user, and security issues in login flows have outsized impact. These examples cover the scenarios that matter most.

TC-AUTH-001: Successful login with valid credentials

Steps:

1. Navigate to the login page
2. Enter a valid registered email address in the email field
3. Enter the correct password in the password field
4. Click the "Sign In" button

Expected Result: User is redirected to the dashboard. The navigation bar displays the user's name or email. A valid session token is created and stored.

TC-AUTH-002: Login fails with incorrect password

Steps:

1. Navigate to the login page
2. Enter a valid registered email address
3. Enter an incorrect password
4. Click "Sign In"

Expected Result: An error message displays: "Invalid email or password." The user remains on the login page. The password field is cleared. No session token is created.

TC-AUTH-003: Login fails with unregistered email

Steps:

1. Navigate to the login page
2. Enter an email address that is not registered in the system
3. Enter any password
4. Click "Sign In"

Expected Result: The same generic error message appears: "Invalid email or password." The message must not reveal whether the email exists in the system (security best practice).

TC-AUTH-004: Login with empty fields

Steps:

1. Navigate to the login page
2. Leave both email and password fields empty
3. Click "Sign In"

Expected Result: Validation messages appear for both fields: "Email is required" and "Password is required." No API request is sent to the server.

TC-AUTH-005: Account lockout after repeated failed attempts

Steps:

1. Navigate to the login page
2. Enter a valid registered email
3. Enter an incorrect password and click "Sign In"
4. Repeat step 3 four more times (5 total failed attempts)
5. On the 6th attempt, enter the correct password and click "Sign In"

Expected Result: After the 5th failed attempt, the account is temporarily locked. A message displays: "Account locked. Please try again in 15 minutes." Even with the correct password, login is rejected during the lockout period.

TC-AUTH-006: Remember me functionality

Steps:

1. Navigate to the login page
2. Enter valid credentials
3. Check the "Remember me" checkbox
4. Click "Sign In"
5. Close the browser completely
6. Reopen the browser and navigate to the application URL

Expected Result: The user is automatically logged in without being prompted for credentials. The session persists based on the "Remember me" token duration.

TC-AUTH-007: Password visibility toggle

Steps:

1. Navigate to the login page
2. Enter a password in the password field
3. Click the eye/visibility icon next to the password field
4. Click the icon again to hide the password

Expected Result: When toggled on, the password displays as plain text. When toggled off, the password is masked with dots or asterisks. The actual password value does not change.

Registration Test Cases

Registration flows involve data validation, uniqueness checks, and often email verification. These test cases cover the common failure points.

TC-REG-001: Successful registration with all required fields

Steps:

1. Navigate to the registration page
2. Enter a valid full name
3. Enter a valid, unused email address
4. Enter a password that meets all requirements (minimum 8 characters, includes uppercase, lowercase, number, and special character)
5. Confirm the password by entering it again
6. Accept the terms and conditions
7. Click "Create Account"

Expected Result: A success message appears. A verification email is sent to the provided address. The user account is created with a "pending verification" status in the database.

TC-REG-002: Registration fails with an already-registered email

Steps:

1. Navigate to the registration page
2. Enter a full name
3. Enter an email address that is already registered
4. Complete all other required fields
5. Click "Create Account"

Expected Result: An error message displays: "An account with this email already exists." The form does not clear other fields so the user can correct only the email.

TC-REG-003: Password does not meet minimum requirements

Steps:

1. Navigate to the registration page
2. Fill in all required fields
3. Enter a password that is only 5 characters long
4. Click "Create Account"

Expected Result: A validation error appears near the password field listing the unmet requirements. The form is not submitted. Password requirement checklist (if present) shows which rules are not met.

TC-REG-004: Password confirmation mismatch

Steps:

1. Navigate to the registration page
2. Enter a valid password in the password field
3. Enter a different value in the "Confirm Password" field
4. Click "Create Account"

Expected Result: A validation error appears: "Passwords do not match." The form is not submitted. Both password fields retain their values so the user can see and correct the mismatch.

TC-REG-005: Registration with special characters in name

Steps:

1. Navigate to the registration page
2. Enter a name with special characters: "O'Brien-Smith Jr."
3. Complete all other required fields with valid data
4. Click "Create Account"

Expected Result: Registration succeeds. The name is stored and displayed correctly with apostrophes, hyphens, and periods preserved. No SQL injection or XSS vulnerabilities are triggered.

Search Functionality Test Cases

Search is deceptively complex. Users expect instant, relevant results across various input patterns. These test cases cover the scenarios where search implementations commonly fail.

TC-SEARCH-001: Basic keyword search returns relevant results

Steps:

1. Navigate to the search page or use the global search bar
2. Enter a keyword that matches known items in the system (e.g., "wireless mouse")
3. Press Enter or click the search icon

Expected Result: Search results display items containing "wireless mouse" in the title or description. Results are sorted by relevance. The total result count is displayed. The search term is preserved in the search bar.

TC-SEARCH-002: Search with no matching results

Steps:

1. Enter a search query that has no matches in the system (e.g., "xyznonexistent12345")
2. Press Enter

Expected Result: A friendly "No results found" message appears with suggestions such as "Try different keywords" or "Check your spelling." The page does not display an error or crash. Recent or popular items may be suggested.

TC-SEARCH-003: Search with special characters

Steps:

1. Enter a search query containing special characters: <script>alert('xss')</script>
2. Press Enter

Expected Result: The search executes safely without triggering any JavaScript. Special characters are escaped or stripped. Results (if any) are displayed normally. No XSS vulnerability is present.

TC-SEARCH-004: Search with leading and trailing whitespace

Steps:

1. Enter " wireless mouse " (with extra spaces before and after)
2. Press Enter

Expected Result: Whitespace is trimmed. Results are identical to searching for "wireless mouse" without extra spaces. The trimmed query is shown in the search bar.

TC-SEARCH-005: Search results pagination

Steps:

1. Enter a broad search query that returns more than one page of results
2. Verify the first page of results displays
3. Click "Next" or page 2
4. Verify the second page loads
5. Click "Previous" or page 1

Expected Result: Each page displays the correct number of results (e.g., 10 or 20 per page). Navigation between pages works. The total result count remains consistent. No duplicate results appear across pages.

TC-SEARCH-006: Empty search submission

Steps:

1. Leave the search field empty
2. Click the search button or press Enter

Expected Result: Either the search is not executed (button is disabled or no API call is made), or a helpful message displays prompting the user to enter a search term. The application does not crash or return all records.

Cart and Checkout Test Cases

Cart and checkout flows involve money. Bugs here directly impact revenue, customer trust, and sometimes legal compliance. These test cases focus on the calculations and edge cases that cause real financial errors.

TC-CART-001: Add a single item to cart

Steps:

1. Navigate to a product detail page
2. Click "Add to Cart"
3. Navigate to the cart page

Expected Result: The cart displays the product with correct name, price, and quantity of 1. The cart icon in the navigation updates to show "1" item. The cart subtotal matches the product price.

TC-CART-002: Update item quantity in cart

Steps:

1. Add a product priced at $29.99 to the cart
2. Navigate to the cart page
3. Change the quantity from 1 to 3
4. Wait for the cart to update

Expected Result: The line item total updates to $89.97 (3 x $29.99). The cart subtotal reflects the new total. A brief confirmation such as "Cart updated" may appear.

TC-CART-003: Remove an item from cart

Steps:

1. Add two different products to the cart
2. Navigate to the cart page
3. Click the "Remove" button next to the first product
4. Confirm removal if prompted

Expected Result: The first product is removed. The second product remains in the cart. The cart subtotal updates to reflect only the remaining item. The cart item count in the navigation updates.

TC-CART-004: Apply a valid discount code

Steps:

1. Add items to the cart totaling at least $50
2. Navigate to checkout
3. Enter a valid discount code "SAVE10" (10% off)
4. Click "Apply"

Expected Result: A discount line item appears showing the calculated discount amount. The order total decreases by the correct percentage. The discount code is displayed with an option to remove it.

TC-CART-005: Apply an expired discount code

Steps:

1. Add items to the cart
2. Navigate to checkout
3. Enter an expired discount code
4. Click "Apply"

Expected Result: An error message displays: "This discount code has expired." No discount is applied. The order total remains unchanged.

TC-CART-006: Checkout with empty cart

Steps:

1. Ensure the cart is empty (remove all items if necessary)
2. Navigate to the checkout page directly via URL

Expected Result: The user is redirected to the cart page with a message: "Your cart is empty." The checkout flow does not proceed. A link to continue shopping is displayed.

TC-CART-007: Price consistency from product page to checkout

Steps:

1. Note the price of a product on the product listing page
2. Click into the product detail page and verify the price matches
3. Add to cart and navigate to the cart page
4. Proceed to checkout

Expected Result: The product price is identical at every step: listing page, detail page, cart, and checkout. No rounding errors or currency formatting differences exist between views.

API Test Cases

API test cases catch backend logic issues that UI tests miss. They execute faster, provide precise error information, and are essential for verifying security, data validation, and business rules.

TC-API-001: GET request returns list of resources

Steps:

1. Send a GET request to /api/v1/projects with a valid authentication token
2. Record the response status code and body

Expected Result: HTTP 200 OK. Response body contains an array of project objects. Each object includes at minimum: id, name, and createdAt fields. The response includes pagination metadata (total count, page size, current page).

TC-API-002: POST request creates a new resource

Steps:

1. Send a POST request to /api/v1/projects with a valid auth token
2. Include a JSON body: {"name": "Test Project", "description": "API test project"}
3. Record the response

Expected Result: HTTP 201 Created. Response body contains the created project with a generated ID, the submitted name and description, and a createdAt timestamp. The project is retrievable via a subsequent GET request using the returned ID.

TC-API-003: POST request with missing required fields

Steps:

1. Send a POST request to /api/v1/projects with a valid auth token
2. Include a JSON body with only: {"description": "Missing required name field"}

Expected Result: HTTP 400 Bad Request. Response body includes a clear error message identifying the missing field: {"error": "validation_error", "details": [{"field": "name", "message": "Name is required"}]}. No resource is created in the database.

TC-API-004: Request without authentication

Steps:

1. Send a GET request to /api/v1/projects without any authentication header

Expected Result: HTTP 401 Unauthorized. Response body includes: {"error": "unauthorized", "message": "Authentication required"}. No data is returned in the response.

TC-API-005: Request with insufficient permissions

Steps:

1. Send a DELETE request to /api/v1/projects/{id} using an auth token for a user with read-only permissions

Expected Result: HTTP 403 Forbidden. Response body includes: {"error": "forbidden", "message": "You do not have permission to perform this action"}. The resource is not deleted.

TC-API-006: GET request for a non-existent resource

Steps:

1. Send a GET request to /api/v1/projects/nonexistent-id-12345 with a valid auth token

Expected Result: HTTP 404 Not Found. Response body includes: {"error": "not_found", "message": "Project not found"}. The response does not expose internal database errors or stack traces.

TC-API-007: Rate limiting enforcement

Steps:

1. Send 100 rapid GET requests to /api/v1/projects within 60 seconds using a valid auth token
2. Observe the response to the request that exceeds the rate limit

Expected Result: Requests within the limit return HTTP 200. The request exceeding the limit returns HTTP 429 Too Many Requests. The response includes a Retry-After header indicating when the client can retry. Subsequent requests after the cooldown period succeed normally.

TC-API-008: PUT request updates existing resource

Steps:

1. Send a PUT request to /api/v1/projects/{id} with valid auth token
2. Include updated data: {"name": "Updated Project Name"}
3. Send a GET request for the same resource to verify

Expected Result: The PUT request returns HTTP 200 with the updated resource. The name field reflects the new value. The updatedAt timestamp is updated. Other fields that were not included in the request remain unchanged.

Form Validation Test Cases

Forms are where user input meets your application's expectations. Every form field is a potential source of bugs — from basic presence validation to complex format checking and cross-field dependencies.

TC-FORM-001: Required field validation on empty submission

Steps:

1. Navigate to a form with required fields (e.g., contact form with Name, Email, Message)
2. Leave all fields empty
3. Click "Submit"

Expected Result: Validation messages appear for each required field. The form is not submitted. Each message clearly indicates which field is required. Focus moves to the first invalid field.

TC-FORM-002: Email format validation

Steps:

1. Enter "notanemail" in the email field
2. Tab out of the field or click Submit
3. Then enter "user@" and repeat
4. Then enter "user@domain" and repeat
5. Finally enter "user@domain.com" and repeat

Expected Result: The first three entries show a validation error: "Please enter a valid email address." The last entry (user@domain.com) passes validation. Validation triggers on blur or submit, not on every keystroke.

TC-FORM-003: Maximum character limit

Steps:

1. Navigate to a form with a text field that has a 500-character limit
2. Enter exactly 500 characters
3. Attempt to type one more character

Expected Result: The first 500 characters are accepted. The 501st character is either prevented from being entered or triggers a validation message: "Maximum 500 characters allowed." A character counter (if present) accurately reflects the current count.

TC-FORM-004: Phone number format validation

Steps:

1. Enter "abc123" in a phone number field
2. Enter "123" (too short)
3. Enter a valid 10-digit phone number: "5551234567"
4. Enter a valid formatted number: "(555) 123-4567"

Expected Result: Non-numeric input is rejected or stripped. Too-short input triggers a validation error. Both valid formats (with and without formatting characters) are accepted. The stored value is normalized to a consistent format.

TC-FORM-005: Date picker with invalid date range

Steps:

1. Navigate to a form with start and end date fields
2. Set the end date to a date before the start date
3. Attempt to submit

Expected Result: A validation error appears: "End date must be after start date." The form is not submitted. Past dates may or may not be allowed depending on the context (booking forms should prevent past dates; reporting forms may allow them).

TC-FORM-006: Form submission with network interruption

Steps:

1. Fill in all form fields with valid data
2. Disable network connectivity (airplane mode or disconnect)
3. Click "Submit"
4. Restore network connectivity

Expected Result: A clear error message appears: "Unable to submit. Please check your internet connection and try again." Form data is preserved so the user does not have to re-enter it. Upon reconnection, the user can successfully resubmit without issues.

TC-FORM-007: Cross-site scripting (XSS) prevention in form fields

Steps:

1. Enter <img src=x onerror=alert('XSS')> in a text input field
2. Submit the form
3. View the submitted data on a display page

Expected Result: The HTML tags are escaped or stripped. No JavaScript executes when the data is displayed. The stored data shows the literal text, not rendered HTML. The application is not vulnerable to stored XSS attacks.

Organizing Your Test Cases for Maximum Impact

Having 30+ test cases is only useful if you can find, execute, and maintain them efficiently. Here are practical strategies for keeping your test suite manageable.

Group by module, not by type. Instead of having separate folders for "positive tests" and "negative tests," organize by feature area: Authentication, Search, Checkout, API. Within each folder, include both positive and negative cases. This way, when you need to test login before a release, every relevant test case is in one place.

Tag for cross-cutting concerns. Apply tags like "smoke" (quick sanity checks), "regression" (full test suite), and "critical" (must-pass before any release) to create filtered views across modules. A smoke test run might pull 2-3 test cases from each module — tags make this selection instant.

Prioritize ruthlessly. Not every test case deserves equal attention. Mark authentication and payment tests as Critical. Mark search pagination tests as Medium. When release pressure forces you to cut your test run short, priority tells you what to skip without guessing.

A test case management tool handles all of this automatically — folders, tags, priority filtering, and execution tracking. If you are still using spreadsheets and your test suite has grown past the examples in this guide, the transition will save you hours every sprint.

Generating Test Cases Faster

Writing 30+ test cases manually for every feature is time-consuming. Modern teams use an AI test case generator to create initial drafts from feature descriptions or user stories. The AI generates structured test cases covering positive, negative, and boundary scenarios — then a human tester reviews, adjusts, and approves them.

This approach cuts test case creation time by 60-70% while actually improving coverage, because the AI systematically generates negative and edge cases that human testers often skip under time pressure.

Wrapping Up

Good test cases share three qualities: they are specific enough that any team member can execute them, they cover negative and edge cases alongside happy paths, and they are organized so you can find and run them efficiently.

Use the examples in this guide as templates for your own application. Adapt the steps and expected results to match your product's specifics. And as your test suite grows, invest in organization and tooling that keeps the suite maintainable — because a test case nobody can find is a test case that never gets executed.