From Test Requirement to Defensible Experimental Evidence

The Complete Chain

Physical testing is not an isolated activity; it is a chain of decisions and actions that begins with an engineering requirement and ends with an engineering conclusion supported by evidence. Each link in the chain depends on the links before it and supports the links after it. A weakness at any link — an ambiguous requirement, a poorly defined objective, an unrepresentative fixture, an uncalibrated sensor, an uncontrolled test execution, an unquantified uncertainty, an unsupported interpretation — compromises the entire chain and the conclusion it produces. The engineer's responsibility is to design, execute and verify the entire chain, not just the part they find interesting. This article presents the chain as a sequence of stages. Each stage has a purpose, an output and a set of things that can go wrong. The stages are not independent: the test objective is defined by the requirement; the configuration is chosen to meet the objective; the fixture is designed to provide the boundary conditions; the load introduction applies the load the analysis assumed; the instrumentation measures the quantities the objective requires; the calibration ensures the measurements are traceable; the execution follows the plan; the data QA verifies the data; the uncertainty bounds the result; the interpretation derives meaning from the data; the correlation compares the result to the analysis; and the engineering conclusion answers the original question. Break any link, and the chain fails.

DESIGN THE TEST TO ANSWER THE QUESTION — THEN ENSURE THE MEASUREMENT SYSTEM IS CAPABLE OF SUPPORTING THE ANSWER.

The Workflow as a Sequence

The complete workflow from requirement to engineering conclusion is presented below as an ordered sequence. Each step is a distinct engineering activity with its own output and its own potential failure modes. The engineer should treat each step as a decision point, not a procedural checkbox.

1. 01 REQUIREMENT — Establish the engineering question that the test must answer, including the decision the result will support and the consequence of getting it wrong
2. 02 TEST OBJECTIVE — Translate the requirement into a specific, measurable test objective: what will be measured, on what article, under what conditions, to what accuracy
3. 03 CONFIGURATION — Define the test article configuration, the boundary conditions, the environment and the loading that the test will apply, matching the analysis assumptions
4. 04 FIXTURE — Design or select a fixture that provides the intended boundary conditions with adequate stiffness, alignment and repeatability, and verify its dynamics where relevant
5. 05 LOAD INTRODUCTION — Define how the load is applied to the article: the actuator, the load path, the distribution, the rate and the control method, ensuring the load enters the article as the analysis assumed
6. 06 INSTRUMENTATION — Select and place sensors to measure the quantities the objective requires, with adequate range, resolution, frequency response and spatial coverage
7. 07 CALIBRATION — Verify that every sensor and channel is calibrated, in date and correctly configured, and that the calibration uncertainty is known and documented
8. 08 TEST EXECUTION — Run the test according to the plan, monitoring for anomalies, recording all channels and events, and documenting any deviations from the plan
9. 09 DATA QA — Verify the recorded data: check for clipping, aliasing, noise, channel dropouts, timing errors and plausibility before any analysis is performed
10. 10 UNCERTAINTY — Assess and document the measurement uncertainty, identifying the significant contributors and reporting the result with a defensible uncertainty bound
11. 11 INTERPRETATION — Derive engineering meaning from the data: what does the measured response tell us about the structure, and does it answer the test objective
12. 12 CORRELATION — Compare the test result to the analysis prediction: do they agree, where do they differ and what do the differences tell us about the analysis and the structure
13. 13 ENGINEERING CONCLUSION — Draw the engineering conclusion that the evidence supports, stating what the test demonstrated, what it did not demonstrate and what the remaining uncertainties are

01 Requirement: Establishing the Engineering Question

The chain begins with a requirement — the engineering question that the test must answer. The requirement is not "test the wing" or "verify the bracket"; it is the specific question that an engineering decision depends on. "Can this wing sustain the design ultimate load with adequate margin?" "Does this bracket fail by yielding or by fastener pull-out under the worst-case load case?" "What is the fatigue life of this joint under the service spectrum, and where does it crack?" The requirement defines what is at stake: the decision the result will inform, the consequence of a wrong answer and the level of confidence the answer must carry. A vague requirement produces a vague test. If the requirement is "check the structure is strong enough", the test designer has no basis for choosing the load, the article, the instrumentation or the acceptance criteria. The engineer should push the requirement to be specific: what load, what condition, what failure mode, what margin, what confidence. If the requirement cannot be made specific, the test is not ready to be designed.

02 Test Objective: Translating Requirement into Measurement

The test objective is the translation of the requirement into a concrete, measurable test plan. It specifies what will be measured (load, strain, displacement, acceleration, cycles to failure, crack growth rate), on what article (which configuration, which material condition, which build standard), under what conditions (temperature, humidity, boundary condition), and to what accuracy (the required uncertainty). The objective is the bridge between the engineering question and the physical test — if the objective does not address the requirement, the test result, however well-executed, does not answer the question. The objective should state what the test is designed to demonstrate and what it is not designed to demonstrate. A static strength test demonstrates load capacity under a defined condition; it does not demonstrate fatigue life. A fatigue test demonstrates life under a defined spectrum; it does not demonstrate static strength margin. Being explicit about the scope prevents the test result from being over-interpreted — used to support conclusions it was not designed to support.

03 Configuration: Matching the Analysis Assumptions

The test configuration — the article, the boundary conditions, the environment and the loading — must match the assumptions of the analysis it is intended to validate or the service condition it is intended to represent. If the analysis assumes a simply-supported beam, the test fixture must provide a simply-supported boundary, not a somewhere-between-fixed-and-free boundary. If the analysis assumes ambient temperature, the test at elevated temperature cannot be directly correlated. If the analysis assumes a pristine article, a test on an article with manufacturing deviations tests the deviation, not the nominal design. Every difference between the test configuration and the analysis assumption or the service condition is a source of correlation discrepancy or interpretation error. The engineer should document the configuration, state how it matches the analysis or service condition and identify any differences. If the differences are intentional (to test a specific condition), they should be stated. If the differences are compromises (because the ideal configuration was not achievable), they should be assessed for their effect on the result.

04 Fixture: Providing the Boundary Condition

The fixture provides the boundary condition — the support, restraint and load transfer that the article sees in the test. A good fixture is stiff enough that its deformation does not materially change the article's response, rigid enough that its modes do not enter the test frequency band (for dynamic tests), and repeatable enough that the same article tested twice in the same fixture produces the same result. The fixture design is a structural design problem in its own right, and it should be treated with the same rigour as the test article design. The fixture should be verified before the test. For static tests, a check that the fixture stiffness is high relative to the article stiffness confirms that the boundary condition is approximately rigid. For dynamic tests, a bare-fixture modal survey confirms that no fixture modes are in the test band. For all tests, a repeatability check — loading the fixture without the article, or repeating a low-level test — confirms that the fixture settles consistently. A fixture that has not been verified is an assumption, not a boundary condition.

05 Load Introduction: Ensuring the Load Enters as Assumed

How the load is introduced into the article determines the load path and the stress distribution at the entry point. If the analysis assumes a uniformly distributed load, a single-point introduction produces a different stress field. If the analysis assumes a pinned connection, a bolted connection with finite stiffness introduces moments that the analysis did not assume. If the analysis assumes axial load, an off-axis introduction introduces bending. The load introduction must be designed to match the analysis assumption, and where it cannot match exactly, the difference must be understood and its effect assessed. The load introduction includes the actuator, the load cell, the connection to the fixture, the fixture-to-article interface and the local load distribution. Each element has stiffness, alignment and load capacity. The engineer should trace the load from the actuator to the article and confirm that at each stage the load is transferred as intended. Load introduction errors are common and often subtle — a slightly misaligned actuator introduces a moment that changes the stress distribution, and the only way to detect it is to measure the strain at the entry point and compare to the prediction.

06 Instrumentation: Measuring What the Objective Requires

The instrumentation plan is determined by the test objective: what quantities must be measured, at what locations, with what range, resolution and frequency response. The plan should be derived from the question, not from habit. If the objective is to identify the failure location, strain gauges must be at the candidate critical locations predicted by analysis, plus a spread of gauges to catch unexpected locations. If the objective is to measure the mode shape, accelerometers must be at enough locations to spatially resolve the modes of interest. If the objective is to measure the crack growth rate, the crack monitoring method (potential drop, visual, AE) must have the resolution to detect the crack at the size of interest. Instrumentation that is insufficient — too few channels, wrong locations, inadequate range or resolution — produces a test that cannot answer the question. Instrumentation that is excessive — too many channels, redundant locations — adds cost, complexity, mass loading and data volume without improving the answer. The plan is an engineering decision: the right measurements, at the right locations, with the right sensors, and no more.

07 Calibration: Ensuring Traceable Measurements

Calibration ensures that the sensor output is related to the physical input by a known, traceable sensitivity. Before the test, every channel should be verified: the sensor is in calibration and in date, the sensitivity is correctly entered into the DAQ, the excitation (if required) is correct, and the signal conditioning is configured for the sensor type. A pre-test check — applying a known input or comparing against a reference — confirms that the channel is functioning and that the configured sensitivity produces the correct reading. Calibration is not just a paperwork exercise. A sensor with an expired calibration may have drifted; a channel with the wrong sensitivity entered produces a plausible but wrong reading; a sensor with the wrong excitation may not function or may have altered sensitivity. These errors are not visible in the recorded data — the data looks plausible — and they are only caught by systematic pre-test verification. The calibration records, the pre-test check results and the channel configuration should be part of the test documentation.

08 Test Execution: Following the Plan and Capturing Deviations

Test execution is the physical running of the test. The engineer follows the planned sequence, monitors the channels for plausibility, watches for anomalies and records everything. Any deviation from the plan — a different load sequence, an environmental excursion, a sensor that stops working, a fixture that settles unexpectedly — should be recorded and its potential effect on the result assessed. A deviation does not automatically invalidate the test, but an undocumented deviation means the evidence cannot be fully trusted because the actual test conditions are not known. Execution discipline matters because the test is a one-time event for that article under those conditions. A measurement missed during the test cannot be recovered. An anomaly not investigated at the time cannot be diagnosed after the article is removed from the fixture. The engineer should maintain a test log — a real-time record of what happened, when, and what was observed — that supplements the recorded data and provides the context for interpretation.

09 Data QA: Verifying the Data Before Analysis

Before any analysis or interpretation, the recorded data should be quality-assured. Check for clipping — any channel that reached the ADC range and saturated has lost data. Check for aliasing — if the anti-alias filter was not correctly set, the data may be corrupted. Check for channel dropouts — any channel that went to zero, went to full scale or produced a flat line may have failed. Check for noise — compare the signal to the noise floor measured before the test. Check for timing — in multi-channel data, verify that the inter-channel timing is consistent with the acquisition architecture. Check for plausibility — does each channel's response make physical sense given the load and the article? Data QA is a gate: data that fails QA should not be analysed as if it were valid. A clipped channel, an aliased signal or a failed sensor produces data that looks like a measurement but is not. Analysing it produces a result that looks like a conclusion but is not. The engineer should identify and flag any data quality issues before interpretation and assess whether they affect the ability to answer the test objective. Sometimes a single failed channel can be worked around; sometimes it means the test must be repeated.

10 Uncertainty: Bounding the Result

The uncertainty assessment (Article 16) bounds the result — it states the range within which the true value is likely to lie. The uncertainty should be assessed from the contributors identified during test planning: calibration, sensor accuracy, alignment, fixture variation, environment, noise, repeatability and sample variation. The assessment should be documented in an uncertainty budget and the result reported with the expanded uncertainty. The uncertainty is compared to the required accuracy from the test objective. If the uncertainty is smaller than the required accuracy, the test has produced a result capable of answering the question. If the uncertainty is larger, the test cannot answer the question as posed — the result is too uncertain to support the decision. This is not a failure of the test; it is a finding that the measurement chain was not adequate for the question, and it should be reported as such. Claiming a result that the uncertainty does not support is the engineering equivalent of reporting a measurement without an error bar — it implies a precision the system cannot deliver.

11 Interpretation: Deriving Engineering Meaning

Interpretation is the process of deriving engineering meaning from the verified, uncertainty-bounded data. What does the load–strain response tell us about the load path? Does the non-linearity indicate yield, slip or buckling? Does the strain distribution match the analysis prediction? Where did the failure initiate, and is it the predicted location and mode? What is the reserve factor, and does it meet the requirement? Interpretation requires engineering judgement informed by the data, the analysis, the test configuration and the known limitations of both the test and the analysis. The interpretation should be honest about what the data shows and what it does not show. A test that produced data at one load case cannot be interpreted as characterising the structure at a different load case. A test on one article cannot be interpreted as characterising the population without accounting for sample variation. A test where a critical channel failed cannot be interpreted as confirming the behaviour at that location. The engineer should state the basis for the interpretation and the limitations of the data, not stretch the interpretation beyond what the evidence supports.

12 Correlation: Comparing Test to Analysis

Correlation is the comparison of the test result to the analysis prediction. It answers: does the analysis agree with the test? Where do they differ? What do the differences tell us about the analysis, the test or the structure? Correlation is not a simple pass/fail — the analysis and the test will rarely agree perfectly, and the engineer must judge whether the level of agreement is adequate for the purpose and whether the differences are understood. Good correlation — agreement within the uncertainty of the test — confirms that the analysis represents the structure's behaviour. Poor correlation demands investigation: is the analysis wrong (wrong assumptions, wrong model, wrong material properties)? Is the test wrong (wrong boundary condition, wrong load introduction, wrong instrumentation)? Or is there a real difference between the analysis model and the test article (manufacturing deviation, damage, material variation)? The investigation of correlation discrepancies is one of the most valuable outputs of a test — it reveals where the engineering understanding is incomplete, and that knowledge drives improvement in both the analysis and the test.

13 Engineering Conclusion: Answering the Original Question

The engineering conclusion is the answer to the original requirement. It should state what the test demonstrated, what it did not demonstrate, what the uncertainties are and what the implication is for the engineering decision. The conclusion is supported by the evidence — the data, the uncertainty, the interpretation and the correlation — and it should be traceable to that evidence. A conclusion that cannot be traced to evidence is an opinion, not an engineering conclusion. The conclusion should also state what remains unknown. No test answers every question; there are always aspects that were not tested, conditions that were not covered and uncertainties that could not be resolved. Stating these limitations is not a weakness — it is what makes the conclusion defensible. A conclusion that claims to have answered everything is over-reaching; a conclusion that clearly states what it has demonstrated and what remains open is evidence that the engineer has thought about the chain end to end.

The Test-Evidence Chain Diagram

The diagram below shows the complete chain from requirement to engineering evidence, with the flow of information and the verification that must occur at each stage.

TEST-EVIDENCE CHAIN

  01 Requirement
      │  What is the engineering question?
      ▼
  02 Test Objective ──── connects back to requirement
      │  What will be measured, on what, to what accuracy?
      ▼
  03 Configuration ──── matches analysis / service assumptions
      │  Article, boundary, environment, loading
      ▼
  04 Fixture ────────── verified: stiffness, dynamics, repeatability
      │  Provides the intended boundary condition
      ▼
  05 Load Introduction ─ verified: load enters as assumed
      │  Actuator, load path, distribution, control
      ▼
  06 Instrumentation ─── verified: range, locations, coverage
      │  Sensors matched to the objective
      ▼
  07 Calibration ─────── verified: in date, correct, traceable
      │  Sensitivity known and entered correctly
      ▼
  08 Test Execution ──── documented: plan followed, deviations logged
      │  Run the test, record everything
      ▼
  09 Data QA ─────────── verified: no clipping, aliasing, dropouts
      │  Data is valid before analysis
      ▼
  10 Uncertainty ─────── documented: budget, expanded uncertainty
      │  Result bounded by defensible uncertainty
      ▼
  11 Interpretation ──── honest: what data shows, what it does not
      │  Engineering meaning from verified data
      ▼
  12 Correlation ─────── investigated: test vs analysis, differences understood
      │  Does the analysis agree with the test?
      ▼
  13 Engineering Conclusion ── answers the original requirement
      │  What was demonstrated, what was not, what remains
      ▼
  ENGINEERING EVIDENCE

  Each link verified. Break one link → the chain fails.

Process Stages and Their Outputs

The table below maps each stage of the workflow to its key output, what it connects to, what can go wrong and what evidence it produces. The table is a reference for the engineer planning or reviewing a test — it identifies what each stage should produce and where the chain can break.

The Central Principle

Every stage of the chain serves a single purpose: to produce an engineering answer that is supported by evidence. The test is designed to answer a question; the measurement system is designed to support the answer; the uncertainty is assessed to bound the answer; the interpretation is grounded in the data; the correlation validates the analysis; and the conclusion answers the question honestly. The engineer who designs, executes and verifies this chain end to end produces defensible experimental evidence. The engineer who skips links, assumes instead of verifying, or reports results without uncertainty produces data that may look like evidence but cannot be trusted to support an engineering decision. The difference between a good test and a bad test is not the quality of the hardware or the sophistication of the sensors. It is whether the test was designed to answer a defined engineering question and whether the measurement system was verified to be capable of supporting that answer. A simple test, well-designed and well-executed, with a clear objective and a documented uncertainty, is better evidence than a complex test with no clear objective and no uncertainty assessment. The principle is the same regardless of the discipline, the industry or the scale of the test: design the test to answer the question, then ensure the measurement system is capable of supporting the answer.

DESIGN THE TEST TO ANSWER THE QUESTION — THEN ENSURE THE MEASUREMENT SYSTEM IS CAPABLE OF SUPPORTING THE ANSWER.

Verifying the Chain End to End

The concluding test is not whether the structure survived or whether the data looks plausible. It is whether the entire chain — from requirement to conclusion — has been verified end to end. Was the requirement specific? Was the objective derived from the requirement? Was the configuration matched to the analysis? Was the fixture verified? Was the load introduction checked? Was the instrumentation adequate? Was the calibration current and correct? Was the execution documented? Was the data quality-assured? Was the uncertainty assessed? Was the interpretation grounded in evidence? Was the correlation investigated? Was the conclusion traceable and honest about its limitations? If the answer to any of these is "no" or "not checked", the chain has a weak link, and the evidence is not as strong as it appears. The engineer should verify the chain before relying on the result — not after, when the decision has been made and the weakness is discovered too late.

ACCEPTING TEST RESULTS WITHOUT VERIFYING THAT THE TEST ARTICLE, FIXTURE, LOAD INTRODUCTION AND MEASUREMENT CHAIN WERE ADEQUATE FOR THE ENGINEERING QUESTION CAN PRODUCE EVIDENCE THAT IS NOT DEFENSIBLE. The chain must be verified end to end.

Closing

This knowledge base has covered the complete practice of experimental mechanics and structural testing — from the fundamentals of what a test is and why it is done, through the planning, the fixtures, the load introduction, the instrumentation, the data acquisition, the test types (static, fatigue, dynamic, failure), the uncertainty, and finally the complete chain from requirement to defensible evidence. The unifying theme throughout is that a physical test is an engineering instrument designed to answer a question, and its value depends entirely on whether it was designed, executed and verified to answer that question. The hardware, the sensors and the data are the means; the engineering evidence is the end. The engineer who keeps that distinction clear produces tests that are worth running and results that are worth trusting.