When a SCADA system is accepted, the acceptance rests on evidence, and that evidence is produced by a test plan and the test scripts underneath it. Rather than an engineer clicking around and pronouncing the system fine, acceptance testing follows a written plan of documented steps, each with an expected result and a place to record what actually happened. This guide explains how a test plan and its scripts are structured, how a traceability matrix ties them back to the specification, how deviations and witnessing are handled, and how the same scripts serve at both the factory and site tests.
Test Plan & Test Script in one line: A SCADA test plan defines the overall scope, order, and criteria for acceptance testing, and the test scripts under it break the testing into step-by-step procedures, each with an expected result and a pass or fail column. A requirements traceability matrix links every test back to a clause of the functional specification, witness sign-off columns record who verified each result, and the same scripts are typically reused across the factory and site acceptance tests.
A test plan is the top-level document that governs how acceptance testing will be conducted. It defines what will be tested and what will not, the order in which testing proceeds, the environment and prerequisites needed, the roles of the people involved, and the criteria by which the overall test is judged to have passed. The plan is where the strategy lives: it establishes, for example, that certain functions must be proven before others, that a particular class of defect blocks acceptance, and how the whole event is structured. It is the map that keeps a multi-day acceptance test from becoming an unstructured scramble.
Under the plan sit the test scripts, which are the actual step-by-step procedures. A test script - often organized as a set of test cases, each covering one requirement or feature - lists a sequence of numbered steps, and for each step it states the action to perform, the expected result, and a blank for the observed result together with a pass or fail mark. The expected result is stated before the test is run, which is what makes the outcome objective: either the observed behavior matches the pre-written expectation or it does not, with no room for after-the-fact rationalization.
The pass or fail column is the heart of the script's discipline. Because the expected result is fixed in advance, a step passes only when the observed behavior matches it exactly, and any mismatch is a fail that must be dealt with. This structure turns testing from a matter of opinion into a matter of record: at the end, the completed scripts show precisely which steps were performed, what was expected, what was seen, and whether each passed - an evidence trail that anyone can review long after the test is over.
The link between the tests and the specification is made explicit through a requirements traceability matrix. The matrix lists every requirement in the functional specification and, against each, the specific test case or script step that demonstrates it. Its purpose is to guarantee coverage: it makes it immediately visible whether any requirement has no test proving it, and conversely lets anyone starting from a requirement find the exact test that verifies it. A specification clause with no corresponding test is a gap the matrix is designed to expose before it becomes a missed acceptance criterion.
When a step does not produce its expected result, the deviation is handled formally rather than glossed over. The failure is recorded on the script, written up as a deficiency, typically added to the punch list, and given a disposition - fix and retest, accept with a documented concession, or defer as agreed. Retesting a fixed item re-runs the relevant script steps to confirm the correction actually worked, and the record shows both the original failure and the successful retest. This deviation handling is what keeps a test honest: nothing quietly passes, and the history of every problem is preserved.
Witnessing gives the results their authority. Test scripts include sign-off columns where the witness - usually the customer or their representative - initials each step or section to confirm they saw the behavior with their own eyes, not just read a report afterward. On larger tests, additional witnesses such as a safety representative or an independent inspector sign as well. The completed, signed scripts, together with the traceability matrix and the deviation records, form the formal acceptance package that proves the system met its specification under observation.
One of the practical strengths of a scripted approach is that the same scripts can be reused across testing stages. The scripts written for the factory acceptance test - where behavior is proven on the bench with simulated or stimulated inputs - are largely the same scripts re-run at the site acceptance test, where the functions that must be re-demonstrated are proven again with real field wiring, live controllers, and actual communications. Reusing them means a function proven at FAT is re-proven at SAT against the identical expected result, so the two tests share a common backbone and any difference in outcome points cleanly to something that changed by moving to site.
This reuse also keeps the evidence trail coherent. Because a requirement is traced to the same test case at both stages, a reviewer can follow a single thread from the specification clause, through the FAT record where it first passed, to the SAT record where it passed again in the installed environment. The traceability matrix and the scripts thus provide continuous proof across the whole acceptance journey rather than two disconnected sets of paperwork, which is exactly what an auditor or a future maintainer wants to find.
For a system supervised by a cloud SCADA platform such as Merobix, the scripts and the discipline around them are unchanged - the same steps, expected results, pass or fail columns, traceability, and witnessing all apply. What shifts is where the testing happens and who can witness it. Because the supervisory application and its displays are a hosted service reachable from anywhere, much of the configuration testing can be executed in a staging environment that mirrors production and witnessed by a remote reviewer watching the same live screens, while the field-dependent scripts are exercised at each site during the site test. For a fleet of remote locations, the same standard scripts are run site after site, so the traceability and evidence are produced consistently across the whole rollout rather than being reinvented for each location.
A test plan is the top-level document that defines the scope, order, prerequisites, roles, and pass criteria for the whole acceptance test - the strategy for how testing is conducted. Test scripts are the step-by-step procedures beneath the plan, each listing numbered actions with a pre-written expected result and a pass or fail column. The plan governs the event; the scripts are what testers actually execute step by step.
A requirements traceability matrix is a table that links every requirement in the functional specification to the specific test case or script step that demonstrates it. Its job is to guarantee coverage - it makes visible any requirement with no test proving it, and lets anyone starting from a requirement find the exact test that verifies it. It is the tool that ensures nothing in the specification was quietly left untested.
Largely yes. The scripts written for the factory acceptance test are mostly reused for the functions that must be re-demonstrated at the site acceptance test, so a function proven on the bench is re-proven with real wiring, live controllers, and actual communications against the identical expected result. Reusing the scripts gives the two tests a common backbone and keeps a single, coherent evidence trail from the specification through both stages.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.