Skip to main content

The verification run

A verification run is what Test Services does when you start one or more tests: it exercises part of your OpenLab CDS deployment and records whether it behaved correctly. This page explains what a run is and what happens inside one, so the progress you see on screen and the report you keep afterwards make sense. To start a run, see Run verification tests.

What a run is​

When you select tests and start them, Test Services performs each test as a sequence of timed steps and records a result for each. As a run proceeds, the steps appear on the home page, each marked as it starts and again when it completes. If a step fails, that test stops at the failing step and is reported as Failed with an explanation; any other tests you selected continue to run. You can stop the whole run yourself while it is in progress; see Stop a running test.

Different tests do very different work. Some inspect the installed software or the security configuration and complete quickly. The Workflow Test does the most: it drives a complete, automated data acquisition through OpenLab CDS and then checks the outcome. Because it is the most involved, it is the clearest illustration of what a run does.

What the Workflow Test does behind the scenes​

The Workflow Test verifies the full acquisition path without needing a live instrument or live samples. To do that, it prepares everything it needs and cleans up after itself, so you do not have to set anything up by hand.

  • It prepares its own project. Test Services creates a dedicated OpenLab CDS project the first time it is needed, or reuses it if it already exists. The project is configured automatically, including enabling the audit trail for methods and sequences, so the run is recorded the way a compliant workflow would be.
  • It prepares its own virtual instrument. Test Services creates a virtual instrument bound to the local machine and configures it to replay canned data rather than acquire from hardware. This lets the test run the same software path a real acquisition uses, with a known, repeatable data set.
  • It runs an acquisition and checks the outcome. The test submits a prepared sequence, acquires the data, and verifies that the software produced the expected results. The progress on screen tracks the run, including which sample is being processed.
  • It records the result as evidence. The result files and the report are stored in the OpenLab storage backend, and the run is recorded so it can be reviewed later.
note

If you delete or change the project or virtual instrument that Test Services created, it recreates and reconfigures them on the next run. They are managed by Test Services and are not meant to be edited by hand.

Where a run leaves its results​

Every run produces results that outlive it. Each test's report and the run's overall Summary report are written to the OpenLab storage backend and listed in the execution history, so a run from last week reads the same as one from today. The overall result is conservative: a single failed test makes the whole run fail, so a passing Summary report is a strong statement about the deployment. For how the overall result is decided and what the report contains, see About the Summary report.

The run is also recorded in the OpenLab CDS activity logs, giving an independent trail of what Test Services did. For the meaning of each individual result value, see Test result statuses.

See also​