An integrated systems test (IST) checks whether connected systems work together as intended under defined conditions. A good test narrative turns the design intent and cause-and-effect logic into a sequence that a test team can follow, witness and record.
The narrative is more than a list of tests. It explains what the test is meant to prove, what must be ready before it begins, how each scenario will be run and what evidence will show whether it passed.
Start with the objective
State the purpose of the test in plain language. For example:
Demonstrate that, on loss of the normal electrical supply, the specified systems respond in the sequence and within the limits defined by the approved project documents.
The exact objective will depend on the system. Avoid vague wording such as “check emergency operation”; define which event is simulated, which systems should respond and what outcomes matter.
Define the test boundaries
Identify the systems and interfaces included. These might include a fire alarm, building management system, ventilation plant, dampers, emergency power or other connected equipment. Record what is outside the test as well, so nobody assumes it has been covered.
Before testing, identify the approved source documents: relevant cause-and-effect matrices, control descriptions, drawings, sequences of operation and commissioning records. Note the revision of each document used.
Write scenarios as executable steps
For each scenario, include:
- Prerequisites: required equipment status, permits, isolations, personnel and safety controls.
- Initial condition: the system state before the initiating event.
- Action: exactly what the test team does or simulates.
- Expected response: the observable response from each relevant system.
- Timing or limits: any project-defined delay, response time or tolerance.
- Evidence: what is observed, measured, recorded or captured.
- Reset: how the system is safely returned to normal.
A witness should be able to follow the steps without having to infer missing actions or expected results.
Make pass and fail criteria clear
Use measurable acceptance criteria wherever the project defines them. Specify the required indication, equipment response, sequence, timing or status. If a result falls outside the criterion, record it as a deviation or test failure and agree how it will be assessed and retested.
Do not invent tolerances in the narrative. If a limit is not stated in the approved requirements, resolve that gap before the test.
Plan for safe testing
An integrated test can affect multiple systems at once. The narrative should identify hazards, affected areas, temporary restrictions, communications, abort conditions and responsible people. It should also state how any simulated signals or temporary overrides will be controlled and removed.
The HSE describes commissioning as a planned progression of checks and highlights the importance of written commissioning procedures, suitable precautions and records.1 The precise process for any project should follow its risk assessments and approved project arrangements.
Close the loop
Finish each scenario with a result, evidence reference, outstanding issue and retest status. Keep the final narrative aligned with the system actually installed. If a test exposes a design or configuration change, assess and document it through the project’s change-control process.
A strong IST narrative makes testing more repeatable and makes the results easier to review. It helps the test team and witnesses share the same understanding of what is being demonstrated.