Methodology

BDD, TDD and the test-design techniques behind them.

15 terms

A

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.

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.