A conditional test step can be correct when it runs and still leave a product inadequately tested because it never runs. Review the precondition that selects the step, especially when one sequence serves several PCB variants. A skipped step needs an intended reason that can be traced to the product configuration.
NI’s TestStand flow-control guidance describes preconditions that allow a step to execute only when specified conditions are met. That mechanism provides flexibility, but the expression and its input values determine the actual coverage.
Map product requirements to conditions
List each optional or conditional measurement and the product states that require it. Include variant, hardware revision, fitted options, and prerequisite outcomes where relevant. Avoid treating an empty configuration field as equivalent to a deliberate “feature absent” state.
Identify the source of every variable used in the expression. A value copied from an earlier unit or retained in station state can select the wrong path. Capture the resolved configuration at the beginning of the attempt and keep it associated with the result.
Exercise the decision boundary
| Case | Expected behavior to verify |
|---|---|
| Feature present | Required measurement executes |
| Feature absent | Measurement is intentionally omitted |
| Configuration unknown | Coverage uncertainty becomes visible |
| Prerequisite fails | Dependent step follows the defined policy |
Use deliberately different product configurations in validation. Running the same nominal board repeatedly can confirm execution stability without ever exercising the alternate branch. Inspect the recorded step status and reason, not merely the overall test result. Include the evaluated inputs so a later reviewer can explain why that branch was selected.
Review compound expressions
- Translate the expression into a plain-language requirement.
- Check each input’s type and allowed values.
- Test representative true, false, and invalid cases.
- Confirm the resulting coverage in the report.
- Keep the cases with the recipe release evidence.
Pay attention to operator grouping and negation. A condition intended to apply to two variants may accidentally apply only when an unrelated flag is also set. A small truth table is often clearer than reading a long expression inside a graphical editor.
When requirements change, update the coverage map and its validation cases together. A newly introduced variant should not inherit an old skip decision simply because its identifier was absent from an earlier list.
The released sequence should distinguish intentional non-applicability from missing information and aborted execution. This makes a passing result meaningful: the checks required for that particular board configuration actually ran, and omitted checks have a documented basis.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist