Reusable and Regression Test Cases

Why it matters

Test cases are run far more often than they are written. Copied steps drift apart: one copy is updated, three are not, and the suite fails for reasons that are not defects. Reusable cases keep each step and each value in one place, so a new log-in screen or a new limit is changed in one place.

A regression suite helps only while the team trusts it and can afford to run it. A suite that only grows fills with duplicates and cases for removed features, becomes too slow and is skipped when time is short, which is exactly when it is needed.

From one-off to reusable test cases

A one-off test case mixes three things: the steps that check a behaviour, the data values and the set-up the steps need. That is fine for a check you run once, and expensive as soon as the case is copied for another value.

A reusable test case keeps the three apart. In ISTQB glossary terms, the case written with placeholders is a high-level (logical) test case: its inputs and expected results are abstract. Each row of concrete values in its table makes a low-level (concrete) test case, with its own expected result and its own pass or fail.

• Parameterised: the steps contain placeholders such as <qty> instead of fixed values.
• Data-driven: a table of values and expected results drives the runs, one row per run.
• Shared steps: set-up that many cases need, such as logging in, is written once and referenced by its ID.

Worked example: one case, many data rows

Requirement: "A customer can add 1 to 10 units of an item to the cart. If fewer units are in stock than requested, nothing is added and a message says how many are left." Each row below has a type tag and its own expected result, with the messages taken from the screen design; stock is a column because one row needs a different value.

Run the case row by row and record one result per row. If the limit changes from 10 to 20, you edit only the table: 20 and 21 replace 10 and 11, and the messages name the new limit; the steps stay the same. Saved as a CSV file (comma-separated values: a plain-text table with one row per line), the same table can feed an automated test: the ISTQB glossary describes data-driven testing as a scripting technique that keeps test data and expected results in data files used by the test scripts.

TC-CART-010   Add <qty> units of a product to the cart
Precondition: SS-01 Log in as a customer and open product P-200
              (stock level as in the row)
Steps:        1. Enter <qty> in the Quantity field
              2. Select "Add to cart"
Expected:     <expected>

Row  Type      qty      stock  expected
R1   positive  3        50     added: cart shows 3 x P-200
R2   boundary  1        50     added: cart shows 1 x P-200
R3   boundary  10       50     added: cart shows 10 x P-200
R4   boundary  0        50     refused: "Enter a quantity from 1 to 10"
R5   boundary  11       50     refused: "You can add at most 10 units"
R6   negative  2.5      50     refused: "Enter a whole number", cart unchanged
R7   edge      (empty)  50     refused: "Enter a quantity from 1 to 10"
R8   edge      5        4      refused: "Only 4 left in stock", cart unchanged

Try it: Test Case Generator Try it: CSV Dataset Generator

Shared steps: write common set-up once

Write the set-up that many cases share, such as logging in and opening a product, once as a shared step block with its own ID, such as SS-01. When the log-in page gains a one-time password step, you update SS-01 and every case that uses it is current again. Test management tools often call this shared steps; in a spreadsheet, a reference to the block ID does the same job.

• Keep the block to set-up and navigation. The behaviour a case checks stays in that case, where the person running it can see it.
• End the block with a checkpoint, such as "the page for P-200 is shown", so a set-up problem is not reported as a failure of the case.
• Before you change a block, check which cases use it: a change made for one feature can break the others.

Positive, negative, boundary and edge cases in one suite

Tagging every row with its type makes gaps visible: if all the rows are positive, the suite proves only the happy path, however many rows it has. Balance does not mean equal numbers; it means every rule has its accepted and its refused side covered. For the quantity rule:

• Positive: valid input and intended use, such as 3 units. The item is added.
• Negative: invalid input, such as 2.5. It is refused with a clear message and the cart does not change.
• Boundary: the smallest and largest allowed values and their neighbours just outside: 1, 10, 0 and 11.
• Edge: one input or condition at an extreme, such as an empty field, or an item almost sold out: 4 left when 5 are requested.

Try it: Boundary Number Dataset Generator Try it: Negative Test Generator

Building and maintaining a regression suite

The lesson on confirmation and regression testing showed how to choose which tests to run after a change; this section is about the suite itself. A case belongs in it when it protects behaviour that must keep working and its expected result is stable. Tag each case with a tier, such as core for every build and full for the nightly run, guided by its priority, and review the suite at a fixed point, such as the end of each release.

• Promote: critical journeys, high-priority rules, areas that broke before, and a case for each fixed defect the suite did not already cover.
• Leave out: one-time checks and duplicates. Cases for a feature that still changes every sprint wait until its behaviour settles.
• Update: when a requirement changes, update the affected expected results in the same sprint as the code.
• Merge and retire: cases that check the same behaviour become one; cases for removed features are archived with the reason.
• Repair: a case that fails without a product defect, because of unclear steps or unreliable data, is fixed promptly.

Try it: Regression Scenario Generator Try it: AI Duplicate Test Case Detector

Frequently asked questions

References

• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.