When discussing vehicle or component testing, the image that usually comes to mind is a specimen mounted on a test rig, a set of sensors, and ultimately a Pass or Fail result. However, a significant part of a test's validity is established before the equipment even starts operating. First, it is necessary to determine which requirement is being evaluated, whether that requirement applies to the product, which version of the standard or test method should be used, what specimen configuration is required, which parameters must be measured, and what the acceptance criteria are. After testing, the data must also be processed, reviewed, and reported as traceable results.
For this reason, a standardized test is better understood as a chain of engineering decisions and technical activities that connects requirements to verifiable evidence. If the wrong requirement is selected at the beginning of this chain, the test may be performed correctly but still have no value for the project. If the specimen configuration is incorrect, the result may not represent the intended product, and if the test report is interpreted beyond its actual scope, even a technically correct result can lead to an incorrect decision. Therefore, understanding the complete testing process is just as important for vehicle manufacturers, component suppliers, validation teams, and laboratory customers as understanding the test method itself.
Where Does the Testing Process Begin?
An effective testing process begins with defining the engineering question or requirement, not with selecting the testing equipment. It must first be clear which characteristic or requirement is being evaluated and for what purpose the result will be used.
The objective may be product development and understanding the failure mode of a prototype. The activity may be part of Design Verification (DV) or Production Validation (PV), or the result may be needed to assess conformity with a standard. In another project, the evidence generated by testing may be used in a Type Approval process.
These differences affect the specimen, test method, documentation, and even the type of report required. Therefore, the statement “we want to test this component” is not a sufficient starting point for defining a precise test program.
Step One: Identify the Requirement
Every test should be linked to a specific requirement. That requirement may originate from regulations, standards, customer specifications, engineering drawings, or other project documents.
The requirement should be as clear and verifiable as possible. A statement such as “the component must be strong” is not sufficient to design a test; it must be clear what conditions the component must withstand and against which criteria its performance will be evaluated.
This stage is important because the test method and acceptance criteria will subsequently be derived from the requirement. If the requirement is ambiguous, the interpretation of the result will also be uncertain.
Step Two: Assess the Applicability of Requirements
The existence of a standard or regulation does not mean that it applies to every vehicle or component. The scope, definitions, vehicle category, product configuration, and relevant conditions must be reviewed.
A regulation may cover only certain vehicle categories, or a particular requirement may apply only when specific equipment or a particular configuration is present. The implementation status of the requirement in the target market must also be assessed separately.
Therefore, before adding a test number to the program, it should be possible to answer this question: Why does this requirement apply to the product being evaluated?
The article “How to Identify Applicable Standards for a Vehicle or Component” explains this process, from reviewing the scope of application to preparing a Regulatory Requirements Matrix.
Step Three: Determine the Applicable Reference and Version
Simply stating R17, R14, or a standard number is not always sufficient to define a test. Standards and regulations may be revised or amended over time, and the requirements in different versions are not necessarily identical.
In UN Regulations, the Series of Amendments and Transitional Provisions can be important in determining the project's regulatory basis. For customer specifications, the applicable document revision must also be identified.
Therefore, the test request and Test Plan should record the precise reference being used, at the level of detail required, to avoid uncertainty about the basis of testing and interpretation of the results.
Step Four: Select the Appropriate Evaluation Method
Not every requirement needs to be evaluated through physical testing. Depending on the nature of the requirement, testing, engineering analysis, inspection, measurement, or document review may be appropriate Verification methods.
If the applicable reference explicitly specifies a particular method, that method should be used. For internal engineering requirements, the project team should select a method that generates sufficient evidence to answer the relevant engineering question.
This stage prevents a common mistake: converting every requirement into a list of tests. Physical testing is valuable when it is an appropriate method for evaluating the specific requirement.
Step Five: Define the Test Method Precisely
If testing is selected as the evaluation method, it must be clear how the test will be performed. The applicable standard or procedure may define the test setup, specimen condition, measurement equipment, loading method, environmental conditions, and other relevant details.
In development testing, the project team may use a dedicated internal procedure. Even then, the method must be sufficiently clear to ensure that the activity can be performed and its results interpreted.
Changing the method during testing without assessing the impact may affect the validity or interpretation of the result. Therefore, the test method should be defined and appropriately controlled before execution.
Step Six: Define Acceptance Criteria Before Testing
Before reviewing the result, it must be clear what conditions indicate that the requirement has been met. Acceptance Criteria may be derived from standards, regulations, customer requirements, or engineering specifications.
Defining criteria after observing the data can introduce bias into the decision. If the objective is development testing and no Pass/Fail decision is intended, this should also be established from the beginning.
Therefore, not every test necessarily produces a Pass or Fail outcome. However, if a statement of conformity is to be issued, the applicable requirement and acceptance criteria must be clearly defined.
Step Seven: Prepare the Test Plan
Once the requirements and methods have been identified, the activities should be organized in a Test Plan. The Test Plan can manage information such as specimen type and quantity, configuration, test sequence, schedule, responsibilities, and other project-specific details.
In complex projects, the Test Plan helps identify which specimens have been allocated to particular activities and whether one test may affect a subsequent test.
This is particularly important for destructive testing. If a specimen undergoes permanent deformation during the first test, it may no longer be suitable for use in the next test.
Step Eight: Link the Design Verification Program to Requirements
In product development projects, DVP&R, or Design Verification Plan and Report, can maintain the connection between requirements, Verification methods, specimens, and results. The objective is to prevent testing activities from becoming a collection of isolated tasks with no clear relationship to product requirements.
For each requirement, it should be possible to identify how Verification was performed and where the supporting evidence is recorded. If the design changes, this traceability also helps identify results that may be affected.
In this way, the Test Plan defines the execution activities, while DVP&R helps maintain traceability of requirements coverage and evaluation results at the design level.
Step Nine: Select the Appropriate Laboratory
Once the test requirements have been defined, an appropriate laboratory can be selected. The laboratory's capability should be evaluated in relation to the specific test method and the intended use of the result.
Having similar equipment is not sufficient on its own. Fixtures, measurement capability, personnel competence, laboratory facilities, and experience with the relevant method may also be important. If an accredited test result is required, the test's status within the laboratory's Scope of Accreditation must also be checked.
The article “How to Choose the Right Laboratory for Vehicle or Component Testing” discusses laboratory selection criteria in greater detail.
Step Ten: Define the Test Specimen Specifications
A test result relates to the specimen that was actually tested. Therefore, it must be clear which product configuration is required for the intended activity.
Part Number, design revision, material, supplier, manufacturing process, software version, or other characteristics may be important depending on the test. The specimen specifications should be derived from the requirement and the test method.
If structural performance is being evaluated, material properties and joint configuration may be critical. In software functionality testing, the hardware and software configuration may be more important.
When Is a Prototype Suitable for Testing?
A Prototype can be highly valuable for product development and Pre-Testing, but it must be determined how representative it is of the final product in relation to the requirement being evaluated.
A prototype may represent the final product in terms of geometry but be manufactured from a temporary material. Such a specimen may be suitable for fit and dimensional checks but not necessarily for structural strength Verification.
The article “What Is a Prototype and How Are Different Prototypes Used in Automotive Product Development?” explains specimen maturity and how well different prototypes represent the intended product.
Step Eleven: Review the Specimen Before Shipment
Sending the specimen should not be the first time the laboratory becomes aware of its configuration. Engineering drawings, installation requirements, part identification, and necessary auxiliary components should preferably be identified before testing.
If the specimen requires a dedicated fixture or part of the vehicle structure, this should also be reviewed and coordinated before shipment.
For complex tests, a specimen preparation checklist can help prevent situations where the specimen arrives at the laboratory but testing cannot proceed because a required component or piece of information is missing.
Step Twelve: Define the Fixture and Boundary Conditions
In many mechanical tests, the Fixture forms part of the test boundary conditions. The way a specimen is installed and restrained can change the load path and test result.
The fixture should be designed or selected according to the test method, and its interface with the specimen must be defined. Fastener type, tightening torque, alignment, and the extent to which the fixture represents the actual product structure may be important depending on the method.
Therefore, fixture design or selection should not be left until the day of testing or based on assumptions.
Step Thirteen: Plan the Measurement Equipment
Before testing, it must be clear which parameters need to be measured and which measurement systems are required.
Force, displacement, temperature, pressure, acceleration, time, or other parameters may be involved depending on the test. The measurement range and capability of the equipment must be appropriate for the test requirements.
If the engineering team also needs additional data channels for development analysis, these should preferably be identified before testing.
What Is the Role of Calibration?
Equipment that affects the validity of test results must be appropriately controlled, and Calibration is part of this process where relevant.
However, calibration alone does not resolve every measurement-related issue. Measurement range, uncertainty, resolution, and equipment suitability for the intended application may also be important.
Calibration provides information about the relationship between a measurement system's indications and reference values. However, calibration does not necessarily mean that the equipment has been adjusted or that it is suitable for every type of measurement.
Step Fourteen: Perform Specimen Conditioning
Some test methods define specific requirements for specimen Conditioning or Preconditioning. Temperature, humidity, battery State of Charge, or other conditions may be relevant depending on the product.
These conditions must be derived from the applicable test method. There is no single conditioning procedure that applies to every test.
The time required for conditioning must also be included in the test schedule. A specimen may have arrived at the laboratory but may not yet meet the conditions required for testing.
Step Fifteen: Is Pre-Testing Necessary?
Pre-Testing can be used to reduce the risks associated with the main test, assess the test setup, or gain an initial understanding of product performance. However, it is not necessary for every project.
If a specimen is very expensive or the main test is highly complex, a Pre-Test may reveal fixture or design problems before the main activity. In product development, it may also help investigate potential failure modes.
However, Pre-Test results should not automatically be used as evidence from a formal or final test. The objectives and specimen maturity levels of the two activities may differ.
Step Sixteen: Verify the Test Setup Before Execution
Before testing begins, specimen identification, installation, fixtures, measurement equipment, and the conditions required by the test method must be checked.
For critical activities, photographs or setup records can support traceability. The objective is to make it possible to identify the configuration and conditions under which the result was obtained.
If a discrepancy with the test method is identified at this stage, it should preferably be resolved before execution. Collecting data from an incorrect setup generally cannot be corrected simply through additional analysis.
Step Seventeen: Execute the Test
At this stage, the test procedure is performed according to the applicable method, and data are recorded. The operator must carry out the activity in accordance with the controlled procedure and manage conditions that may affect the test.
However, operating the equipment is only one stage of the overall process. All previous decisions concerning requirements, specimens, fixtures, and measurement equipment now affect the quality of the result.
This is why test engineering cannot be reduced to operating testing equipment.
Step Eighteen: Record Raw Data
Many tests generate substantial amounts of Raw Data. Sensor signals, time histories, images, videos, and other records may form part of the initial data.
Raw Data are not the same as the final test result. A result may be obtained by processing, calculating, or extracting a particular parameter from the original data.
The data processing method must also be controlled according to the applicable reference, particularly when filtering, sampling rates, or calculation algorithms affect the reported result.
Step Nineteen: Process the Data
After testing, Raw Data may require conversion, filtering, calculation, or other defined processing operations to produce reportable results.
This stage is part of the measurement chain. Errors in conversion factors, unit conversions, or processing algorithms can change the result even when the sensor has operated correctly.
Therefore, software and calculations that affect the result must also be appropriately controlled.
What Is the Difference Between a Test Result and Pass/Fail?
A Test Result is the output of a measurement or evaluation. In contrast, Pass/Fail indicates whether that result conforms to specified acceptance criteria.
A test may produce a numerical result even when the customer has not requested a statement of conformity. In development testing, the objective may simply be to understand product behavior.
Therefore, a test result should not be confused with a conformity decision.
Step Twenty: Evaluate Measurement Uncertainty Where Required
In relevant measurements, Measurement Uncertainty provides information about the dispersion of values that could reasonably be attributed to the measurand.
This becomes particularly important when a result is close to a specification limit or when the decision rule depends on measurement uncertainty.
However, reporting measurement uncertainty is not a universal requirement for every test report. The applicable requirements, test method, and intended use of the result determine when this information must be reported.
Step Twenty-One: Evaluate Conformity
If a statement of conformity is required, the test result is compared with the relevant acceptance criteria. Where measurement uncertainty affects the decision, the Decision Rule must be defined.
A Pass means that the result meets the relevant requirement according to the applicable decision rule. This statement must not be extended to other requirements that have not been evaluated.
Similarly, a Fail must also be linked to a specific requirement.
What Happens If a Test Fails?
A test failure does not necessarily mean the end of development. It can mark the beginning of a systematic problem-solving process. First, it must be determined whether the observed failure is genuine and whether the test setup, specimen, and method were correct. Root Cause Analysis can then begin.
The location where failure occurs is not necessarily its root cause. A component may fracture at one location, while the underlying cause may involve the load path, material, manufacturing process, or the design of another area.
After corrective action has been taken, an impact analysis determines which Verification activities need to be repeated.
Should the Test Be Repeated Immediately?
Not necessarily. If the cause of failure has not been identified, repeating the same test on another specimen may simply produce a different result without resolving the underlying issue.
It should first be determined whether the failure resulted from the design, specimen variability, a manufacturing issue, the test setup, or another factor. A change or corrective action can then be defined, and retesting should have a clear objective.
The purpose of retesting is not simply to obtain a Pass result. It should generate reliable evidence that the identified issue has been effectively resolved.
Step Twenty-Two: Perform a Technical Review
Before issuing the report, the results and related information must undergo a Technical Review in accordance with the laboratory's procedures. The objective is to assess whether the activity performed and the reporting are consistent with the applicable requirements.
Review does not replace correct test execution. An incorrect setup cannot be corrected through an administrative review of the report. However, the review can help identify reporting errors, calculation mistakes, or inconsistencies before the report is issued.
This stage forms part of the process of producing reliable results.
Step Twenty-Three: Issue the Test Report
A Test Report records information about the specimen, test method, and results in a usable format. Depending on the test and applicable requirements, it may also include information such as test conditions, observations, photographs, measurement uncertainty, or a statement of conformity.
A report does not necessarily include all Raw Data, and a Pass/Fail statement is not required in every report.
The article “What Is a Test Report and What Should You Look for When Reviewing One?” explains how to review report information and the key considerations when using test results.
Is Issuing the Test Report the End of the Process?
For the laboratory activity itself, the report is one of the main deliverables, but it does not necessarily mark the end of the process at the project level.
The result may be entered into the DVP&R, the relevant requirement may be closed, a failure may lead to a design change, or the report may be used as technical evidence in another process.
In Type Approval, a test report may also form part of the technical evidence, but the report itself is not equivalent to Type Approval.
Does Passing a Test Mean the Product Has Been Approved?
Not in general. A Pass result must be interpreted only within the scope of the relevant requirement and test.
A vehicle may have dozens of other requirements that have not yet been evaluated. Type Approval or product certification may also involve a separate process managed by the relevant approval authority or certification body.
Therefore, the statement “the product passed the test” is not equivalent to “the product meets all applicable requirements.”
Where Does Type Approval Fit into This Process?
If a test forms part of the Type Approval process, the resulting technical evidence is used within the framework of the applicable regulation. Designated Technical Services and Type Approval Authorities each have their defined roles.
Performing a test at a laboratory does not, by itself, result in approval. The Type Approval process may involve technical documentation, definition of the product Type, test evidence, and other relevant requirements.
For this reason, the purpose of testing must be defined from the beginning so that the evidence generated is suitable for the intended process.
Which Stages Are Affected by ISO/IEC 17025?
ISO/IEC 17025 provides a framework for evaluating laboratory competence, impartiality, and consistent operation. It covers areas such as personnel, equipment, metrological traceability, test methods, handling of test items, technical records, and reporting.
However, ISO/IEC 17025 does not establish the technical requirements for the product itself. This standard does not specify that a vehicle must comply with R17 or R14; such requirements originate from the regulations or technical specifications applicable to the product.
Therefore, product standards and laboratory competence standards serve two different purposes.
What Are the Responsibilities of the Customer and the Laboratory?
The division of responsibilities depends on the contract and agreed process. In general, the customer should provide the test objective and necessary product information, while the laboratory should perform the testing activity according to the agreed method and scope.
The laboratory should not make assumptions about an undefined product configuration, and the customer should not assume that the laboratory can identify every applicable product requirement without receiving the necessary project information.
Technical coordination before testing is an important part of successful execution.
How Can Unnecessary Retesting Be Avoided?
A significant amount of unnecessary retesting can be reduced through better planning. Selecting the correct requirement, identifying the applicable standard version, preparing a representative specimen, ensuring that the fixture is suitable, and defining reporting requirements can prevent many problems before testing begins.
It is also advisable to perform a Test Readiness Review before important testing activities. This means checking that the specimen, setup, measurement equipment, test method, and required documentation are ready.
The cost of a few hours of review is often much lower than the cost of consuming a prototype and booking the laboratory again.
The Testing Process at a Glance
The overall process can be summarized as follows:
Requirement Identification → Applicability Assessment → Reference and Version Selection → Evaluation Method Selection → Acceptance Criteria Definition → Test Planning → Specimen and Configuration Definition → Laboratory Selection and Accreditation Scope Review → Fixture Preparation → Measurement Equipment Selection → Specimen Conditioning → Setup Verification → Test Execution → Raw Data Recording → Data Processing → Result Determination → Conformity Decision → Technical Review → Test Report Issuance → Project Decision
This sequence is not a fixed execution template for every test. The type of test and the organization's processes may change some of the stages. However, the underlying principle remains the same: the result must be traceable to a specific requirement and specimen.
A Good Test Begins Before the Equipment Is Switched On
The most visible part of testing is usually the moment when the specimen is placed on the test rig and data acquisition begins. However, the quality of the result is established long before that moment. The correct requirement must have been selected, applicability and the reference version reviewed, the specimen must represent the intended product, the fixture and measurement system must be suitable, and acceptance criteria must be defined before the data are observed.
The work does not end when the equipment is switched off. Raw Data must be converted into usable results, the results must be reviewed, conformity must be assessed where required, and the report must connect the specimen, method, and outcome in a traceable manner.
Therefore, the professional question about a test is not simply “How is this test performed?” A more complete question is: “Which requirement is this test intended to evaluate, on which configuration, using which method and measurement system, and what decision will the result support?” When this chain is clearly established, testing becomes more than an execution activity; it becomes meaningful evidence for product development, Verification, and engineering decision-making.