16. Capstone: investigate a small role catalogue

qatestingtest-designindependent-practice

Saved on this device

Full lesson · 4 learning steps Open any exercise for focused practice

Step 1 of 4 · intro card

16. Capstone: investigate a small role catalogue

Concept and contract

Produce a compact evidence package with requirements, cases, observations and a reproducible report.

The capstone uses the local four-role catalogue and fictional saved-list accounts. Your goal is to investigate a bounded change, not to certify a production system. Choose a combined-filter risk and a private saved-state risk, then define independent expected results.

Reuse the earlier techniques selectively. Partitions and boundaries help limit validation, a decision table helps ownership, a transition sequence helps repeated saves, and SQL can inspect a disposable stored-state fixture. Do not include a technique merely to fill a template.

Mechanism and worked example

The worked plan names three observations: exact UA-query ids, a rejected invalid limit and a denied foreign-account read.

The worked plan names three observations: exact UA-query ids, a rejected invalid limit and a denied foreign-account read. Each has a clear oracle and local scope. The automation course will execute corresponding checks, but the plan should already be understandable without reading test code.

Keep evidence traceable to fixture version and inputs. An observed failure should become a reproducible report with expected and actual outcomes. A successful run should still state which risks and environments were not investigated.

Complete worked example

json

{
  "fixture": "roles-v1",
  "cases": [
    {
      "risk": "combined filter",
      "path": "/api/roles?country=UA&q=qa",
      "status": 200,
      "ids": [
        "r1"
      ]
    },
    {
      "risk": "limit validation",
      "path": "/api/roles?limit=0",
      "status": 400
    },
    {
      "risk": "account isolation",
      "caller": "alice",
      "owner": "bob",
      "status": 403
    }
  ]
}

Reasoning: Each observation is attached to a named risk and explicit local oracle.

Counterexamples and common mistakes

The weak plan checks the home page and calls the whole release ready.

The weak plan checks the home page and calls the whole release ready. It cannot distinguish the two named risks. A polished report with no corresponding observations is still missing evidence, regardless of the number of headings or screenshots.

Do not alter a real ApplyDjinn account or call third-party job feeds for this exercise. The companion lab is deliberately isolated. Claims about production performance, accessibility or security require their own scoped evidence.

Counterexample: what this check misses

json

{
  "cases": [
    "Home page opens"
  ],
  "conclusion": "Every catalogue and account risk is covered"
}

Reasoning: A page-open check cannot establish the named filter and account contracts.

Independent practice: small task

Write a five-case plan covering combined filtering, invalid limit, anonymous private read, foreign-account read and repeated owner save.

Write a five-case plan covering combined filtering, invalid limit, anonymous private read, foreign-account read and repeated owner save. Specify expected ids or status plus the relevant postcondition. Begin with the combined-filter case before adding the private-state sequence.

Run the provided local checks, record results and write one short report for the controlled OR-filter defect. Optional extension: add a new risk and explain why its evidence belongs in the release set. Keep the core plan small enough to review.

Step 1: Specify the combined filter’s exact ids. Step 2: Add private-state cases and a read-back postcondition.

Practice starter: solve before reading the solution

json

{
  "fixture": "roles-v1",
  "cases": "TODO: five focused cases",
  "postcondition": "TODO",
  "controlledDefectReport": "TODO",
  "limitations": "TODO"
}

Reasoning: Write one exact result before expanding to the five-case plan.

Hint 1: Use only fictional local accounts.
Hint 2: Record limitations alongside successful results.

Solution, tests and trade-offs

The solution records all five cases and requires a saved-list read after the repeated save.

The solution records all five cases and requires a saved-list read after the repeated save. It also names r4 as the extra record exposed by the controlled OR defect. This connects test design to an observable wrong implementation rather than a collection of ceremonial steps.

The verifier checks executable local cases and the structure of the evidence plan. Human review still judges the defect report and scope statement. Passing the lab is a self-study milestone, not a professional certification or a guarantee of job readiness.

Practice solution and acceptance checks

json

{
  "fixture": "roles-v1",
  "cases": [
    "UA plus qa returns only r1",
    "Zero limit is 400",
    "Anonymous saved-list read is 401",
    "Alice reading Bob saved list is 403",
    "Saving r1 twice leaves exactly one r1"
  ],
  "postcondition": "Owner GET /api/saved returns [r1]",
  "controlledDefectReport": {
    "input": {
      "country": "UA",
      "q": "qa"
    },
    "expectedIds": [
      "r1"
    ],
    "actualIds": [
      "r1",
      "r3",
      "r4"
    ]
  },
  "limitations": "Local fixture only; no production capacity, complete accessibility or security claim."
}

Reasoning: The solution connects repeated commands to a stored postcondition and keeps limitations visible.

Interview reasoning and next step

In an interview, present one risk from requirement through fixture, case, result and conclusion.

In an interview, present one risk from requirement through fixture, case, result and conclusion. Explain what you would investigate next and why. A clear small chain of evidence is stronger than a long list of tool names.

Move to the automation course when you can write these expectations without copying the solution. You will turn them into unit, API and browser tests while retaining the same independent oracles and careful scope.

Optional stretch — after the core task works: Add one new risk with an independent oracle.

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.

Produce a compact evidence package with requirements, cases, observations and a reproducible report.