Phase 4: Automated Testing

By this point, the plugins are validated, the scenario is built, and the curriculum is written. Phase 4 is where you confirm the whole thing actually works as a student would experience it.

Claude has a full MCP harness over both the VM infrastructure and the deployed scenario. That means end-to-end testing doesn’t require a human in the seat — Claude can deploy, interact, observe, and report.

Two Testing Modes

Browser-Based (Student Simulation)

Claude drives the student-facing lab interface through the browser — navigating curriculum blocks, submitting flags, triggering unlocks, using the tools made available in the student environment. This is the closest proxy to “does a student experience work correctly?”

Use this mode to:

• Confirm the curriculum flow is gated correctly (flags unlock the right sections, wrong submissions fail gracefully)
• Verify that instructions in the curriculum match what students actually see in the environment
• Catch UI-level failures — broken links, missing assets, pages that don’t load

VM Execution (Lab Flow Walk)

Claude connects directly to machines and works through the lab manually — the same steps a student would take, but from inside the machine rather than through the student UI.

Use this mode to:

• Validate that the attack and defense paths actually work (tools are staged, services are running, vulnerabilities are exploitable in the way the curriculum implies)
• Catch environmental issues that don’t surface in UI testing — wrong file permissions, services that didn’t start, dependencies that staged correctly but didn’t install
• Walk the full ICS/SCADA scenario end to end: connect to the engineering workstation, interrogate the PLC, simulate the attack path, trigger the detection, work the response

Use both

Browser testing and VM exec catch different classes of problems. Browser testing finds curriculum and flow issues; VM exec finds environment and technical correctness issues. Running only one is incomplete.

What to Expect

For a scenario of this complexity — 14 custom plugins, ICS protocol emulators, multi-machine dependencies — the first full test run will find issues. That’s the point.

Common findings at this stage:

• A plugin that passed on the test canvas breaks in the course canvas because of a dependency on another plugin’s output
• Curriculum instructions reference a step that works differently than described once you’re actually sitting on the machine
• A flag condition triggers too early or too late relative to where the curriculum says it should

Each finding goes back to the appropriate phase for a fix. The test harness makes this loop fast — Claude identifies the issue, you fix it, redeploy, Claude retests. You don’t need to walk through the entire lab manually after each fix; Claude handles the regression.

---

Back to: ICS/SCADA Case Study Overview