QA methodology and test design

The vocabulary and technique layer an automation QA interview tests, independent of any tool. ISTQB is the certification that codifies most of it, and even if you never sit it, the terms are how these conversations are conducted.

Test levels and types

The distinction interviewers listen for: retesting confirms a specific fix; regression testing checks that unrelated things still work. They are different activities with different scopes, and conflating them is a common slip.

Test design techniques

These are the techniques that let you justify why you chose those cases rather than writing dozens arbitrarily.

Equivalence partitioning. Divide inputs into classes where the behaviour should be the same, and test one value per class. An age field validating 18-65 has three classes: below, within, above.

Boundary value analysis. Test at and immediately around the edges: 17, 18, 65, 66. Off-by-one is the most common defect class, and boundaries are where it lives. Pairing this with equivalence partitioning is the standard answer.

Decision tables. For combinations of conditions with different outcomes. Systematic where ad-hoc case selection misses combinations.

State transition testing. For anything with a lifecycle — an order, a subscription, a session. Test valid transitions, and explicitly test invalid ones (can you cancel an already-shipped order?).

Pairwise / all-pairs. When there are too many combinations to test exhaustively, cover every pair of parameter values. Most combinatorial defects involve two factors, so this gets most of the coverage for a fraction of the cases.

Error guessing and exploratory testing. Experience-based, unscripted, deliberately trying to break things. Not a substitute for systematic design, but it finds what scripts do not — and modern risk-based guidance explicitly values it.

Risk-based prioritisation

You cannot test everything. Prioritise by risk = likelihood x impact:

• What breaks the business if it fails (payments, ordering, clinical dosing)?
• What changes most often?
• What has historically been defect-prone?
• What is hardest to detect in production?

Deep automated coverage where risk is high; exploratory or shallow coverage where it is low. Being able to say what you deliberately did not automate, and why, is a senior signal — a candidate who claims they automate everything has not had to make the trade.

What to automate, and what not to

The economics: an automated test costs to write and, more importantly, to maintain. A suite of 3,000 brittle UI tests that nobody trusts is worse than 300 reliable ones, because a failing suite people ignore provides no signal at all.

Flakiness

The defining operational problem of test automation.

Causes, in rough order of frequency: implicit timing assumptions (fixed sleeps instead of waiting for a condition), shared mutable test data, test order dependence, unmocked third-party calls, and animations or async rendering in UI tests.

The discipline: quarantine flaky tests immediately, fix or delete them, and never normalise a red build. A team that reruns until green has stopped testing. Track flake rate as a metric and treat a rising number as a defect in the suite.

Entry and exit criteria, and the defect lifecycle

Entry criteria (the build deploys, smoke passes, test data is loaded) and exit criteria (coverage of planned cases, no open critical or high defects, known issues documented) make “are we done” a decision rather than an argument.

A defect report that gets acted on quickly has: exact steps to reproduce, expected versus actual, environment and build id, evidence (log, screenshot, trace id), and a severity separate from priority. Severity is technical impact; priority is business urgency. A cosmetic typo on the landing page can be low severity and high priority — being able to separate them is a standard interview question.

ISTQB

The Foundation Level certification covers exactly the material above: the seven testing principles, the test process, design techniques, test management, defect management and tool support. Advanced levels branch into test analyst, test manager and technical test analyst.

Worth having when a job posting asks for it, mostly as evidence you use the shared vocabulary. It is not evidence you can automate anything, and the honest framing in an interview is that it standardises terminology while the engineering skill comes from building suites.

Interview angle

• “How do you decide what to test?” - risk-based prioritisation (likelihood x impact) to choose scope, then systematic design techniques - equivalence partitioning plus boundary values, decision tables for condition combinations, state transitions for lifecycles - to choose cases within it. Being able to say what you chose not to automate is part of the answer.
• “Retesting or regression testing?” - retesting confirms a specific fix works; regression testing checks that nothing else broke. Different scope, different trigger, and they are frequently conflated.
• “Severity or priority?” - severity is technical impact, priority is business urgency. They are independent: a trivial-severity typo on a pricing page can be top priority.
• “How do you handle flaky tests?” - quarantine immediately, fix or delete, and track flake rate as a metric. The failure mode to name is a team that reruns until green, at which point the suite provides no signal.
• “What would you not automate?” - anything still changing shape daily, anything needing human aesthetic judgement, and anything whose automation cost exceeds the manual cost over its expected life. Automating a one-off is a common junior mistake.
• “What is pairwise testing for?” - covering every pair of parameter values when full combinatorial coverage is infeasible, on the empirical basis that most combinatorial defects involve only two factors.