Test Case in Software Testing

A requirement says what the software must do. A test case proves whether it does. Every defect found in production traces back to a test case that was never written, never executed, or never updated.

This guide covers what a test case is and its key components. It explains the types of test cases and design techniques. It covers the full test case lifecycle and how to organize test cases for long-term management.

What Is a Test Case in Software Testing?

A test case in software testing is a defined set of inputs, steps, and expected results. Test cases validate a specific software behavior. A test case connects a requirement to a verifiable outcome.

The tester executes the steps and compares the actual result against the expected result. The test case is marked as passed or failed based on this comparison.

📋 ISTQB Definition: The ISTQB Glossary defines a test case as “a set of preconditions, inputs, actions, expected results and postconditions, developed based on test conditions.” IEEE 610.12 uses the term “test case specification.”

A test case is not the same as a test. A test is a single execution of a test case against a specific build. One test case produces multiple tests across builds and environments. A test case for login validation runs as a separate test in every regression cycle.

Test cases serve 3 functions in the software testing lifecycle:

• Validation: Proving that the software meets its requirements.
• Documentation: Recording what was tested, with what data, and what happened.
• Repeatability: Enabling consistent re-execution by any tester on any build.

Test cases sit at the core of structured testing. Without test cases, testing becomes ad-hoc exploration. With test cases, testing becomes traceable, measurable, and auditable.

Where test cases sit in the STLC:

Test cases are created during the test design phase. Requirements feed test conditions. Test conditions feed test cases. Test cases feed test execution. This traceability chain ensures that every requirement has validation coverage.

What Are the Key Components of a Test Case?

The key components of a test case are 10 fields. These fields are test case ID, description, preconditions, test steps, test data, expected result, actual result, status, priority, and severity. Each component serves a specific purpose.

The components below use a single login scenario to demonstrate each field.

Test Case ID: A unique identifier for traceability and reference. Format follows organizational convention: TC-LOGIN-001 or JIRA story number. The ID links the test case to its requirement in the traceability matrix.

Description: A one-sentence statement of what the test case validates. Example: “Verify that a registered user can log in with valid credentials.” The description answers “what behavior does this test prove?”

Preconditions: Conditions that must be true before execution starts. Example: “User account exists with email user@test.com and password Test@1234. User is on the login page.” Without preconditions, the tester cannot reproduce the starting state.

Test Steps: Sequential actions the tester performs. Each step is one discrete action:

1. Navigate to /login
2. Enter “user@test.com” in the email field
3. Enter “Test@1234” in the password field
4. Click the “Sign In” button

Test Data: Specific input values used during execution. Example: email = user@test.com, password = Test@1234. Test data must be exact. “Valid credentials” is not test data. “user@test.com / Test@1234” is test data.

Expected Result: The behavior that confirms the test case passes. Example: “User is redirected to the dashboard. Welcome message displays user’s name.” The expected result is derived from the requirement, not from the tester’s assumption.

Actual Result: The observed behavior recorded during execution. Example: “User redirected to dashboard. Welcome message displayed.” The actual result captures exactly what happened, not an interpretation.

Status: The execution outcome based on comparing actual result to expected result. Three values apply: Pass (actual matches expected), Fail (actual deviates), or Blocked (a defect prevents execution).

Priority: The execution order of the test case. P1 test cases run first in every cycle. P2 test cases run after P1 completes. P3 and P4 run when time permits. A login test case is P1. A footer link test case is P4.

Severity: The impact level when the test case fails. Four levels apply: Critical (system unusable), Major (feature broken), Minor (cosmetic defect with workaround), and Cosmetic (visual-only issue). A login failure is Critical. A tooltip typo is Cosmetic.

💡 Key Rule: Every component must contain specific data, not placeholders. “Valid data” is not a test step. “Enter user@test.com” is a test step.

For complete guidance on structuring these components into a reusable template, see the test case writing guide.

The 10 components above define the structure of every test case. The types below define the purpose each test case serves.

What Are the Types of Test Cases in Software Testing?

Eight types of test cases exist in software testing: functional, non-functional, positive, negative, boundary, integration, regression, and user acceptance. Each type validates a different aspect of the application. The type determines the design technique, the execution timing, and the tester profile.

Functional Test Cases

Functional test cases verify that a feature produces the correct output for a given input. Functional test cases are the largest category in any test suite. Every feature in the requirements document maps to one or more functional test cases.

Functional test cases cover web application workflows like registration, login, search, and checkout. Each test case validates one behavior. “User can register with valid data” is one test case. “User sees error with duplicate email” is a separate test case.

Brief examples:

• Verify that entering a valid email and password redirects to the dashboard.
• Verify that submitting the registration form with all required fields creates a new account.
• Verify that the search function returns relevant results for “running shoes”.

Non-Functional Test Cases

Non-functional test cases evaluate how the system behaves, not what features it delivers. Non-functional testing covers performance under load, security against attacks, and usability across user profiles.

Brief examples:

• Verify that the login page loads within 2 seconds under 1,000 concurrent users.
• Verify that SQL injection strings in the search field are rejected without exposing database errors.
• Verify that all form fields are accessible via keyboard navigation (WCAG 2.1 compliance).

Positive and Negative Test Cases

Positive test cases confirm that the system works correctly with valid input. Negative test cases confirm that the system handles invalid input gracefully. Every feature needs both.

Negative test cases catch more production defects than positive test cases. Users enter unexpected data. Attackers enter malicious data. Negative test cases validate both scenarios.

Boundary and Edge Case Test Cases

Boundary test cases test values at the exact edges of input ranges. Edge case test cases test unusual conditions that fall outside normal usage. Both target defects that standard functional test cases miss.

Brief examples:

• Age field accepts 18: PASS (at minimum boundary)
• Age field accepts 17: FAIL expected (below minimum boundary)
• Username field accepts 255 characters: PASS (at maximum)
• Username field accepts 256 characters: FAIL expected (above maximum)
• Date field handles Feb 29 in a leap year: PASS
• Date field rejects Feb 29 in a non-leap year: PASS

Integration Test Cases

Integration test cases validate data flow between connected modules. Integration test cases catch defects that unit tests and functional tests miss because they test the connections, not the components.

Brief examples for an e-commerce workflow:

• Verify that completing checkout reduces inventory count by the ordered quantity.
• Verify that a successful payment triggers an order confirmation email.
• Verify that API endpoints return correct order status after payment processing.

Regression Test Cases

Regression test cases confirm that existing features still work after code changes. A regression failure means a bug fix or new feature broke something that previously worked. Regression suites grow with every release.

Automated regression execution reduces re-execution time from weeks to hours. Manual regression for a suite with 500+ test cases is impractical at sprint-level release frequency.

Three regression selection strategies exist:

• Retest all: execute the full regression suite (thorough but slow)
• Priority-based: execute P1 and P2 test cases only (faster, accepts risk)
• Impact-based: execute test cases linked to changed modules (targeted, requires traceability)

Smoke and Sanity Test Cases

Smoke test cases verify that the critical features of a new build work at a basic level. Smoke testing answers one question: is this build stable enough to test further? Smoke suites cover web and mobile application test cases across install, launch, login, and core workflows.

Sanity test cases verify that a specific bug fix or feature change works as expected. Sanity testing is narrower than smoke testing. Smoke tests check breadth. Sanity tests check depth on a targeted change.

Brief examples:

• Smoke: Application launches, login page loads, user can log in, homepage renders.
• Sanity: Bug #4521 (cart total miscalculation) is fixed; cart now calculates correctly with 3+ items.

User Acceptance Test Cases

User acceptance test cases validate that the system meets business requirements from the end-user perspective. UAT test cases use business language, not technical language. Business analysts or end users write UAT test cases.

Brief examples:

• “As a customer, I can place an order and receive a confirmation email within 5 minutes.”
• “As an admin, I can export a sales report filtered by date range in CSV format.”

UAT test cases are the final validation gate before production deployment. A passed UAT suite signals stakeholder sign-off.

What Is the Difference Between a Test Case and a Test Scenario?

The difference between a test case and a test scenario is the level of detail. A test scenario describes what to test. A test case describes how to test it, with exact inputs, steps, and expected results.

One test scenario generates multiple test cases:

Test scenario: “Verify login functionality”

Derived test cases:

1. Valid login with registered credentials
2. Invalid login with wrong password
3. Login with empty email field
4. Account lockout after 5 failed attempts
5. Login with expired session token

The test scenario defines the scope. The test cases define the execution.

Test case types and test scenarios answer what to test. Test case design techniques answer how to generate those test cases systematically.

How Are Test Cases Designed?

Test cases are designed using 3 approaches: specification-based (black box), structure-based (white box), and experience-based. Each approach uses a different source of information to generate test cases. The ISTQB CTFL Syllabus classifies all three as formal test design categories.

Specification-Based Design (Black Box)

Specification-based design generates test cases from requirements without examining internal code. The 5 core techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and error guessing.

Each technique produces test cases from a different angle. Equivalence partitioning reduces test cases by grouping inputs. BVA targets edge values. Decision tables cover combinations. State transition maps workflows.

For worked examples of each technique with input-output tables, see the black box testing techniques guide.

Structure-Based Design (White Box)

Structure-based design generates test cases from internal code structure. Developers use white box design at the unit and integration testing levels.

Three coverage criteria drive white box test case design:

• Statement coverage: Every line of code executes at least once.
• Branch coverage: Every decision point (if/else, switch) takes both true and false paths.
• Path coverage: Every unique execution path through the code runs at least once.

Path coverage is the most thorough and the most expensive. Statement coverage is the minimum baseline. Branch coverage is the standard target for most projects.

Experience-Based Design

Experience-based design generates test cases from tester knowledge and defect patterns. This approach supplements formal techniques by targeting areas that specification and structure miss.

Two experience-based techniques apply:

• Error guessing: Testers predict likely defect locations based on past project patterns.
• Checklist-based testing: Testers execute against a predefined checklist of common scenarios.

Experience-based test cases catch edge cases that formal partitioning and boundary analysis overlook. A tester who has seen double-click submission bugs adds a concurrency test case that no specification-based technique generates.

What Is the Test Case Lifecycle?

The test case lifecycle is a 4-phase process: creation, review, execution, and maintenance. Each phase has a defined output. Skipping a phase creates gaps that surface as missed defects or stale test cases.

Where Does Test Case Creation Start?

Test case creation starts with requirements. Each requirement maps to one or more test conditions. Each test condition maps to one or more test cases. This traceability chain ensures that no requirement exists without test coverage.

A traceability matrix documents these links:

The matrix reveals gaps. A requirement with zero linked test cases has zero validation coverage.

For step-by-step guidance on writing test cases with format and template, see the test case writing guide.

How Are Test Cases Reviewed?

Test case review catches design errors before execution. Three review methods apply:

• Peer review: A fellow QA engineer reviews test cases for completeness and clarity.
• Walkthrough: The author presents test cases to the team for feedback.
• Inspection: A formal review with defined roles (moderator, reviewer, author).

Reviewers check 5 things:

• Every test case traces to a requirement.
• Preconditions are complete and reproducible.
• Test steps are unambiguous and sequential.
• Expected results are specific (not “works correctly”).
• Test data uses exact values, not placeholders.

How Are Test Cases Executed?

Test case execution runs the designed test cases against the application build. Manual execution involves a tester performing each step. Automated execution uses scripts to perform steps programmatically.

The execution decision follows a simple rule. Repetitive test cases with stable steps automate well. Test cases requiring judgment, visual verification, or exploratory branching stay manual.

Each execution records 3 outcomes:

• Pass: Actual result matches expected result.
• Fail: Actual result deviates; a defect report is logged.
• Blocked: A defect or environment issue prevents execution.

How Are Test Cases Maintained?

Test cases become stale when requirements change, features evolve, or environments update. Unmaintained test cases produce false passes and false fails. A false pass validates outdated behavior. A false fail triggers because the expected result no longer applies.

Four triggers require test case updates:

• A requirement changes after the original test case was written.
• A feature’s UI or workflow changes after a redesign.
• A defect fix alters the expected behavior.
• The test environment changes (new browser, new API version).

Test case maintenance runs as a recurring activity, not a one-time effort. Every sprint review includes a test case update check.

Individual test cases pass through this lifecycle independently. Test suites group these test cases for coordinated execution.

What Is a Test Suite in Software Testing?

A test suite in software testing is a collection of test cases grouped for a specific testing purpose. A test suite organizes test cases by feature, by testing type, or by execution priority. Executing a test suite runs all test cases within it in sequence.

Three common test suite types exist:

• Regression suite: All test cases for existing features, executed after every code change.
• Smoke suite: Critical-path test cases only, executed after every new build.
• Sanity suite: Targeted test cases for a specific fix or feature, executed after a patch.

A test suite is not a test plan. A test plan defines the strategy (what to test, how, with what resources). A test suite is a specific set of test cases ready for execution.

The relationship is hierarchical:

Test Plan → Test Suites → Test Cases → Test Steps

An e-commerce release test plan contains 4 suites. The smoke suite holds 10 test cases. The functional suite holds 200. The regression suite holds 500. The performance suite holds 30.

How Are Test Cases Organized and Managed?

Test cases are organized through folder structures, naming conventions, and traceability matrices, then managed through dedicated test management tools. Organization determines how quickly testers find, execute, and maintain test cases across releases.

Folder structure:

Test case repositories follow feature-based or module-based hierarchies:

• /Login/Functional/
• /Login/Security/
• /Checkout/Payment/
• /Checkout/Shipping/
• /API/Users/
• /API/Orders/

Naming conventions:

Consistent naming enables search and filtering.

A standard pattern: [Module]-[Type]-[Sequence].

Example: LOGIN-FUNC-001, CHECKOUT-NEG-003, API-INTG-012.

Test management tools:

💡 Key Guidance: Spreadsheets work for teams with fewer than 100 test cases. Beyond that threshold, traceability, version control, and reporting become unmanageable without a dedicated tool.

Metrics from test case management:

• Test case pass rate: (passed / total executed) x 100
• Defect density: defects found per module or feature
• Requirement coverage: percentage of requirements linked to at least one test case
• Test case growth rate: new test cases added per sprint
• Stale test case ratio: test cases not executed in the last 3 release cycles

Why Are Test Cases Important in Software Testing?

Test cases are important in software testing because they convert requirements into verifiable proof of software behavior. Without test cases, testing produces opinions. With test cases, testing produces evidence.

Five reasons test cases matter:

• Consistency: Two testers executing the same test case produce the same result. Ad-hoc testing produces different results from different testers. Test cases standardize validation.

• Compliance and audit trails: Regulated industries (healthcare, finance, medical devices) require documented evidence of testing. Test cases with execution history provide this evidence for HIPAA, FDA, SOX, and ISO audits.

• Knowledge transfer: New team members execute existing test cases on day one. Domain knowledge lives in the test suite, not in individual testers’ heads. Test cases survive team turnover.

• Regression safety: Every code change risks breaking existing features. The regression test suite catches breaks. Without regression test cases, teams discover regression defects in production.

• Measurement: Test case metrics (pass rate, coverage, defect density) provide objective quality data. Stakeholders make release decisions based on these metrics. “We feel the software is ready” is not a release criterion. “98% pass rate across 500 test cases with zero P1 defects” is.

What Are Common Mistakes in Test Case Design?

The 6 most common mistakes in test case design are listed below. These mistakes are missing traceability, combined validations, vague expected results, missing negative cases, stale test cases, and assumption-based test data.

• Missing traceability: Test cases without links to requirements create blind spots. No traceability matrix means no way to confirm that every requirement has coverage.

• Combined validations: A test case that checks login, navigation, and search in one sequence tests 3 features. One failure makes it unclear which feature broke. One test case validates one behavior.

• Vague expected results: “Application works correctly” is not an expected result. “User is redirected to /dashboard and welcome banner displays ‘Hello, John'” is an expected result. Vague results produce inconsistent pass/fail decisions.

• Missing negative cases: Testing only the happy path misses the defects users encounter most. Every valid test case needs a corresponding invalid test case. Login works? Test what happens when login fails.

• Stale test cases: Requirements change. Features change. Test cases that validate last quarter’s behavior produce false confidence. Regular maintenance is a requirement, not an option.

• Assumption-based test data: “Enter valid email” is an assumption. “Enter user@test.com” is test data. Assumptions create inconsistency across testers and environments.

Frequently Asked Questions

What Is the Difference Between a Test Case and a Test Script?

A test case is a documented specification of inputs, steps, and expected results. A test script is the coded implementation of a test case in an automation framework. The test case defines what to validate. The test script defines how to automate that validation. One test case maps to one test script. Selenium, Cypress, and Appium execute test scripts, not test cases directly.

Who Writes Test Cases in a Software Team?

QA engineers write the majority of test cases for functional, regression, and integration testing. Developers write unit test cases for code-level validation. Business analysts and product owners write user acceptance test cases in business language. Security specialists write penetration test cases. The role depends on the testing type and the organizational structure.

What Is a Dependent Test Case?

A dependent test case requires the output of a preceding test case as its input. Example: TC-002 (place an order) depends on TC-001 (user login). TC-002 cannot execute without TC-001 passing first. Dependencies create execution order constraints. Minimizing dependencies improves test suite flexibility and parallel execution capability.

How Many Test Cases Are Enough?

The number depends on requirement coverage, not a fixed count. A traceability matrix determines completeness. Every requirement links to at least one test case. Every test case applies at least one design technique (EP, BVA, decision table). Coverage is measured by requirement coverage percentage and defect detection rate, not by test case volume. 500 well-designed test cases outperform 2,000 redundant ones.