Typorithm · easy
Step 1 of 4 · intro card
Choose observable checks that reduce a specific product risk, rather than counting clicks or green tests.
Testing is an investigation of a product claim against evidence. Begin with a user, an action and an observable outcome. For a saved-role feature, seeing a button is not enough: the right account must retain the right role, and another account must not receive that private state.
A test oracle is the basis for deciding whether an observation is acceptable. It may be a requirement, an independently computed result or a documented protocol rule. Repeating the implementation’s output as the expected value produces agreement without independent evidence.
The worked risk note names a cross-account leak and a concrete denied-read result.
The worked risk note names a cross-account leak and a concrete denied-read result. It identifies a meaningful failure before choosing a tool. The public role catalogue remains public; only the account’s saved list is private. This distinction prevents a security check from accidentally blocking a legitimate public feature.
Choose a level that can observe the risk cheaply and directly. An API check can establish ownership behavior, while a browser check confirms the user-facing control. Neither a screenshot alone nor an arbitrary number of unit tests establishes the complete privacy boundary.
json
{
"change": "Saved roles",
"risk": "Another account receives a private saved list",
"check": "Read account B saved roles while signed in as A",
"expectedStatus": 403,
"scope": "Private saved lists, not the public catalogue"
}The weak note says that the page opened and labels the feature tested.
The weak note says that the page opened and labels the feature tested. That observation may be true while the wrong account’s saved data is displayed. A green result is useful only when the check would become red for the failure that matters.
Avoid treating ordinal impact scores as precise probabilities. Describe consequences, exposure and uncertainty, then use them to prioritize investigation. Testing reduces uncertainty; a small sample of successful actions does not prove that a feature has no defects.
json
{
"check": "Open the page",
"actual": "Page opened",
"conclusion": "All privacy behavior works"
}Write two risk notes for a combined country-and-title filter.
Write two risk notes for a combined country-and-title filter. One should concern returning roles outside the selected country; the other should concern losing valid results. Give each note a concrete query, an independent expected id list and the observation that would contradict it.
Begin with one known role and one excluded role from the companion dataset. Add the second risk only after the first expectation is unambiguous. The task is a short evidence plan, not a long document or a promise to test every possible combination.
Step 1: Choose one included fixture role. Step 2: Write the excluded role and the contradictory observation.
json
{
"query": {
"country": "UA",
"q": "qa"
},
"overInclusion": {
"expectedIds": "TODO",
"failureObservation": "TODO"
},
"omission": {
"expectedIds": "TODO",
"failureObservation": "TODO"
}
}The solution uses the same small dataset but states different failure hypotheses: over-inclusion and omission.
The solution uses the same small dataset but states different failure hypotheses: over-inclusion and omission. Expected ids come from reading the fixture, not from calling the filtering function and copying its return value. A reviewer can therefore challenge the expectation independently.
The document checker verifies required evidence fields; the local lab exercises the filter cases separately. Human review still assesses whether the selected risks matter and whether the observations justify the conclusion. Formatting a report correctly is not equivalent to proving the feature correct.
json
{
"query": {
"country": "UA",
"q": "qa"
},
"overInclusion": {
"expectedIds": [
"r1"
],
"failureObservation": "r4 appears despite country US"
},
"omission": {
"expectedIds": [
"r1"
],
"failureObservation": "r1 is missing from results"
}
}In an interview, explain one risk, its oracle and the cheapest useful observation.
In an interview, explain one risk, its oracle and the cheapest useful observation. Describe what the check cannot establish. A good answer can be short and concrete; naming a testing pyramid without connecting it to the product decision is less useful.
Next, turn informal requirements into acceptance criteria. That provides a stronger oracle and reveals ambiguities before a tester spends time automating an assumption that the product team never agreed to.
Optional stretch — after the core task works: Add a third risk involving stale saved-state display.
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.
Choose observable checks that reduce a specific product risk, rather than counting clicks or green tests.