Module 7 · Test design techniques

Test Techniques Overview

By the Mutqan Soft QA team · · 17 min · Intermediate

A test technique is a systematic way to decide what to test and how. You apply it to a source of information, such as a requirement or the code, and it helps you define test conditions, identify coverage items and choose test data. The ISTQB Foundation syllabus (v4.0) sorts techniques into three categories by what they are based on: black-box techniques use the specified behaviour, white-box techniques the internal structure of the code, and experience-based techniques the tester's knowledge and skill.

Take a sign-up form whose age field accepts 18 to 65. Equivalence partitioning, a black-box technique, gives one test per group of ages. The developer's branch coverage report, a white-box measure, shows that the code path for an empty age field never ran. An experienced tester pastes an age with a trailing space, because that broke a similar form before. Three categories, three different angles on the same field: each can reveal defects the other two miss.

Why it matters

Exhaustive testing is impossible, as the seven principles say, so every test suite is a sample. Without a technique the sample follows habit: the happy path again, the first values that come to mind, and whole classes of defects never tried. A technique makes the sample deliberate: it tells you which values to pick and why.

Techniques also make your work reviewable. "I tested the important things" cannot be checked; "every partition and boundary of the fee rule and every valid transition of the order status" can. Reviewers can spot the gaps before the release, not after it.

Black-box, white-box and experience-based techniques

Black-box techniques, also called specification-based, derive tests from the specified behaviour of the test object: requirements, user stories, business rules, an API contract. They ignore how the software is built, so the tests stay valid when developers refactor the code.

White-box techniques, also called structure-based, derive tests from the internal structure of the code, such as its statements and branches, and measure how much of it the tests exercised. They need the design or the code to exist. A requirement that was never implemented leaves no code to cover, so white-box testing cannot find that defect of omission.

Experience-based techniques use the tester's knowledge of the domain, of past defects and of how software usually fails. They find defects that systematic techniques miss, but they depend heavily on the person, so they complement the other two categories instead of replacing them.

  • Black-box: equivalence partitioning, boundary value analysis, decision table testing and state transition testing (the four in the Foundation syllabus), plus use case, pairwise and combinatorial testing later in this module.
  • White-box: statement testing and branch testing, which design tests to exercise the executable statements or the branches of the code and measure the share exercised as coverage; condition and path coverage come later in this module.
  • Experience-based: error guessing (anticipating likely mistakes and defects from what has failed before), exploratory testing (designing, running and evaluating tests at the same time while learning about the product, often in a time-boxed session guided by a test charter, a short statement of what to explore and why) and checklist-based testing (testing the conditions on a checklist built from experience).

Collaboration-based approaches: prevent defects, not only find them

The techniques above aim to detect defects. The syllabus adds collaboration-based test approaches, which also aim to avoid defects through communication before the code is written: collaborative user story writing, acceptance criteria and acceptance test-driven development (ATDD), covered in the lessons on user stories and acceptance criteria. They are a way of working with the business and developers, not a fourth category of techniques.

The techniques still do the work inside those conversations. When the team writes the example "orders of 300 SAR or more ship free", the tester asks about 299.99 and 300.00: boundary value analysis before a line of code exists.

Try it: Acceptance Criteria Generator

Choosing a technique

First ask what you are deriving tests from. A story still in refinement calls for collaboration. Specified behaviour calls for a black-box technique chosen by the shape of the rule: groups of values for equivalence partitioning, plus boundary value analysis when the values are ordered, as in a range; combinations of conditions for a decision table; behaviour that depends on what happened before for state transition testing; many independent parameters for pairwise testing. Code you need to measure calls for white-box techniques; thin documentation or a new area calls for exploratory testing and error guessing.

Choosing a technique: a story in refinement calls for collaboration, the shape of a specified rule picks the black-box technique, code calls for white-box and thin documentation for experience-based testing. Conceptual model
Question 1: What are you deriving tests from?Start from the test basis, then look at the shape of the rule

  • Answer: A story still in refinement

    Outcome: User stories, acceptance criteria, ATDDAgree examples before coding, to prevent defectsCollaboration-based

  • Answer: Specified behaviour

    Question 2: What shape does the rule have?

    • Answer: Ranges or groups of values

      Outcome: Equivalence partitioning and BVACoverage items: partitions, and boundary values where values are orderedBlack-box

    • Answer: Combinations of conditions

      Outcome: Decision table testingCoverage items: feasible columnsBlack-box

    • Answer: Depends on what happened before

      Outcome: State transition testingCoverage items: states or transitionsBlack-box

    • Answer: Many independent parameters

      Outcome: Pairwise testingCoverage items: pairs of parameter valuesBlack-box

  • Answer: The code and its structure

    Outcome: Statement and branch testingMostly developers, in component testing; cannot find missing requirementsWhite-box

  • Answer: Thin documentation or a new area

    Outcome: Exploratory testing, error guessing, checklistsDepends on skill; a charter and notes make it reviewableExperience-based

A starting point, not a rule: most features need several techniques, and risk decides how rigorous each one is.

Then let the context adjust the choice, and expect to combine techniques: most features contain rules of several shapes.

  • Risk: higher risk calls for more rigorous techniques and stronger coverage, such as 3-value BVA, or invalid transitions as well as valid ones.
  • Test level: developers apply white-box techniques mostly in component testing; the other categories work at every level.
  • Test basis: a precise specification supports black-box techniques; a vague one needs a conversation first.
  • Constraints: in some domains contracts or regulations prescribe techniques or coverage levels, and the team's skills and time limit what is realistic.

Try it: Equivalence Partition Generator Try it: Pairwise Testing Generator

Worked example: techniques for a return request

An online shop adds return requests. Each rule gets the technique that fits its shape, and the plan starts with a conversation.

  • Refinement (collaboration): "A return can be requested within 30 days." The tester asks: from delivery or from the order? Is day 30 included? The answers become acceptance criteria.
  • Return window of 1 to 30 days after delivery (a range): equivalence partitioning and 2-value BVA give 0, 1, 30 and 31 days.
  • Refund method by payment type (card or cash on delivery), gift or not, and opened or not (combinations): a decision table with up to 2 × 2 × 2 = 8 columns.
  • Return status, with cancellation allowed only before pick-up (states and events): state transition testing, including invalid attempts such as cancelling after pick-up.
  • Restocking fee in a new function (code): the developer measures branch coverage; the tester asks which branches remain uncovered.
  • Pick-up through a new, thinly documented courier integration: an exploratory session with a charter, plus error guessing from past defects such as long Arabic addresses and courier time-outs.

Try it: Decision Table Generator Try it: State Transition Generator

Common mistakes

  • Treating one technique as the whole job, such as testing only boundary values and calling the feature tested.
  • Choosing by habit, or because a tool exists, instead of by the shape of the rule: boundary values for unordered options such as payment methods.
  • Reading high code coverage as proof that the requirements are tested; it cannot see requirements that were never implemented.
  • Treating experience-based testing as unplanned clicking: without a charter and notes, nobody can tell what was covered.
  • Not recording which technique produced a test case, so reviewers cannot judge coverage and nobody knows why the case exists.

The QA perspective

On a working team the choice happens twice. In refinement you listen for the shape of each rule and ask the questions that make it testable. In test design you pick the technique per rule, record it with its coverage items in the test case or the design notes, and match the rigour to the risk agreed in the test plan.

Share the work with developers: they own white-box coverage at component level, and you ask to see the report for high-risk code. Reserve time for exploratory sessions on new or changed areas. When someone asks "is it tested enough?", answer with techniques, coverage and residual risk, not with a feeling.

Practice exercise

Choose techniques for a parking app

Your task

For each of the five rules of a city parking app below, name its shape, a technique or approach and its category, and the first coverage items or test values. Then write your questions for refinement.

Material
PARK-12  Story: pay for street parking in the app
Rule 1: A parking session lasts from 15 to 240 whole minutes.
Rule 2: The price depends on the zone (A, B or C), whether the driver
        has a resident permit and whether the car is electric.
Rule 3: A session is Booked, then Active; it ends as Ended (stopped by
        the driver) or Expired. A Booked session can be Cancelled.
        An Active session can be extended at most twice.
Rule 4: The app runs on Android and iOS, in Arabic and English, and
        accepts card, digital wallet or account balance.
Rule 5: A new SMS reminder before expiry has no specification yet.
Steps
  1. Name the shape of each rule: range, combinations, states, independent parameters, or no specification.
  2. Pick a technique or approach for each rule and write its category.
  3. List the first coverage items or test values.
  4. Write your questions for the refinement meeting.
Show the model answer
Model answer

Rule 1, a range: equivalence partitioning and BVA (black-box). Test 14, 15, 240 and 241 minutes, plus a typical value such as 60.

Rule 2, combinations of conditions: decision table testing (black-box): up to 3 × 2 × 2 = 12 columns, fewer after merging those where a condition makes no difference.

Rule 3, states and events: state transition testing (black-box). Cover the five valid transitions, including extending an Active session, and invalid attempts such as a third extension or extending an Expired session.

Rule 4, independent parameters: pairwise testing (black-box). Six tests instead of all 2 × 2 × 3 = 12 combinations still cover every pair of values.

Rule 5, no specification: experience-based. A time-boxed exploratory session with a charter, plus error guessing such as a reminder sent after the session was extended. Ask the product owner for acceptance criteria in parallel.

White-box: no rule needs you to design white-box tests; ask the developers for the branch coverage of the price calculation. Questions: Is 240 minutes the limit per booking or including extensions? Does the resident permit apply in every zone? Whose clock decides expiry, the phone's or the server's?

Frequently asked questions

Which test technique is the best one?

None in general. Each technique targets a kind of rule and a kind of defect: boundary value analysis finds off-by-one comparisons, decision tables find forgotten combinations, state transition testing finds missing or illegal transitions, and exploratory testing finds problems nobody specified. Choose by the shape of the problem and the risk, and combine techniques.

Do testers need white-box techniques if developers write the unit tests?

You may design few white-box tests yourself, but you need to understand them: to read a coverage report, to ask which risky branches are untested, and to know that 100% branch coverage says nothing about requirements that were never implemented. Testers in automation roles often write component tests too.

Is exploratory testing the same as ad hoc testing?

No. Ad hoc testing is informal: no test analysis or test design, and usually no record. Exploratory testing designs, runs and evaluates tests at the same time, but it can be structured: a charter sets the mission, a time box limits the session, and notes record what was covered and what was found. Session-based test management builds on exactly this structure.

References

Tools

Practise with Mutqan tools

Boundary Value Analysis

Perform full boundary value analysis (2-value and 3-value BVA) with equivalence classes and expected results.

Test Design

Decision Table Generator

Build decision tables from conditions and actions, generate all rule combinations and collapse impossible ones.

Test Design

State Transition Generator

Define states and events, then generate a transition table, valid/invalid transition tests and 0-switch/1-switch coverage.

Test Design

Go deeper

Your progress on this topic

Part of the QA Roadmap