Bare-board electrical testing versus functional testing

Bare-board electrical testing and functional testing answer different questions. A bare-board test examines specified electrical properties before components are assembled. A functional test examines the behavior of an assembled circuit or product under defined operating conditions. A report from one stage should not be used as an unspecified substitute for the other.

MicroCraft’s official EMMA measurement-system documentation describes continuity and insulation testing and optional measurement functions. It illustrates why a test specification needs more detail than an equipment name: different modes and settings address different questions. This reference does not imply that our company owns that equipment or performs every listed test.

Define the object being tested

Begin the test plan with the part number, revision, and assembly state. Is the object a bare rigid-flex board, a populated board, or a complete product in its enclosure? Then identify the input data used to create the test and the pass/fail conditions. “Tested” without this context is too broad to be useful in a receiving inspection decision.

A passing result still has a scope

Consider a fictional sensor board that passes its agreed bare-board electrical test. After assembly, the sensor output is incorrect because the loaded firmware uses the wrong calibration data. The earlier test result is not necessarily wrong; calibration behavior was outside its defined scope. The correct response is to trace the failed requirement to the test stage intended to evaluate it.

The reverse distinction also matters. An assembled product performing one demonstration does not establish that every required fabrication acceptance check was completed. Keep the production records and the product-performance evidence separate, then connect them through the part and revision identifiers.

Use an evidence request with five fields

1. Identity: Which part, revision, lot or serial reference does the record cover?
2. Method: What test was run, and which settings define its scope?
3. Reference: Which controlled data and acceptance criteria were used?
4. Result: Is the outcome recorded clearly, including any exceptions?
5. Disposition: Who reviewed a failure, retest, or approved deviation?

For a flexible assembly, also state the mechanical condition used during any project-specific test. A flat condition, an installed condition, and a moving condition are not identical descriptions. Do not infer a lifetime or repeated-bend qualification from a test record that never defined that requirement.

Translate a requirement into an observable result

A test is useful when it connects a requirement to an observable measurement or behavior. For a bare board, the requirement may concern intended connectivity or separation between nets under agreed conditions. For an assembled sensor, it may concern the response to a defined input. Write the expected observation before selecting equipment so that the test method follows the question.

A statement such as all boards electrically tested still needs interpretation. Identify the applicable test-data revision, the characteristics evaluated, and any excluded features. If the record covers only a sample or a specific subset of circuits, state that scope. Do not infer complete coverage from the existence of a passing summary or the name of a test machine.

Functional testing also needs boundaries. A product that powers on and reports a firmware version has demonstrated those operations under that setup. It has not necessarily demonstrated accuracy across the operating range, all communication modes, environmental performance, or every fault response. List the behaviors checked and the conditions used so that a demonstration cannot be mistaken for a comprehensive validation result.

Trace test data back to the released design

Identify the source used to define the intended connectivity. Keep that source under revision control with the fabrication package, and record how the test preparation process uses it. If an independent comparison is part of the agreed workflow, identify both data sets and the disposition of any differences. Two files exported from the same obsolete revision can agree with each other while failing to represent the current design.

For a rigid-flex board, confirm that the test data covers the intended connections across rigid islands and flexible spans. A regional drawing helps a reviewer locate the physical path, but it does not replace the electrical connectivity definition. When a layer name changes between global and local stack views, make the correspondence explicit so that test preparation and design review use the same interpretation.

Use a release record containing the board revision, connectivity-data revision, test-program identity, and approval reference. When the board changes, evaluate whether the test data must change too. A small copper edit, a revised connection, or an altered accessible feature can affect test preparation even when the outline and product name remain unchanged.

Separate access problems from circuit failures

A test result depends on the measurement system making the intended connection to the board. The referenced MicroCraft documentation describes contact checks and optional measurement functions, illustrating why test setup matters. A reported failure should therefore be investigated with attention to the board, test data, contact condition, and measurement configuration rather than assigned immediately to a manufacturing defect.

Document how the flexible board is supported during testing. Record the assembly state and any fixture constraints that affect access or handling. The test should not require uncontrolled folding simply to reach a measurement point. If a special fixture or support is needed, include its identification in the record so that a repeated test reproduces the intended setup.

Do not resolve an access problem by quietly removing the affected feature from the test scope. Record the limitation and obtain a disposition that identifies any alternative evidence. The important question is whether the original requirement is still addressed, not whether the revised test program can produce a passing result.

Use a coverage matrix for an illustrative sensor

The matrix is a planning tool. It does not prescribe universal voltages, resistance thresholds, sample sizes, or test durations. Those values must come from the applicable product requirements and the agreed technical specification. A limit selected only because an instrument supports it is not necessarily suitable for the board or for the decision being made.

Describe functional tests as controlled experiments

For a functional test, record the hardware revision, firmware version, configuration data, supply conditions, connected equipment, and expected sequence. If calibration affects the result, identify the calibration record. A test operator should be able to determine which configuration was evaluated without relying on the memory of the person who prepared the unit.

In a fictional sensor example, define three input conditions and the expected output interval for each. Record the measured outputs against those intervals rather than writing only sensor works. The actual stimulus levels and limits belong to the product specification; this example supplies the record structure, not numerical acceptance values. Add initialization and settling requirements if they matter to the measurement.

When a test includes software commands, keep their sequence and version with the test procedure. A later firmware change may alter timing, output format, or operating modes. Reassess the procedure after such a change instead of assuming that a previous passing record establishes equivalence for the new configuration.

Preserve failures and explain retests

A useful record distinguishes the first result, investigation, corrective action, and retest result. If a contact problem is suspected, record how that conclusion was reached and what changed before retesting. If a board or assembly was repaired, identify the repair and the acceptance checks required afterward. A final pass should not erase the history needed to understand the disposition.

Use consistent identifiers to connect the records. A lot-level fabrication report and an individual assembled-product record may use different numbering systems, so maintain the cross-reference. This becomes important when a later investigation asks which bare-board release and assembly configuration contributed to a particular unit. Traceability should be designed into the process rather than reconstructed after a failure.

Make the delivery statement match the evidence

Request a delivery summary that states what was checked and points to the supporting records. Avoid broad language suggesting that every possible failure mechanism was excluded. A precise statement of the completed test scope is more useful than an unqualified tested label because it allows the receiving team to identify what additional assembly or product-level work remains.

Review any requested certificate or report wording before production. If the wording implies a test, standard, or performance claim that has not been agreed and performed, resolve the discrepancy. Clear documentation protects the technical meaning of a passing result and helps the next team plan its own verification work without duplicating assumptions.

Resolve a test gap before release

Make a list of product requirements and assign the evidence needed for each. If no test or inspection currently addresses a requirement, record the gap explicitly and assign an owner. If two stages address the same issue, establish why both are needed and what each contributes. This review helps avoid both missing evidence and redundant requests.

See our inspection and testing overview and quality documentation guidance. Submit your test and documentation requirements with the inquiry so the scope can be reviewed before an order is finalized.