Functional Testing Is Not Watching the Contractor Push a Button

Here is a scene that plays out constantly. The CxA arrives. The controls technician is already at the workstation. The technician says: "Okay, so here's the AHU. Watch — I'll put it in occupied mode." The graphic changes. Fan starts. Damper opens. "See, economizer's working." The CxA writes Pass.

Nothing about that was a test. It was a demonstration, performed by the party whose work is being evaluated, of a state they selected in advance because they knew it worked.

A functional performance test is close to the opposite of a demonstration. You are trying to make the system fail, and recording what it does when it does. If your test procedure never produces a failure, it is not sensitive enough to detect one.

The four things a real FPT does

1. It drives the system through every state in the approved sequence, including the ugly ones. Not just occupied and unoccupied. Warm-up and cool-down modes. Optimum start. Unoccupied setback with the zone drifting past the low limit. Morning warm-up transition. Economizer high-limit changeover in both directions with the setpoint straddled. Minimum outdoor air at design and at part load — which on a VAV system with a fixed minimum damper position is where the ventilation code violations live and nobody looks.

2. It injects failures. This is the part that separates real testing from everything else, and it is the part that gets cut first because it takes time and makes contractors nervous. Pull the outdoor air sensor and confirm the system fails to the safe state rather than to whatever the controller's default happens to be. Simulate a fan status failure and confirm the alarm and the interlock. Force a smoke detector and confirm the shutdown and confirm what happens on reset. Drop the differential pressure signal. Take a pump offline and watch the lead/lag/standby actually rotate — the number of standby pumps that have never once started in a building's life is remarkable.

3. It records values, not verdicts. Every step produces a number and a time. Expected discharge air temperature 55°F; observed 58.4°F at 14:32; deviation noted; retest after loop retuning; observed 55.1°F at 09:15 the following Tuesday. A row that says "Pass" and nothing else is unfalsifiable and therefore worthless as evidence.

4. It trends across time, not moments. Many of the most expensive faults in a building are invisible at any single instant and obvious across eight hours. Two air handlers serving adjacent zones fighting each other. A hot water reset curve that is fine at 40°F outdoor and nonsense at 55°F. A static pressure reset that never actually resets because one rogue zone box is stuck at 100 percent and holds the whole system at maximum. Simultaneous heating and cooling that only shows up in the shoulder hours. You find these by trending, not by visiting.

Who touches the keyboard

Small procedural point, large consequence: the CxA should be specifying the commands and reading the results, and should be able to see the raw points, not just the graphic.

Graphics lie. Not usually maliciously — a graphic is a rendering of what the programmer believed the system does. I have seen a graphic showing a damper at 20 percent minimum position while the actual analog output point sat at 0 percent, because the graphic was bound to the setpoint rather than the output. The building had been running with zero mechanical ventilation for fourteen months. The startup report said "Pass."

Ask for the point list. Look at the trends. Put a sensor next to the sensor.

Test at the boundaries, not the middle

Systems mostly work in the middle of their range. That's what they were designed and tuned for, that's what got demonstrated during startup, and that's where nothing interesting happens.

Faults live at the boundaries and in the transitions. Changeover points. Staging thresholds. The moment a chiller has to add a stage. Minimum turndown, where the boiler short-cycles and the control valve hunts. The first ten minutes of morning warm-up. Design day conditions, which is why seasonal testing exists and why dropping it — the single most commonly dropped scope item in commissioning — is such a serious omission. A building tested only in September has been tested at the one condition that stresses nothing.

The honest objection

A contractor reading this will say: this takes forever, it disrupts the schedule, you're testing during a period when the building is being handed over and everyone is under pressure, and half your "failures" are just incomplete work that would have been finished anyway.

Some of that is fair. Which is the argument for the CxA being involved from design, for prefunctional checklists being genuinely completed and verified before functional testing starts rather than signed in a stack at the end, and for functional testing being a scheduled activity with duration in the construction schedule rather than a thing that gets squeezed into the two weeks before CO.

That is a project-management argument, and it's a real one. It is not an argument for demonstrating instead of testing. It's an argument for planning the testing. The version where nobody plans it and then it doesn't happen and everyone signs anyway — that's the version we've mostly settled on.

The minimum I'd accept

If you are an owner and you read nothing else here, require these four things in the contract and withhold final payment until you have them:

• Test scripts written against your project's approved sequence of operations, with the sequence attached
• Recorded values in every test step, not pass/fail marks
• At least one documented failure-mode test per major system — sensor failure, status failure, power interruption recovery
• Trend logs spanning a minimum of one full week of occupied operation after all issues are closed

Those four are cheap to specify, hard to fake, and would eliminate most of the drive-by product from your project by themselves.