Test Case Design – Software Engineering Principles and Practices

Test Case Design is the process of creating a set of specific inputs, execution conditions, and expected results to verify a particular feature or requirement.

In professional software engineering, a test case isn't just a "random check"—it is a structured document that ensures testing is repeatable, objective, and thorough.

💡 What is a Test Case?

A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly.

Standard Components of a Test Case:

Test Case ID: A unique identifier (e.g., TC_001).
Description: What is being tested?
Pre-conditions: What must be true before the test (e.g., "User is logged in").
Test Steps: Detailed, numbered instructions.
Test Data: Specific inputs used (e.g., Username: admin123).
Expected Result: What the system should do.
Actual Result: What the system actually did (filled in during execution).
Status: Pass/Fail.

🛠️ Test Design Techniques

Since we cannot test everything (Exhaustive Testing is Impossible), we use specific strategies to pick the most effective test cases.

A. Black-Box Techniques (Functional)

These focus on inputs and outputs without looking at the code.

Equivalence Partitioning (EP): Divide input data into "partitions" that are expected to behave the same way. You only test one value from each partition.
- Example: If a field accepts ages 18–60, your partitions are: Underage (<18), Valid (18-60), and Overage (>60).
Boundary Value Analysis (BVA): Most bugs hide at the "edges" of input ranges. You test the exact boundaries.
- Example: For the 18–60 range, you test 17, 18, 19 and 59, 60, 61.

B. White-Box Techniques (Structural)

These focus on the internal logic, loops, and paths of the code.

Statement Coverage: Ensuring every line of code is executed at least once.
Decision/Branch Coverage: Ensuring every "If/Else" path is taken.
Path Testing: Testing all possible mathematical paths through a function.

📊 Example: Designing a Test Case for "User Login"

Field	Details
TC ID	TC_LOGIN_01
Description	Verify that a user can login with valid credentials.
Pre-condition	User has a registered account.
Test Steps	1. Navigate to login page. 2. Enter valid email. 3. Enter valid password. 4. Click "Login".
Test Data	Email: `test@user.com`, Pwd: `Password123`
Expected Result	User is redirected to the Dashboard and sees a "Welcome" message.

✨ 5.3 Traceability: The RTM

One of the most important parts of design is the Requirements Traceability Matrix (RTM). This is a table that maps your Test Cases directly back to the SRS Requirements.

Why? To ensure that every requirement has at least one test case and that you aren't testing things that weren't requested.

💡 The "Good" Test Case Checklist

A high-quality test case should be:

Accurate: Tests exactly what the requirement says.
Independent: Can be run without relying on the results of another test case.
Repeatable: Different testers should get the same result every time.
Traceable: Linked to a requirement.