Every network project ends with the same document request: the test plan. Engineers ask for templates by name on Cisco's community forums — "ACI NRFU document template," "how to test new or modified network infrastructure with standardized testing methods" — because the artifact is mandatory and nobody enjoys producing it. Worse, producing it is the easy half: the EMA change-validation study found 98% of organizations claim pre-change validation processes, while only 11% apply them to all changes (Enterprise Management Associates). Test plans get written, filed, and skipped — because executing them is manual, repetitive, skill-gated work.
Bottom line: the test plan shouldn't be a document you write and then dread executing. In NetPilot, the agent derives the test plan from your design or change objective, executes every case against real network OS devices, and returns a pass/fail report with command-level evidence — the same session, no test code.
What a network test plan actually contains
Strip away the formatting and every serious network test plan asserts the same six layers, bottom-up:
- Physical / interface state — links up, optics healthy, error counters clean, LACP bundles complete.
- Protocol adjacencies — OSPF/IS-IS neighbors full, BGP sessions established, the expected count of each.
- Routing state — the prefixes the design promises, in the tables the design promises, with the next-hops it promises.
- End-to-end reachability — a source×destination matrix, including the paths that must fail (segmentation is a test case too).
- Failover behavior — pull the primary, verify the backup carries traffic, measure how long convergence took.
- Performance baselines — throughput, latency, jitter, and loss on the paths that matter, recorded as the reference for later comparison.
That list is also why test plans die in spreadsheets: layers 1–3 are dozens of per-device show commands across vendors with different syntax; layer 4 is a combinatorial matrix; layers 5–6 need traffic tooling (iperf3, tc/netem — compared here). Executing it once is a day of work. Executing it identically after every change is the part nobody sustains — that's the 98%-vs-11% gap.
What NRFU testing is (and why the term matters)
NRFU — network ready for use — is the acceptance-testing phase at the end of a build or migration: the structured proof that the network's actual operating state matches the design before production traffic lands on it. It's a real operator workflow with real tooling momentum: NANOG has run tutorials on automating NRFU with pytest, and Arista's open-source ANTA framework ships a dedicated anta nrfu command.
Those frameworks share a constraint: someone writes and maintains the test code. ANTA is Arista-focused; pytest suites are as good as the engineer who authored them; Cisco pyATS is powerful and famously effort-hungry. The teams with strong NRFU automation are the teams that could already afford test engineers — which is exactly backwards from where the outages happen.
The agent workflow: design in, evidence out
Here's the same six-layer plan, run the agent-first way in a NetPilot network testing lab.
1. State the objective.
"Here's the design: dual-hub DMVPN, OSPF inside the tunnels, HSRP at each branch. Generate the NRFU test plan and execute it. I want interface state, protocol adjacencies, the routing table each branch should hold, a full reachability matrix, failover of hub 1 with convergence time, and a 200 Mbps baseline per branch."
2. The agent derives the plan. It enumerates the checks per layer — which adjacencies should exist, which prefixes belong in which table, which source→destination pairs must pass and which must be blocked — and shows you the plan before running it. Edit it in plain English: "add a case: branch-2 must not reach the management VRF."
3. The agent executes every case. This is where multi-vendor translation earns its keep: the same assertion — "BGP sessions established" — is show ip bgp summary on Cisco, show bgp summary on Juniper, and FRR's vtysh variant, executed in parallel and aggregated into one table. Traffic cases run with iperf3; failover cases shut the hub and measure reconvergence with in-flight probes.
4. You get the report; the CLIs stay open. Every case returns pass/fail with the command output as evidence — the artifact your change board or customer sign-off actually wants. Direct CLI is always available too: SSH into any device and re-run show ip ospf neighbor yourself, or add a check by hand. The agent is for coverage and speed; the CLI is the trust layer.
5. Rehearse it before it counts. Because the lab deploys from the design in ~2 minutes, you can run the NRFU battery against a mirror before running it against the real deployment — which converts NRFU from a deadline-night scramble into something you've already passed once. The same pattern extends to full cutover rehearsal.
Do you still need a test-plan template?
If your deliverable is a document, yes — and the agent's generated plan exports as one (the checks, the expected results, the evidence columns). But the template was never the bottleneck. A template tells you what to check; the 11% problem is running the checks, every time, identically. Generate-and-execute beats fill-in-and-file.
FAQ
What should a network test plan include?
Six layers: interface/physical state, protocol adjacencies, expected routing state, an end-to-end reachability matrix (including must-fail paths), failover cases with convergence measurements, and performance baselines (throughput, latency, jitter, loss). Each check needs an expected result and an evidence field — a check without an expected value is an observation, not a test.
What is the difference between NRFU and UAT for networks?
NRFU (network ready for use) validates the infrastructure — state, routing, reachability, failover, baselines — before production traffic. UAT validates the applications and users on top of it afterward. NRFU is the network team's gate; a clean NRFU report is typically the entry condition for UAT.
Can AI write a network test plan from a design document?
Yes. Give the agent the design (or even the change ticket) and it derives the checkable assertions — expected adjacencies, routing state, reachability pairs, failover expectations — as an editable plan. The differentiating step is that the same agent then executes the plan against real network OS devices and returns the evidence, rather than handing you a document to run manually.
How do I automate NRFU testing without writing pytest or pyATS code?
Use an agent with CLI access to the devices: state the acceptance criteria in plain English and let it run the per-vendor commands, traffic tests, and failover cases, and collect the evidence. If you already maintain ANTA or pyATS suites, keep them — run them against the same lab over SSH, and use the agent for the cases nobody scripted.
Run your next test plan instead of filing it
Describe your design at app.netpilot.io and ask for the NRFU battery — plan, execution, and report in one session, on a lab you can SSH into.
Copy-paste ready: the NRFU / acceptance test plan prompt generates and executes the full battery — paste it into app.netpilot.io and swap in your design.
Related: AI-native network testing lab · Network change validation · Traffic generators for lab testing