Extends TDD by writing acceptance tests collaboratively with the customer or product team before implementation begins. Aligns the team on what 'done' looks like in concrete, testable terms.
Methodology
BDD, TDD and the test-design techniques behind them.
15 terms
A
B
Collaborative specification writing using human-readable scenarios (Given/When/Then) shared across product, dev, and QA. Often automated with Cucumber, SpecFlow, or similar tools.
C
Deliberately injecting failures (killing instances, adding latency, dropping packets) into production or production-like environments to verify resilience. Pioneered by Netflix's Chaos Monkey. Uncovers brittleness that synthetic tests can't reproduce.
M
Generating test cases automatically from a formal model of system behaviour (state machines, decision tables). Useful when the system has many states and rules — the model finds combinations a human would never enumerate.
Measuring test quality by deliberately introducing small bugs (mutations) into the source and checking whether tests catch them. A high mutation score means the suite genuinely exercises the code, not just executes it. More honest than line coverage.
P
Asserting that a property (e.g., 'reverse(reverse(list)) == list') holds for many automatically generated inputs, instead of writing one example per case. Tools like Hypothesis and fast-check generate thousands of cases and shrink failures to a minimal example.
Q
An automated checkpoint in a build or deployment pipeline that blocks promotion if quality criteria (test pass rate, coverage threshold, security scan) aren't met.
R
Prioritising tests by the likelihood and impact of failure — the highest-risk areas get the most coverage, low-risk areas get less. The honest answer to 'we can't test everything before the release date'.
S
The stages a product passes through from concept to retirement: requirements, design, implementation, verification, deployment, maintenance. The container that the testing life cycle (STLC) sits inside.
Moving testing earlier in the development lifecycle — running tests at design and code-review time, not just before release. Goal: find defects when they're cheapest to fix.
Validating quality in production — through monitoring, feature flags, canary releases, and chaos experiments — to catch issues that synthetic tests can't reproduce.
The structured phases of testing: requirement analysis, test planning, test design, environment setup, execution, and closure. Mirrors the SDLC at the testing layer.
T
Write a failing test first, write the minimum code to make it pass, refactor. Drives design through tests rather than testing afterward — and produces a thorough unit test suite as a byproduct.
The implicit cost of choosing a quick or expedient solution today over a more durable one. In testing, it accumulates as flaky tests, missing coverage, and brittle locators that slow every future change.
A model for balancing test types: a wide base of fast unit tests, a smaller layer of integration tests, and a thin layer of slow end-to-end tests. Counters the inverted 'ice-cream cone' anti-pattern of UI-heavy suites.