◇ 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 Verification"]
  N2["30.2 Examples"]
  N3["30.3 Recording"]
  N4["30.4 Independence"]
  N5["30.5 Findings"]
  N6["Evidence quality"]
  N7["Fixing failures"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 Verification"]
  N2["30.2 Examples"]
  N3["30.3 Recording"]
  N4["30.4 Independence"]
  N5["30.5 Findings"]
  N6["Evidence quality"]
  N7["Fixing failures"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 Verification]
    |
    v
[30.2 Examples]
    |
    v
[30.3 Recording]
    |
    v
[30.4 Independence]
    |
    v
[30.5 Findings]
    |
    v
[Evidence quality]
    |
    v
[Fixing failures]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) verify requirements on lab PCs; (2) record evidence; (3) distinguish pass, fail and untested.

30.1 Verification

For each requirement, Mateo runs its test on lab PCs and records evidence: screenshots of settings, logs and test outputs.

Each requirement's test follows its written procedure, and the evidence is saved in a folder named by requirement and image version. Mateo avoids describing a result in words alone: a screenshot of the firmware setting or a log line showing the block is stronger than a note saying it worked. Evidence that would show patron data is never collected; the tests use synthetic sessions only.

30.2 Examples

R1 verified by firmware report; R3 by inserting a synthetic USB storage device and confirming block; R6 by idle timeout test.

Each example uses the method chosen when the requirement was written. The firmware report is inspection of a setting. The USB test is a direct test of behaviour. The idle timeout test waits fifteen minutes and checks that the session closes and the profile is cleared. A requirement verified only by reading the configuration, without testing its effect, is noted as weaker evidence.

30.3 Recording

Each result is pass, fail or untested, with date and tester.

Untested is a separate status, never counted as a pass. Mateo's summary gives the count for each status, so readers can see at once how much of the system has been checked. A failed result names its cause once known and links to the fix. The record is kept with the image release, so the evidence for a release stays with it. Marta signs the summary before any release moves to a branch.

30.4 Independence

A technician repeats three tests without Mateo present.

The technician follows the written procedures on her own and records her results separately. If her results differ from Mateo's, the difference is investigated before release. Independent repetition checks two things: that the tests are written clearly enough for someone else to run, and that the original results were not shaped by the designer's expectations. In this round all three matched. Her notes are kept with Mateo's results, so a reviewer can compare the two sets side by side.

30.5 Findings

Remote logging (R7) is not reaching the central server from one lab PC due to a firewall rule.

The rule on the lab network blocked the logging port from one PC's address, left over from an earlier test. Events from that PC were kept locally but never reached the central store, so a failure there would have gone unseen. The fix was a one-line rule change, followed by a re-test showing events arriving. The finding also led to a check that every PC has reported events in the last day.

Evidence quality

Evidence should allow someone else to check the result. Screenshots show settings at a moment; logs show events with timestamps; test outputs show results. Mateo stores each with the requirement ID, date and tester, and avoids evidence that contains patron data.

He also records the image version tested, so evidence stays linked to the right release.

Fixing failures

Failed requirements get a fix, a re-test and a note explaining the cause.

Planning the lab

Mateo schedules verification over two days, grouping tests by setup: firmware tests first, then OS, application, network and monitoring. Grouping saves time and reduces mistakes when switching contexts.

Each test has a written procedure so the technician can repeat it independently.

Independent repeats

The technician repeats R1, R3 and R6 independently. All match Mateo's results.

Release decision

The image is not released until R7 is fixed.

Coverage

Every requirement has a test before release, and the test list is reviewed when requirements change.

Timing

The lab finishes within the planned two days.

Worked example

The technician's repeat of R3 passes. R7's failure is logged and a rule fix scheduled.

Synthetic case. Synthetic.

Errors and limits

Verification by the designer alone can miss errors.

Exercises

Synthesis

Verify each requirement with recorded, independent evidence.

Continue studying — chapter 30 of 50

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