A building system can be installed, powered on, and communicating with the building automation system without operating as intended. An air handling unit might run while its economizer sequence behaves incorrectly. A pump might start while the lead-lag changeover fails. A temperature sensor might display a believable reading while reporting a value that does not match actual conditions.
Functional performance testing helps commissioning teams identify these gaps before they become operating problems. It provides a structured way to demonstrate how equipment and systems respond under defined conditions and compare the results with project requirements.
Successful testing depends on preparation, clear procedures, and reliable documentation. Bluerithm helps teams organize this work, including using AI to create functional performance tests, or FPTs, that commissioning professionals can review and refine for their projects.
What Is Functional Performance Testing?
Functional performance testing verifies that building equipment and systems operate according to the applicable design requirements and approved sequences of operation. Depending on the commissioning scope, testing may address normal operation, operating mode changes, alarms, interlocks, and responses to specified abnormal conditions.
The distinction between startup and functional testing matters. A manufacturer’s startup process may confirm that a unit can operate and establish initial settings. An FPT examines whether the installed system performs its intended functions within the building’s operating environment. Both activities contribute to project delivery, but they answer different questions.
For example, confirming that a supply fan starts does not demonstrate that an air handling system maintains the required pressure as demand changes. Functional testing follows the operating sequence and records the system’s response to the conditions being tested.
Start With the Project Requirements
An effective FPT begins with a clear understanding of the intended operation. Review the owner’s project requirements, basis of design, specifications, approved submittals, and current sequences of operation as applicable to the scope.
Use those documents to establish what each test must demonstrate. Identify the relevant operating modes, setpoints, time delays, interfaces, and acceptance criteria. Resolve conflicting instructions with the appropriate project team members before issuing the procedure for use.
A reusable template can provide a consistent starting point, but every test needs a project-specific review. Similar equipment can have different control strategies, accessories, and operating requirements. A test written for one air handling unit may omit important functions on another.
Clear references also make later review easier. When a test step identifies the sequence paragraph or specification requirement it verifies, reviewers can understand the reason for the step and evaluate whether its expected result is appropriate. Commissioning documentation should reflect the requirements and review processes established for the particular project.
Confirm Readiness Before Scheduling Tests
Scheduling a test does not establish that the system is ready. Incomplete installation, unfinished controls programming, or missing balancing information can turn a planned verification session into troubleshooting work.
Establish the prerequisites for each test and confirm their status before mobilizing the testing team. Depending on the system and project, these may include completed installation checks, startup records, controls point verification, sensor calibration, applicable balancing work, and resolution of issues that would prevent meaningful testing.
Coordinate the people and access required as well. Identify who will operate equipment, make authorized controls changes, witness results, and address problems. Agree on notifications and operating restrictions, particularly in occupied buildings where testing can affect occupants or ongoing operations.
If a prerequisite remains incomplete, document what is missing and how it affects the test. Distinguish work that is ready for verification from work that needs additional preparation so the project team can make realistic scheduling decisions.
Write Test Steps That Produce Clear Evidence
A useful FPT tells the testing team how to establish a condition, what action to take, what response to expect, and what information to record. Broad instructions such as “verify proper operation” leave too much room for interpretation.
For each test sequence, include these elements:
- Initial conditions and required system configuration.
- The action or approved method used to initiate the condition.
- Expected equipment and controls responses.
- Acceptance criteria taken from the project requirements.
- Fields for actual observations, measurements, and results.
- Instructions for restoring the system after testing.
Separate commands from proof of operation. A building automation system command showing that a valve should be open is different from evidence that the valve moved and the system responded appropriately. The procedure should identify the observations or measurements needed to support its conclusion.
Include timing where it matters. If a sequence requires a response after a defined delay, record that requirement and the observed response. Where criteria are missing, request clarification instead of inserting an assumed tolerance or delay into the test.
Use AI to Create FPTs in Bluerithm
Writing functional test procedures can take significant preparation time, especially when a project includes many equipment types and operating sequences. Bluerithm’s AI form-building tools can generate functional performance tests, including test procedures and expected results, based on your instructions.
Commissioning teams can use this capability to create a draft FPT, then review and edit the content for the actual system. Providing clear context helps focus the draft: describe the equipment, relevant operating modes, required functions, and the structure you want the form to follow.
For example, a starting instruction could be:
Create a draft functional performance test for a variable air volume air handling unit. Organize the form into prerequisites, occupied operation, unoccupied operation, economizer operation, alarms, and restoration. Include test actions, expected results, actual results, and pass/fail fields. Use only the project requirements I provide for setpoints, delays, and acceptance criteria. Flag missing information for review.
Supply the relevant project details when using an instruction like this. Treat the generated form as a draft: check coverage, technical accuracy, acceptance criteria, and test methods against the approved documents before use.
AI can accelerate form creation. The commissioning team remains responsible for approving the procedure and verifying actual system performance in the field.
Execute Tests and Record Actual Results
Before starting, confirm that participants understand the procedure and that the approved prerequisites are satisfied. Record the equipment identification, date, participants, document revision, and relevant operating conditions so the results have a clear context.
Follow the approved test steps and record what actually happens. A pass/fail selection is useful, but supporting observations explain the result. Where applicable, capture measured values, response times, trend information, screenshots, or photos that demonstrate the behavior being evaluated.
Suppose a test examines lead-lag pump changeover. The record should explain the initial operating state, the approved condition used to initiate changeover, and the observed response. That creates a more useful record than a checkmark beside “changeover verified.”
Document limitations as well. If weather, building load, equipment availability, or another condition prevents a meaningful test, identify the affected step and the follow-up required. Keep deferred and blocked tests distinguishable from tests that passed.
Connect Failed Tests to Issues and Retesting
A failed test needs an actionable issue record. Identify the equipment, test step, expected behavior, actual behavior, and supporting evidence. Assign responsibility and track the corrective work so the team can determine when retesting is appropriate.
For example, “economizer problem” provides little direction. A clearer observation would explain the test condition, the damper command, the observed position, and how that response differed from the approved sequence. Keep observations separate from an unconfirmed diagnosis.
After corrections, repeat the affected test steps and evaluate whether related functions also need verification. Preserve the original failure and subsequent retest results so the record explains how the issue was resolved.
Bluerithm connects equipment with tests, issues, and documentation, helping teams keep the verification record together. Its issue tracking supports assignments, photos, comments, due dates, and issue histories, while project progress views help teams monitor testing status.
Plan for Restoration and Deferred Testing
Test completion includes returning the system to its intended operating condition. Temporary overrides, simulated inputs, disabled schedules, and changed setpoints can affect building operation if they remain in place.
Include restoration checks in the procedure and confirm that authorized personnel remove test conditions. Record the final operating state and communicate any remaining restrictions to the appropriate team members.
Some verification must occur later because the necessary seasonal or operating conditions are unavailable. Track deferred work with its reason, required conditions, responsible parties, and planned follow-up. A clear outstanding-work record helps the owner understand what has been demonstrated and what still requires confirmation.
Build a Useful Closeout Record
Functional performance testing documentation should help the owner understand what was tested, the results, and any remaining limitations. Organize completed procedures, supporting evidence, issue resolutions, retest records, and deferred activities so the information can be located and reviewed.
Use consistent equipment names throughout the records. A test labeled with one equipment tag and an issue recorded under another can create avoidable confusion during closeout and future troubleshooting.
Bluerithm supports digital commissioning forms and reporting connected to project data, helping teams assemble testing information as work progresses. Maintaining organized records throughout the project reduces the amount of reconstruction needed at closeout.
Manage Functional Performance Testing With Bluerithm
Reliable FPTs begin with project requirements and produce evidence of actual system behavior. Clear procedures, verified prerequisites, documented results, and tracked retesting give commissioning teams a stronger basis for evaluating performance.
Bluerithm supports that workflow from test creation through closeout. Teams can use AI to draft FPTs, refine procedures for their projects, and manage testing alongside equipment records and issues.
For additional help building repeatable commissioning processes, download the Commissioning Firm Standardization Toolkit below.
Start a 30-Day Free Trial to bring your testing workflow into one platform.
