Writing effective QA test cases is a skill. Learn the structure, best practices, and common mistakes that separate useful test cases from those that miss real bugs.
What Is a QA Test Case?
A test case is a documented set of conditions, inputs, and expected results used to verify a specific function or behavior of an application. Good test cases can be executed by any tester — not just the person who wrote them — and produce consistent, reproducible results.
The Anatomy of a Good Test Case
Every test case should contain:
| Field | Description | Example |
|---|---|---|
| Test Case ID | Unique identifier | TC-LOGIN-001 |
| Title | One-line description | Login with valid email and password |
| Preconditions | State before execution | User is on login screen, not logged in |
| Test Steps | Numbered actions | 1. Enter valid email 2. Enter valid password 3. Tap Login |
| Expected Result | What should happen | User is redirected to dashboard |
| Actual Result | What did happen | (filled in during execution) |
| Status | Pass / Fail / Blocked | (filled in during execution) |
| Priority | High / Medium / Low | High |
| Test Data | Specific inputs to use | email: test@example.com, pwd: Test1234! |
Types of Test Cases to Write
Positive Test Cases
Verify that the system works correctly with valid inputs.
*Example*: Login with a correct email and password → user reaches dashboard.
Negative Test Cases
Verify that the system handles invalid inputs gracefully.
*Example*: Login with wrong password → user sees "Invalid credentials" error, not a crash.
Boundary Test Cases
Test the edges of acceptable input ranges.
*Example*: Username field with exactly 50 characters (max) → accepted. 51 characters → rejected with clear error.
Edge Case Test Cases
Test unusual but valid scenarios.
*Example*: Complete a purchase with the exact account balance required, leaving $0.00 remaining.
How to Structure Your Test Suite
Organize test cases by feature area (module), then by scenario type — for example:
Login Module
TC-LOGIN-001: Login with valid credentials (Positive)
TC-LOGIN-002: Login with invalid password (Negative)
TC-LOGIN-003: Login with empty email field (Negative)
TC-LOGIN-004: Login with non-registered email (Negative)
TC-LOGIN-005: Login with maximum length email (Boundary)
TC-LOGIN-006: Login after session timeout (Edge Case)
Common Test Case Mistakes
Vague steps: "Go to settings and change email" is not a test step. "Tap the profile icon → tap Settings → tap Email → enter newemail@example.com → tap Save" is.
Missing preconditions: If your test requires a specific user state (logged in, cart has 3 items, payment method saved), state it explicitly.
No test data: Never write "enter a valid email." Specify the exact email to use. This makes tests reproducible by anyone.
Testing only the happy path: Most bugs hide in edge cases and error states. Write at least one negative test for every positive test.
Too many steps in one case: If a test case has 20+ steps, it's probably testing multiple things. Split it.
Test Case Review Checklist
Before finalizing a test case, confirm:
Working with QA Services
When using a managed QA service like HappyTestr, you can either provide your own test cases or let the testing team write them based on your app's functionality. Professional testers bring structured test case libraries for common flows (auth, payments, onboarding) and supplement with exploratory testing for app-specific features.