◇ OpenCyber Academy
Engineering · Chapter 30 · English

Chapter 30 — Verification laboratory I

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 30 — Verification laboratory I

Lesson map

Lesson 30 published. Map, example, EX088.

flowchart TD
  N0["Learning outcomes"]
  N1["30.1 Lab setup"]
  N2["30.2 Test cases"]
  N3["30.3 Evidence"]
  N4["30.4 Results"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 Lab setup"]
  N2["30.2 Test cases"]
  N3["30.3 Evidence"]
  N4["30.4 Results"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 Lab setup]
    |
    v
[30.2 Test cases]
    |
    v
[30.3 Evidence]
    |
    v
[30.4 Results]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) build a test environment for identity; (2) write test cases with expected results; (3) record evidence linked to configuration versions.

30.1 Lab setup

The verification laboratory is a separate test tenant of the identity provider, with synthetic users, groups and a handful of test applications, plus a copy of the HR feed using synthetic records. It is isolated from production so tests cannot affect staff. Its configuration comes from the same version-controlled files as production, so tests exercise exactly what will be deployed. Sana documents how to rebuild the lab from scratch, which lets others repeat her tests and lets the council keep using it after she leaves.

30.2 Test cases

Each test case states its purpose, the requirement it verifies, the input and the expected result. Examples: a synthetic leaver is marked in HR, and within four hours every test application refuses sign-in; a synthetic clerk is assigned the approver role, and the preventive check blocks it; a token is presented after expiry and is rejected; a token issued for one application is presented to another and is rejected. Cases cover both access that must work and access that must fail, and expected results are written before running.

30.3 Evidence

Evidence records what each test did: date, configuration version, input, observed output and pass or fail, with logs attached. A reviewer can confirm a result without rerunning it. Evidence that cannot be linked to a specific configuration version is weak, because it may describe a setup that no longer exists. Sana stores evidence beside the traceability matrix, so each requirement points to its tests and each test to its evidence, forming the chain auditors and examiners will follow. Evidence is retained for the life of the system.

30.4 Results

Of 84 test cases in the first round, 79 pass. The five failures include an application that accepts tokens with the wrong audience, a mover whose old access was not removed because of an overlapping exception and a desk procedure step missing from the runbook. Each failure is fixed, retested and recorded. Sana reports failures openly in the results summary; reviewers trust a report that shows honest failures and fixes far more than one in which everything passed first time.

Seventy-nine of 84 is a 94 percent first-round pass rate.

Worked example

The first verification round passes 79 of 84 tests; five failures, including a wrong-audience token acceptance, are fixed and retested with evidence linked to configuration versions.

Synthetic case. Tests, failures and versions are synthetic.

Errors and limits

Evidence not linked to a configuration version cannot show that the tested setup is the one in production.

Exercises

Synthesis

A rebuildable test tenant, tests with expected results and versioned evidence make identity verification trustworthy.

Continue studying — chapter 30 of 50

← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →