## Chapter 40 — Verification laboratory II ### Lesson map Lesson 40 published. Map, example, EX118. ```mermaid flowchart TD N0["Learning outcomes"] N1["40.1 Tests"] N2["40.2 Rollback"] N3["40.3 Outage"] N4["40.4 Firmware recovery"] N5["40.5 Results"] N6["Test design for resilience"] N7["Results table"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 N7 --> EX["Worked example"] EX --> Q["Exercise EX118"] ``` ### Logical drawing ```mermaid flowchart LR N0["Learning outcomes"] N1["40.1 Tests"] N2["40.2 Rollback"] N3["40.3 Outage"] N4["40.4 Firmware recovery"] N5["40.5 Results"] N6["Test design for resilience"] N7["Results table"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX118"] ``` ```text [Learning outcomes] | v [40.1 Tests] | v [40.2 Rollback] | v [40.3 Outage] | v [40.4 Firmware recovery] | v [40.5 Results] | v [Test design for resilience] | v [Results table] | v [Worked example] --> [Exercise EX118] ``` ### Learning outcomes You will (1) verify resilience features; (2) test recovery; (3) record results. ### 40.1 Tests Mateo tests rollback, server outage, firmware recovery and restore alert. These four test the resilience features designed earlier: rollback for a bad image, the local copy for a server outage, the recovery tool for a failed firmware update and the alert for a failed restore. Each feature exists because a scenario or a studio question showed it was needed. Until tested, each is only a claim in the design documents. Mateo writes the expected result for each test before running it, and keeps the written procedures with the evidence. ### 40.2 Rollback A deliberately broken image on a lab PC is rolled back in ten minutes. The broken image was a synthetic release with a deliberately faulty policy file that prevented logon. The PC detected the failure after the first start, rolled back to the previous signed image and returned to service. Ten minutes included detection, rollback and the digest check. Mateo repeated the test on each hardware model, and all completed within a similar time. The faulty release was then deleted from the lab server. ### 40.3 Outage With the server disconnected for three days, lab PCs restore from local copies each night. Three nights is shorter than the week the design promises, but long enough to show that restores keep working without the server and that nothing builds up in the logs or on disk. Each morning the PCs showed a successful restore, recorded locally. When the server was reconnected, the stored results were delivered and appeared on the dashboard with their original times. Marta watched the first morning's check. ### 40.4 Firmware recovery A simulated failed firmware update on a lab PC is recovered with the vendor's recovery tool. The failure was simulated by interrupting the update on a lab PC set aside for the purpose, with the vendor's guidance. The recovery tool restored the previous firmware, and Mateo then checked that Secure Boot, the firmware password and the boot order were as required. The test found one practical gap, described in the worked example. Each step and its timing were written down so the recovery could be repeated by someone else. ### 40.5 Results All four tests pass; results are recorded with evidence. All four tests matched their expected results, and the evidence for each is stored with the procedure, the image version and the date. A pass here means the feature worked on lab PCs under the tested conditions. Mateo notes what was not tested, such as an outage longer than three nights, so readers know the limits of the evidence. The results feed the evidence dossier. Marta signed the results before they were filed. ### Test design for resilience Each resilience test has a hypothesis, setup, action, expected result and recovery steps. For the outage test: hypothesis, lab PCs restore from local copies without the server; setup, disconnect server; action, run three nights; expected, all restores succeed; recovery, reconnect server and check reports. Writing tests this way keeps them safe and repeatable. All tests use lab PCs, never patron PCs during opening hours. ### Results table A table records each test, date, result and evidence link. ### Follow-ups Each finding, such as the USB stick requirement, gets an owner. ### Repeat Tests repeat annually. ### Learning Tests turn assumptions into evidence. ### Sharing Results are shared with Marta. ### Comparison Results are compared with chapter 33's design expectations. ### Gaps Only the USB stick gap was found. ### Confidence Passing tests increase confidence that recovery will work. ### Records Evidence joins the dossier. ### Safety rules No test runs on patron PCs during opening hours, and every test has a written rollback. These rules are part of the test procedures, approved by Marta. ### Documentation Each test procedure is stored in the repository with its results and the image version tested. ### Worked example The firmware test reveals the recovery tool requires a USB stick; one is stored securely at each branch. > **Synthetic case.** Synthetic. ### Errors and limits Resilience features that are never tested may not work when needed. ### Exercises - **EX118 — Rollback time.** How long did rollback take? *Rubric:* 3 = ten minutes; 2 = partial; 1 = vague; 0 = none. - **EX119 — Outage test.** How long was the server disconnected? *Rubric:* 3 = three days; 2 = partial; 1 = vague; 0 = none. - **EX120 — Firmware finding.** What did the firmware test reveal? *Rubric:* 3 = recovery needs USB stick; stored at branches; 2 = partial; 1 = vague; 0 = none. ### Synthesis Test resilience features before relying on them. ### Continue studying — chapter 40 of 50 [← Chapter 39 (draft)](#ch-39) · [Course chapter index](../SUBJECTS.md) · [Chapter 41 (draft) →](#ch-41) ## Worked answers **EX118.** Ten minutes. **EX119.** Three days. **EX120.** Recovery requires a USB stick, now stored at each branch.