Automated, Semi-Automated or Manual Tests: Choosing the Right Evidence

An available reading is not always a valid test

A controller can read a signal automatically. Does that mean it can test the associated function at any moment?

Not necessarily. A reading taken before a command, without the required load, or in the wrong equipment state may answer a different question from the one the diagnostic model needs.

iTech's documentation distinguishes fully automated, semi-automated and manual tests. The useful distinction is not simply how modern the test equipment looks. It is what must happen before trustworthy evidence becomes available, and who must obtain it.

Those practical requirements should be part of the diagnostic application from the outset.

Fully automated: evidence available without a special operating state

The iTech fully automated test guide describes tests the system can perform while switched on, without a special state or operator intervention. Its examples include detecting power-on status and the presence of connected equipment.

This can make a useful observation available without asking a technician to prepare another test. However, the observation still has a defined scope.

A connection-presence indication does not, by itself, demonstrate that every function of the connected assembly works. A power-on indication does not establish that every downstream supply remains within specification under load.

Nor does the availability of a signal mean that a particular installation already has the necessary interface configured. Confirm what evidence the actual diagnostic application can obtain; do not assume that every controller value is automatically accessible to iTech.

Semi-automated: the measurement needs the right conditions

The semi-automated test guide describes tests that require a particular system state or operator action before a measurement can be taken. The documented example requires an operator command before observing the relevant response.

The result may come from a sensor or controller. What prevents the test from being fully automated is the prerequisite, not necessarily the measurement.

For an illustrative actuator system, a feedback signal might be readable at any time, but a response test might require an authorized movement command first. “Feedback inactive” before the command is not equivalent to “feedback failed to activate after the specified command.”

A useful procedure therefore distinguishes:

• The operating state required before the test.
• The action needed to establish that state.
• The observation to collect and its acceptance criteria.
• The conditions that make the observation invalid or unavailable.

These are engineering review questions, not a claim that iTech automatically discovers or enforces every prerequisite.

Manual: the technician supplies an observation or measurement

The manual test guide describes checks that cannot be obtained through the available sensor or software readings. Its examples include visual checks of mechanical operation and a terminal-voltage measurement.

Here, “manual” describes how evidence is obtained in the application. It does not mean that the test must be imprecise, or that a human can judge the result without a defined requirement.

A technician may need a specified instrument, an accessible observation point, suitable qualifications and a clear interpretation rule. A visual check also needs a defined target: seeing an indicator change is not always the same as observing the mechanism itself.

Manual evidence can distinguish causes that the installed instrumentation cannot separate. Conversely, an observation that is unsafe, inaccessible or outside the technician's authority is not made available merely by adding it to a model.

Compare the evidence, not just the automation label

Illustrative example only—not an installation description or an equipment procedure. Consider a modeled actuator with a controller indication and a mechanism whose movement can be observed under an approved test.

Evidence opportunity	Possible test category	What needs review
An existing interface reports that an assembly is connected, with no special preparation.	Fully automated, if it meets the documented conditions.	What does “connected” actually establish, and how reliable is the indication?
A controller reports feedback after an operator establishes the required commanded state.	Semi-automated.	Was the correct state established, and was the response assessed against the specified requirement?
A technician observes whether the mechanism reaches its required position.	Manual, where no suitable automatic reading is available.	Is the observation safe, accessible and sufficiently precise for the modeled conclusion?

These observations are not interchangeable. Connection presence, reported feedback and observed mechanical position address different claims.

The modeling-tests guide makes a related distinction: an indicator can be used as evidence of an output's status, but that is not the same physical observation as measuring the output itself. The modeler must justify the relationship between the indication and the function being inferred.

For the wider issue of inference boundaries, see What a Passing Test Really Tells You.

Define pass and fail against the specification

Whichever category supplies the observation, the result needs a clear interpretation.

The test-procedures guide explains that reporting good or bad does not limit the technology to Boolean physical measurements. A measured value or performance curve can be judged against specified tolerances.

“The equipment still operates” is therefore not an adequate substitute for “the tested requirement is met.” An out-of-tolerance value can be a bad result even while the overall equipment continues working.

Likewise, if the required operating condition was never established, do not substitute an assumed pass or fail. Follow the approved procedure for unavailable evidence or escalation rather than claiming a result that was not obtained.

Include preparation effort and validate the interpretation

An automatically collected result may be convenient but provide little new discrimination. A manual observation may be more informative but require access, preparation and specialist equipment.

iTech's test time/cost documentation identifies time and cost as inputs to test-strategy calculation. The practical comparison should include realistic preparation effort rather than ranking tests solely by their automation category. For more on that distinction, see Why Fewer Tests Do Not Always Mean Faster Repairs.

Before field use, review the modeled tests with the system expert, exercise simulated troubleshooting sessions and validate against real equipment where feasible and safe, as described in the model-validation guide.

Check not only whether a reading can be collected, but whether its interpretation clears or implicates the correct modeled functions. Test design never authorizes bypassing interlocks, operating unsafe equipment or performing live measurements without approved controls.

Choose the observation that supplies justified evidence under achievable conditions—not simply the one carrying the most automated label.