Functional testing — BuildingCX

A pass that means what it says.

A test result derives itself here instead of getting typed in.

01Built once, reused often

A test sequence is written once and run against every matching unit.

Write the step order and expected values for one air handler and reuse it against every AHU on the job. Equipment-specific results fill in per unit; the sequence itself stays untouched.

Screenshot — a reusable test sequence applied to multiple AHUs

02No silent averaging

The overall result is computed, not chosen.

One failed step fails the test — the overall pass/fail isn't a judgment call at the end, it's derived from every step's own result. A reviewer can see exactly which step is holding the sequence back.

Screenshot — one failed step driving an overall fail result

03Attributed, not anonymous

Every step result records who entered it.

Each pass, fail or partial is stamped with who recorded it and when, so looking back at a sequence shows exactly who ran which step.

Screenshot — a step result with who recorded it and when

Questions about functional testing

Can we write our own test sequences?

Yes — build a sequence once per equipment type and reuse it across every matching unit on the project.

What happens when a step fails?

You can raise an issue directly from the failed step, carrying the equipment tag and reading with it, and re-test once resolved.

Do results feed the tracker automatically?

Yes — a recorded step result updates the tracker the same way a submitted checklist does. There's no separate entry.

Can we see who recorded each result?

Yes — every step result is attributed to the person who entered it, with a timestamp.

One failed step fails the test.