KEVOS · Templates & Examples · Project Templates
Engineering Test Request Register Template
A generic engineering test request register for priority, sample readiness, test status, forecast dates, execution and result control.
Executive summary
The engineering-test workbook contains more than 900 product/test records and uses a repeatable request-to-result structure: status, product/test identifier, priority, test type, sample details, requester/manager roles, test instructions, sample readiness, laboratory comments, test dates, numerical result fields and business grouping. This page converts that operating register into a generic project-template design without carrying over any company, product or person identifiers.
What the source register controls
The register is not just a list of test results. It manages demand into a test function. Rows move through statuses such as not started, in progress, awaiting report, complete, paused and cancelled. Priority classes distinguish urgent quality or customer-driven work from normal project and stock-check work. Separate fields show whether the required samples have been supplied and when the test was delivered, started, forecast and completed.
That structure solves a common project-scheduling problem: the Gantt task says “testing”, but the detailed operational information needed to start and complete the test lives elsewhere. A well-designed test register can provide that detail while the project schedule carries the controlling dependency and forecast.
Recommended register schema
| Field group | Fields | Control purpose |
|---|---|---|
| Identity | Test request ID; project/reference ID; item or configuration description. | Trace the test to the correct project and sample configuration. |
| Workflow | Status; priority; request date; delivered date; start date; forecast completion; completion date. | Control queue and forecast. |
| Test definition | Test type; test details/method summary; performance target/reference. | Make the requested test unambiguous without storing an entire procedure in the schedule. |
| Samples | Sample description; quantity; required-samples-ready flag; relevant load/weight/sample parameters. | Prevent tests being scheduled before usable samples are available. |
| Responsibility | Requesting role; product/project manager role; testing officer/owner. | Clarify who requests, who owns the product decision and who performs/coordinates testing. |
| Result | Result summary; numerical result columns where appropriate; report reference. | Provide decision-ready evidence and a link to the detailed record. |
| Administration | Created/modified timestamps; business/project stream. | Support traceability and filtering. |
Source test mix
The source register is dominated by cycle, ultimate/strength and neutral-salt-spray work, with additional tensile, torque, function, impact and other specialised tests. Those categories are source examples only; they are not a prescribed KEVOS test taxonomy. The template should allow an organisation to maintain its own controlled list of test types.
Similarly, numerical fields such as cycles, force or exposure hours should be included only where meaningful for the selected test. Do not create a universal pass/fail threshold from values in historical rows. The acceptance target must come from the relevant product requirement, customer specification, engineering requirement or approved test plan.
Request-to-result workflow
Readiness gate before test start
- The sample configuration is identifiable and matches the purpose of the test.
- Required quantity is available or an explicit sample-shortage action exists.
- The test instruction states what is to be done and what result is to be captured.
- Applicable performance target or specification reference is known where a pass/fail decision is required.
- Fixtures, rigs, gauges or instruments needed for the test are available and suitable.
- The test priority is assigned using the organisation’s agreed rules.
- A forecast completion date reflects current queue/capacity rather than the project’s desired date alone.
- The project schedule links to the test completion or report review when testing is on the controlling path.
Status definitions
| Status | Meaning | Project-schedule treatment |
|---|---|---|
| Not started | Request exists but testing has not begun. | Keep project test task open; check sample/readiness and queue forecast. |
| In progress | Test execution is underway. | Use current forecast and monitor interruptions or failures. |
| Awaiting report | Physical test may be complete but the formal result/review evidence is not yet available. | Do not close the project dependency if the gate requires the report. |
| Paused | Testing cannot continue temporarily. | Record reason and restart trigger; update forecast. |
| Complete | Required test/result record is complete for the register. | Project team still needs to disposition the result before closing downstream approval if required. |
| Cancelled | Request will not proceed. | Record why; ensure project plan is updated so it does not continue waiting for a cancelled test. |
Priority design
The source uses five broad priority groupings tied to quality failures, customer/director requests, customer projects, internal projects and stock checks. Because those names are organisation-specific, the generic template should keep the concept but not the labels.
A robust priority method should define what each level means and who can assign or change it. Priority should influence queue order, but it should not override safety, test-method readiness or sample suitability. A high-priority request that is not ready should not block ready work unnecessarily; instead, its missing prerequisite should be visible.
Useful operating metrics
| Metric | Formula / interpretation |
|---|---|
| Open test queue | Count of requests in not-started, in-progress, awaiting-report or paused states. |
| Ready-to-test queue | Open requests with required samples and prerequisites available. |
| Forecast adherence | Completed on or before the last committed forecast ÷ completed requests. |
| Cycle time | Completion date − delivered/ready date, with waiting causes reviewed separately. |
| Paused ageing | Current date − pause date for requests still paused. |
| Repeat-test rate | Requests repeated because of product, tooling, sample or test-method correction; classify the reason rather than using the number alone. |
Related KEVOS templates
Operating the test register as a service queue
The register should have one clear point at which a request becomes ready for scheduling. Before that point, it may exist as a draft or awaiting-sample request, but the forecast completion date should not imply that testing has started. Confirm the test purpose, sample identity and quantity, method or instruction, priority basis and required report/result. If essential information is absent, return the request for completion or mark the missing prerequisite visibly.
Once ready, assign the testing resource and a forecast that reflects both the intrinsic test duration and the current queue. Long-running tests should not be treated the same as short functional checks: the register can show the start date and expected finish while the resource may be available for other work in between, depending on the test method. The schedule link should use the forecast completion of the evidence needed by the project, not a generic laboratory promise.
Result and closure discipline
- Record the tested product/sample configuration and number of samples actually tested.
- Keep raw observations or referenced result files traceable to the request.
- Use a controlled status for paused, cancelled or awaiting-report work so it is not mistaken for active testing.
- Record the completion date when the required evidence is available, not merely when physical testing stops if a report is still required.
- Link failed or inconclusive results to the project correction/retest action rather than creating an unrelated new request without context.
- Review ageing requests and incomplete sample/readiness fields as part of routine queue hygiene.
The historical register contains many completed records and several distinct status states, which makes it valuable as a learning dataset. Future analysis can compare forecast versus actual completion, identify dominant test families and detect recurring waits for samples or reports. Those measures should be used to improve planning and service capacity, not to create arbitrary universal test-time targets.