Summary of "How To Write A Test Case? | Test Case In Software Testing | Software Testing Tutorial | Edureka"
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:
-
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)
-
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
-
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
-
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.
-
Select tooling
- Choose Excel or a spreadsheet for simple/manual workflows, or a test management tool (TestLink, TestRail) for more scale.
-
Write test cases using a template that includes the standard fields listed above.
-
Write a concise test case statement — a one-line summary of what you verify, the conditions, inputs, and expected outcome.
-
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)
Category
Educational
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...