Coursify

SOFTWARE ENGINEERING

Software Testing Process and Test Case Design

Introduces the overall software testing process, including planning, test design, execution, defect reporting, and evaluation, with emphasis on constructing effective and systematic test cases.

Learning Goals

  • Describe the major phases of the software testing process, including planning, design, execution, defect tracking, and closure.
  • Identify the inputs, outputs, and responsibilities associated with each stage of the testing lifecycle.
  • Design test cases from software requirements using clear preconditions, test steps, expected results, and postconditions.
  • Distinguish between effective and ineffective test cases based on coverage, traceability, and fault-detection capability.
  • Prepare a basic test suite that organizes multiple test cases for a given functional requirement.

The Software Testing Lifecycle represents a systematic approach to verifying and validating software. Far from being a single, isolated phase executed at the end of development, modern software engineering treats testing as a continuous, multi-stage lifecycle that runs in parallel with the Software Development Lifecycle (SDLC).

To build high-quality systems, organizations must distinguish between two core aspects of quality assurance:

  • Verification focuses on static evaluation (e.g., reviews, walkthroughs, and inspections). It answers the fundamental question: "Are we building the product right?"
  • Validation involves dynamic execution of the software to verify its behavior against business goals. It answers the question: "Are we building the right product?"

The relationship between development levels and corresponding test stages is elegantly captured by the V-Model, which represents a symmetric progression from requirements down to coding, and back up through verification and validation levels:

V-Model Diagram Showing Verification and Validation Phases

During the execution of these phases, defects are systematically identified, logged, and tracked through a structured workflow. The typical progression of a bug is represented below:

Footnotes

  1. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

  2. Software Testing: Principles and Practice - Comprehensive guide on software testing principles and verification/validation processes. ↩ ↩2 ↩3

How to Write a Test Case: A Complete Software Testing Tutorial

Phases of the Software Testing Lifecycle (STLC)

Requirement Analysis

Phase 1

The quality assurance team reviews software requirements documents to identify testable features and clarify ambiguities. Inputs: Software Requirement Specification (SRS), User Stories. Outputs: Requirement Traceability Matrix (RTM) outline, list of clarification questions. Responsibilities: QA Engineers collaborate with Business Analysts and Product Owners to ensure requirements are clear and testable."

Footnotes

  1. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

Test Planning

Phase 2

The testing strategy, timeline, scope, resource allocation, tool selection, and environments are formally defined. Inputs: SRS, RTM shell, Project Schedule. Outputs: Test Plan document, Test Strategy document, Effort Estimation metrics. Responsibilities: QA Lead / Test Manager defines the strategic direction, risk mitigation steps, and signs off on planning."

Footnotes

  1. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

Test Case Design & Development

Phase 3

Testing teams develop detailed test cases, prepare mock test data, and refine tracing links using structured techniques like Boundary Value Analysis and Equivalence Partitioning. Inputs: Approved Test Plan, SRS, RTM. Outputs: Detailed Test Cases, Test Data, completed RTM. Responsibilities: Test Engineers draft the test suites; QA Lead reviews and baselines them."

Footnotes

  1. Test Case Design Techniques - Best practices in test case template design and black-box testing methodologies from Qase. ↩ ↩2

  2. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

Test Environment Setup

Phase 4

Hardware, software, database configurations, and network environments are prepared to replicate production conditions. Inputs: Test Plan, Environment Configuration Requests. Outputs: Fully functional Test Environment, verified environment smoke test results. Responsibilities: DevOps and System Administrators configure the infrastructure, while QA Engineers perform smoke testing."

Footnotes

  1. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

Test Execution & Defect Tracking

Phase 5

Testers execute the prepared test cases within the test environment, record actual outcomes, and log any discrepancies as bugs in tracking software. Inputs: Test Cases, Test Data, Configured Environment. Outputs: Test Execution Report, Bug Logs, updated RTM. Responsibilities: Test Engineers execute tests and file bugs; Developers verify, patch, and deploy fixes."

Footnotes

  1. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

Test Closure & Evaluation

Phase 6

The testing team evaluates the complete cycle against exit criteria (e.g., zero high-severity bugs open) and prepares a final summary report. Inputs: Test Execution Reports, Bug Metrics. Outputs: Test Summary Report, Test Closure Report, Retrospective Action Items. Responsibilities: Test Manager and QA Lead analyze overall metrics and officially sign off on product quality."

Footnotes

  1. Software Testing Life Cycle (STLC) Phases - Comprehensive guide by Testomat.io outlining all phases, inputs, outputs, and roles in the STLC. ↩

The Shift-Left Testing Paradigm

Integrating testing early in the software development lifecycle—shifting testing 'left' in the timeline—can reduce overall bug-fixing costs by up to 10×10 \times. Finding and addressing a defect during the Requirement Analysis or Design phases is dramatically more cost-efficient than diagnosing and patching the same defect once the software has been deployed to production!

Footnotes

  1. Shift-Left Testing Paradigm and Cost Optimization - Academic research on the economic benefits of early testing integration. ↩

Systematic Test Case Design Process

  1. 1
    Step 1

    Identify what the system must perform and what rules apply. Break down the user story or requirement into individual testable actions and validation points. For example, for a password reset request, identify all paths (e.g., unregistered email, empty field, correct email).

  2. 2
    Step 2

    Establish the exact starting state the system must occupy before the test begins (e.g., 'User is logged out and on the landing page') and the final state the system must occupy upon successful execution (e.g., 'A password reset token is generated and recorded in the database').

  3. 3
    Step 3

    Gather or generate the specific inputs required to run the test. Apply test design techniques such as Boundary Value Analysis to select critical inputs that are highly sensitive to software faults (e.g., testing exactly 88, 77, and 99 characters for an 88-character minimum rule).

  4. 4
    Step 4

    Write sequential, imperative, and unambiguous steps that a manual tester or automation script can execute without hesitation. Keep each step focused on a single logical action (e.g., '1. Click Forgot Password. 2. Enter registered email address. 3. Click Send Reset Link.').

  5. 5
    Step 5

    Specify the exact physical, measurable, and observable outcome of the system for each step. Avoid subjective terms like 'system should work'. Instead, write: 'System displays a green success alert saying: Password Reset Email Sent'.

  6. 6
    Step 6

    Link the created Test Case back to the respective requirement ID in the RTM. This guarantees complete requirements coverage and prevents gaps.

    Footnotes

    1. Test Case Design Techniques - Best practices in test case template design and black-box testing methodologies from Qase. ↩

Test Case ID: TC-LOGIN-001 (Effective)

Description: Verify successful user login with valid registered email and minimum boundary password length (8 characters).

Preconditions: User is on the login page (`/login`) and the email `user@example.com` is registered in the database with the password `P@ssw0rd`.

Test Steps:

  1. Enter the registered email address "user@example.com" in the Email input field.
  2. Enter the valid 8-character password "P@ssw0rd" in the Password input field.
  3. Click on the "Log In" button.

Expected Result:

  • The page redirects to the user dashboard page (`/dashboard`).
  • A welcome toast notification appears saying "Welcome back, user!".
  • The user's active session is initialized in the browser storage.

Postconditions: User is logged in; session cookie is stored.

Traceability: Mapped to requirement RQ-AUTH-101.

Test Suite Execution Distribution

Results of executing a test suite containing 120 test cases for module RQ-AUTH

The Danger of Vague Assertions

Ineffective test cases frequently use terms like 'should work' or 'login is successful' as expected results. This introduces subjectivity. Expected results must specify the exact physical indicators (UI updates, API responses, database state changes) that mark a test as successful. Subjectivity in tests leads to false positives and undetected production defects!

Footnotes

  1. Writing Effective Test Cases - Analysis of effective vs ineffective test design and precision in assertions. ↩

Advanced Test Case Design & Traceability Deep Dives

Knowledge Check

Question 1 of 4
Q1Single choice

Which phase of the Software Testing Lifecycle (STLC) is primarily responsible for establishing the test environment specifications, determining resource requirements, and producing the test budget?

Previous

Next