Test Implementation

Why it matters

Execution time is usually the scarcest time in a release. Every hour lost to a missing test account, the wrong build on staging or a suite waiting for another is an hour not spent finding defects. And an environment that is not what you think it is gives false results: tests that fail for reasons unrelated to the product, or passes that production would not repeat.

For the tester, implementation is where design becomes repeatable: a procedure with a stated set-up and wrap-up can be run by a colleague, re-run after a fix and automated later.

What implementation produces

Test design ends with test cases, test data requirements and the environment the tests need. Implementation turns them into concrete testware. The ISTQB syllabus lists these work products:

• Test procedures: test cases in execution order, with the actions that set up their preconditions and wrap up afterwards.
• Test scripts: manual step-by-step instructions or automated code that carry out the tests.
• Test suites: procedures or scripts executed together in one test run.
• Test data: the actual accounts, records, files and values that meet the data requirements.
• The test execution schedule: which suites run in which order, when and where.
• Test environment elements: the environment the tests run in, plus stubs and drivers that stand in for missing components (as in the lesson on component testing), simulators that behave like a real device or system, and service virtualisation, which imitates whole dependent services.

Procedures, suites and the execution schedule

A test case says what to check; a test procedure says in what order to run several cases and what to do around them. Cases that share preconditions belong together: one procedure sets up a logged-in customer with a full cart once, runs its cases and cleans up, so the next procedure starts from a known state.

Procedures are grouped into suites for a purpose (smoke, feature, regression), and the schedule orders the suites. ISTQB names three common prioritisation strategies: risk-based (tests for the most important risks first), coverage-based (tests that achieve the most coverage first) and requirements-based (tests for the requirements that stakeholders rank highest first). Two limits apply: a test that others depend on runs first even if its priority is lower, and the order must fit when the people, tools and environments are available.

Below, one procedure shares one set-up across three cases. The schedule shows all three rules: the smoke suite runs first because every other suite depends on a testable build, the promo suite comes next because it carries the highest risk, and the checkout suite waits for the afternoon window in which the payment sandbox is booked.

TP-PROMO-01  Apply and remove a promo code
  Set-up:   account cust-basic-01, cart baseline CART-3 (3 items, 240.00 SAR)
            promo codes loaded: SAVE10 (active, 10%), OLD5 (expired)
  Run:      TC-03  apply SAVE10   -> discount 24.00, subtotal 216.00
            TC-05  remove SAVE10  -> subtotal back to 240.00
            TC-07  apply OLD5     -> "This code has expired", subtotal unchanged
  Wrap-up:  empty the cart, reset the usage count of SAVE10

Execution schedule, staging, day 1
  09:00  Smoke suite (8 checks)       must pass before any other suite
  09:30  Promo suite TP-PROMO-01..03  highest risk: changes what customers pay
  13:00  Checkout regression suite    payment sandbox booked 13:00-17:00

Creating test data and readying the environment

Design said what data the tests need; implementation creates or acquires it: seed scripts or files for accounts, products and orders in the right states, and a recorded baseline you can restore between runs, so a different result comes from the software, not from leftover data. Prefer synthetic or masked data: real customer records copied into a test environment are still personal data.

The environment is then built and verified, which means checked, not assumed: the expected build is deployed, configuration that affects behaviour is set as planned, third-party services are reachable or replaced by a stub, and every test account can log in. A smoke test, a short suite covering the main functionality, then shows the system works well enough for planned testing to begin.

Try it: Test Data Factory Try it: SQL Dataset Generator Try it: Fake User Generator Try it: Mock API Response Generator

Worked example: a readiness checklist

Before the promo-code suites start, the tester works through a readiness checklist and records each result with evidence, so "I think we are ready" becomes checks anyone can repeat. Many teams use such a checklist as the entry criteria for execution, the preconditions that must hold before it starts. The ISTQB syllabus lists available environments and test data, and passed smoke tests, among typical entry criteria.

A failed item does not mean "start and hope". On the first run, the payment sandbox timed out: the promo suite, which never reaches payment, started on time, the checkout regression suite waited, and the problem went to the sandbox owner.

• Build: version 4.2.0 is on staging and matches the release notes.
• Configuration: the promo_codes flag is on, prices are in SAR, and the time zone matches production, because code expiry depends on it.
• Test data: cart baselines and the codes SAVE10 and OLD5 are loaded; the restore script has run once.
• Accounts: a test account for each role (customer, support agent) can log in, and guest checkout works without an account.
• Integrations: the payment sandbox responds (failed on the first run); the SMS service is replaced by a stub that records messages.
• Testware: procedures TP-PROMO-01 to 03 are reviewed, traced to their test cases and loaded as a test run.
• Observability: testers can read application logs and the browser console.
• Smoke suite: all 8 checks pass on this build.

Try it: API Health Checker

Frequently asked questions

References

• 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.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.