13. Observing Tests

An important part of the functional testing process is observation. The test procedure initiates an input to the system, and the commissioning provider and test team observe, react to, and document the result. Even if this sounds simple, some issues may cause misinterpretation.

       What Really Happens vs. What You Expected to Happen: In a well-planned test sequence, the commissioning team will initiate the test having anticipated and planned for as many of the potential test outcomes as possible. This allows the team to quickly respond to any problems that occur as discussed in the preceding section. However, it is possible to trick yourself into to seeing what you wanted to see instead of what really happened. Often, there are only subtle differences between the two, but the differences can be the line between a system performing as intended and a system that is wasting energy.

       Repetitive Test Sequences: Many test sequences are repetitive in nature. For example, the testing used for zone controllers on a project may be nearly identical from zone to zone. When performing repetitive test, it is not difficult to miss an obvious problem because you have been lulled in to complacency by numerous successes on the preceding test cycles. In addition, be careful not to confuse the data from one test with the data from another. Working with a team member is one way to combat these sorts of problems if the project economics can sustain it. Switching tasks between team members as you work through the test cycles also helps.

       Checklists and Test Procedures as Guides: Many experienced commissioning providers say that the benefits of a formal checklist or test procedure are realized more during its development cycle than when it is actually used. To develop the checklist or procedure, the test writer must assess the system and consider all of the factors. In doing so, they develop an intimate understanding of the system and how they expect it to work. This understanding can be a greater benefit than the documented procedure. In fact, once experienced commissioning providers are in the field, many use the checklist as a guide and a way to document results, but frequently deviate from the exact process outlined due to the dynamic nature of the field environment.

However, it is important to understand that deviating from a well-planned procedure is not a casual decision, especially for a large system undergoing a complex test or a test with a high element of risk. In these situations, if you think there is a need to deviate from your plan due to a change in the field or an unanticipated result in the test, then you may want to stop the test to re-evaluate and document your new plan.

       Anticipating the Unexpected: Many times, the only real problems during functional testing are the ones you didnít think of as possible prior to their occurrence. Once they occur, they often seem blatantly or even painfully obvious.

Early in the space shuttle program, Barbara Walters was interviewing John Young and Bob Crippen, the astronauts who would be the test pilots for the first flight of the space shuttle Columbia (not the first manned flight, the first flight). In the course of the interview, she asked them if they would be nervous. After a slight pause, John Young, a veteran of flight test and the Gemini and Apollo programs and commander for the mission looked at her and said something like ĎIf you are piloting an untested vehicle on its first test flight and that vehicle contains more propellant than was ever placed on a launch pad before and the vehicle was assembled by the low bidder, and you arenít a little nervous, then you donít fully comprehend the situation[3]

The bottom line is that when we as commissioning providers set out to functionally test the HVAC systems that are built in the modern construction environment, we are testing complex assemblies of interactive components. These systems are designed and assembled by teams of people with conflicting priorities and interests under intense budget and time constraints, often based on specifications and plans that are lacking in detail and contradictory. When considering all of that, if we donít expect a few problems, then perhaps, as John Young said in the story in the side bar, we donít fully comprehend the situation.