2. Acceptance criteria and requirement review

An acceptance criterion describes externally meaningful behavior under stated conditions. It should identify the starting state, action and observable result without requiring knowledge of internal method names. A vague phrase such as search works leaves case handling, whitespace, empty input and filter combinations unresolved.

Review requirements before execution. Ask which interpretation users expect and record open questions rather than silently choosing one. This static review can prevent expensive rework even when no test script has been written yet.

The example specifies a country-and-query result using the companion fixture’s stable role ids. The country and query predicates combine with AND, and title matching ignores case after trimming. This is a small contract that can support manual, API and browser checks.

Given/When/Then is a communication structure, not proof by syntax. Keep each scenario focused on one meaningful rule and include enough fixture context to explain the expected result. A list of UI clicks with no business outcome is not a useful acceptance criterion.

The weak scenario says results are correct without defining which roles should appear. It cannot distinguish an empty result, all roles or the expected subset. Adding more automation around that sentence would make the assumption faster to repeat, not more justified.

Avoid hiding undecided requirements in test code. If empty search should mean all country-matching roles, write that explicitly. If it should mean no results, that is a different product decision and needs a different oracle.

Write two criteria for the same filter: empty query with country US, and mixed-case query qa with country UA. Use the four fixture records and give the complete expected id list in original order. Begin by writing the first criterion in plain language.

Then express it as a small Given/When/Then record. Add one open question about searching company names, which this lesson’s contract does not include. The task develops clear scope rather than rewarding elaborate scenario syntax.

Step 1: List the US fixture ids manually. Step 2: Write the normalized UA query criterion.

The solution expects r2 and r4 for an empty US query, and r1 for the normalized UA query. The company-name question remains open instead of being asserted as implemented. This preserves the difference between an agreed requirement and a useful suggestion.

The lab verifies the stated fixture results, while review checks that the criterion is observable and independent. If the fixture changes, review expected ids deliberately rather than regenerating them from the new implementation automatically.

In interviews, describe an ambiguity you would raise before automating and explain its effect on the oracle. Show one concrete criterion with a complete expected result. Avoid claiming that every acceptance criterion must use one particular notation.

Next, use equivalence partitions to choose representative inputs. A clear contract lets you reduce redundant cases without pretending that one successful input proves the entire feature.

Optional stretch — after the core task works: Add a criterion for clearing the country selection.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.