Test Design Techniques

Acceptance Test-Driven Development (ATDD) is a collaborative practice where the team — developer, tester, and business stakeholder — agrees on concrete acceptance tests for a feature before any code is written, then builds to make those tests pass. It turns acceptance criteria into an executable definition of done.

Behavior-Driven Development (BDD) is a collaborative approach where features are described as Given/When/Then scenarios in plain language before any code is written, so developers, testers, and product stakeholders share one unambiguous definition of "done." Those scenarios, typically written in Gherkin, often become the automated acceptance tests themselves.

Boundary value analysis is a test design technique that targets the edges of an input range — the minimum, maximum, and the values just inside and just outside them — because that's where off-by-one errors and validation bugs cluster. If a field accepts ages 18-65, BVA tests 17, 18, 65, and 66, not just a "normal" value like 30.

Checklist-based testing uses a predefined list of items, conditions, or questions to guide testing — a lightweight structure without the full detail of written test cases. It's faster to create and execute than formal test cases, at the cost of being less precise and harder to make fully repeatable.

Combinatorial testing systematically tests combinations of input parameters — not every possible combination, which grows exponentially, but a mathematically chosen subset that still covers all pairs (or triples) of parameter values at least once. It's the general technique that pairwise testing is the most common specific case of.

Data-driven testing separates test logic from test data, running the same test script repeatedly against different sets of input values pulled from an external source — a spreadsheet, CSV, or database. It lets one script cover many scenarios without duplicating the test code for each one.

Decision table testing maps every combination of input conditions to their expected output in a table, then derives one test case per column — a systematic way to make sure complex business rules with multiple interacting conditions are tested completely, not just the obvious cases.

Equivalence partitioning divides an input range into groups (partitions) that should all behave the same way, then tests just one representative value from each group instead of every possible value. It's the foundational technique that makes exhaustive input testing unnecessary in most cases.

Error guessing relies on a tester's experience and intuition to predict where defects are likely to hide — based on patterns from past bugs, common developer mistakes, and areas of known complexity — rather than following a formal, systematic technique.

Gherkin is the plain-language, structured syntax used to write Behavior-Driven Development scenarios in a Given/When/Then format — readable by non-technical stakeholders while still being precise enough for tools like Cucumber and SpecFlow to parse and execute as automated tests.

Keyword-driven testing describes test steps as a sequence of predefined keywords — "Click", "EnterText", "VerifyText" — that map to reusable automation code, letting non-programmers assemble tests from a spreadsheet or table without writing script code directly.

Model-based testing generates test cases automatically from a formal model of the system's expected behavior — a state diagram, a flowchart, or a specification — rather than having a human write each test case by hand. Changing the model regenerates the tests, keeping them in sync with the intended behavior.

Mutation testing measures the quality of a test suite itself by deliberately introducing small bugs ("mutants") into the code — changing a `+` to a `-`, flipping a boolean — and checking whether the existing tests catch each one. Tests that fail to catch a mutant reveal a gap in coverage that a plain coverage percentage wouldn't show.

Pairwise testing generates a minimal set of test cases that covers every possible pair of input parameter values at least once, based on the observation that most defects are triggered by interactions between just two parameters. It's the most common practical form of combinatorial testing.

Risk-based testing prioritizes testing effort according to the likelihood and impact of failure in each area of the system, focusing the most scrutiny on the highest-risk functionality rather than spreading effort evenly. It's a strategy for allocating limited testing time deliberately, not a specific technique.

Scenario-based testing designs test cases around realistic, end-to-end user scenarios — a customer buying a gift for someone else, a support agent processing a return — rather than testing individual features in isolation. It aims to reveal issues that only surface when a real workflow spans multiple features together.

Session-based testing structures exploratory testing into time-boxed sessions with a defined charter (a goal or area of focus), producing a session report documenting what was tested, what was found, and what still needs coverage. It brings accountability and repeatability to otherwise unstructured exploration.

State transition testing designs test cases around the different states a system can be in and the valid (and invalid) transitions between them — like an order moving from Pending to Shipped to Delivered — specifically testing that only the allowed transitions can happen and disallowed ones are correctly blocked.

Test-Driven Development (TDD) is a development practice where a developer writes a failing automated test before writing the implementation code, then writes just enough code to make it pass, then refactors — repeating in short cycles. Tests drive the design, rather than being added after the fact.

Use case testing derives test cases directly from documented use cases — structured descriptions of how an actor (a user or another system) interacts with the system to achieve a goal, including the main success path and alternate or exception paths.