Video summary

How To Write A Test Case? | Test Case In Software Testing | Software Testing Tutorial | Edureka

Main summary

Key takeaways

Educational

How to Write a Test Case — Summary

Main ideas and lessons

Software testing aims to find bugs before release to improve quality and reduce cost and time. Good documentation (requirements and test artifacts) is critical: it provides traceability, a single source of truth, and legal/business protection (for example, resolving disputes about compatibility or scope).

Three levels of test documentation (from most to least detailed):

  • Test script — line-by-line steps and data (very detailed; may include expected results per step).
  • Test case — describes what to test (the expected feature/behavior) without prescribing exact step-by-step actions; allows tester flexibility.
  • Test scenario — high-level user activity or condition to test; minimal detail and maximum tester flexibility.

Primary goal of a test case:

Validate that features work as expected under specified conditions, improve coverage, enable reusability, reduce maintenance/support cost, and ensure the product meets end-user requirements.

Test case structure — typical fields

A standard test case typically includes:

  • Test case ID or title — unique identifier.
  • Description — brief, high-level goal; may include environment, data, preconditions, assumptions.
  • Preconditions — what must be true before the test runs (e.g., user logged in).
  • Test steps — ordered, clear, concise, granular actions to execute the test.
  • Test data — positive and negative datasets chosen for sufficient coverage.
  • Expected result — what should happen if the system is correct.
  • Actual result — what happened during execution.
  • Status — pass/fail.
  • Comments — screenshots, developer notes, reproduction hints.

Optional/additional fields:

  • Priority, test type (positive/negative), bug ID, reviewer, creation/execution dates, etc.

Test case design techniques

Three major categories:

  1. Specification-based (Black-box)

    • Derive tests from requirements/specs.
    • Common techniques:
      • Boundary Value Analysis (BVA)
      • Equivalence Partitioning (EP)
      • Decision Table Testing
      • State Transition Testing (use state-transition diagrams)
      • Use Case Testing (business scenarios / end-user flows)

  2. Structure-based (White-box)

    • Derive tests from the internal code structure.
    • Common techniques:
      • Statement coverage
      • Decision / Branch coverage
      • Condition coverage
      • Multiple condition testing
      • Path coverage

  3. Experience-based

    • Rely on tester skill and product knowledge.
    • Common approaches:
      • Error guessing
      • Exploratory testing (design and execution happen concurrently)

Characteristics of a good test case

A good test case is:

  • Accurate — has a clear purpose.
  • Traceable — mapped to requirements.
  • Repeatable — can be run multiple times with the same result.
  • Reusable — can be used in future tests.
  • Independent — can run in any order without dependencies.

Guidelines and best practices

  • Prioritize tests by risk and release timeline; focus on high-risk features first.
  • Apply the 80/20 rule: ~20% of tests should cover ~80% of critical behavior (useful for smoke/sanity suites).
  • Start with “good enough” test cases and iterate; revise as needed.
  • Keep tests concise and executable in a reasonable time (recommended 45–90 minutes per tester).
  • Make test cases executable by others — clarity and granularity are important.
  • Classify tests by business scenario and functionality for better organization and selection.
  • Think like the customer — design tests to validate user expectations.
  • Use a test case management tool (TestLink, TestRail, spreadsheets/Excel, etc.) and learn it well.
  • Monitor the test repository to avoid duplicates and remove irrelevant/obsolete tests.

Common mistakes and how to avoid them

  • Composite steps: combining multiple distinct actions into one step. Avoid by breaking steps into small, granular actions with explicit expected outcomes so failures are specific.
  • Multiple conditions in one test: grouping several logical conditions/variations into a single test makes failure causes unclear. Avoid by making modular tests — one condition per test where feasible.
  • Rushing test-writing: take sufficient time and include reviews.

Step-by-step process to create test cases

  1. Prepare

    • Check for existing equivalent test cases; update if appropriate.
    • Understand the characteristics of a good test case.
    • Consider likely user scenarios and think from the customer’s perspective.
    • Allocate sufficient time for writing and review.

  2. Select tooling

    • Choose Excel or a spreadsheet for simple/manual workflows, or a test management tool (TestLink, TestRail) for more scale.

  3. Write test cases using a template that includes the standard fields listed above.

  4. Write a concise test case statement — a one-line summary of what you verify, the conditions, inputs, and expected outcome.

  5. Review test cases

    • Ensure steps and expected results align, remove duplicates, and ensure traceability to requirements.

Examples (condensed)

Login functionality — valid credentials

  • Preconditions: (none) or valid credentials available.
  • Steps: navigate to login page → enter username → enter password → click login.
  • Test data: valid username and password.
  • Expected result: login dialog visible, credentials accepted, user logged in.
  • Actual result / Status: recorded per step; overall Pass if all expected == actual.

Login functionality — invalid credentials

  • Steps same as above.
  • Test data: invalid username and/or password.
  • Expected result: navigation & data entry succeed; login fails and an appropriate error is shown.
  • Status: Pass if actual matches expected (i.e., the system correctly rejects login).

Upload photo — logged-in user

  • Preconditions: user logged in.
  • Steps: click upload photo link → select photo → click upload.
  • Expected: upload dialog opens, photo selected, photo uploaded successfully.

Upload photo — not logged-in user

  • Preconditions: user not logged in.
  • Expected: upload action should be prevented and an appropriate message shown (test should fail early or show appropriate error).

Practical tips

  • Use screenshots and comments when steps are complex.
  • Include both positive and negative tests.
  • Keep a test library organized by module/feature.
  • Continuously review and maintain test cases as the product changes.

Sources / Speakers

  • Presenter: Amer China (Edureka)
  • Organization / channel: Edureka (YouTube)

Original video