Test condition
Hardware, optics, software version, configuration revision and traffic or management conditions are recorded.Observable result
Each check has a defined method and pass, fail or exception outcome rather than a general tested statement.Traceability
Identifiers, versions, dates, evidence and changes can be linked to the delivered configuration where scoped.Sign-off boundary
Pre-shipment, receiving and site acceptance remain separate stages with named owners.
Evidence boundary
The product image is not a test result.
No photograph on this page is presented as laboratory, pre-shipment or site-acceptance evidence. A passed result applies only to the recorded configuration, conditions, method and stage covered by the agreed plan.
What establishes a project-specific claim
- The test plan, hardware and optics identifiers, software version and configuration revision
- Observable outputs or measurements tied to each pass, fail or exception decision
- Named review and sign-off roles, corrective actions, retest results and remaining limits
Write the test plan around decisions
A test is useful when its result changes an approval decision. The plan should name the condition, method, expected result, evidence to retain, owner and response to failure before execution begins.
- Port profile, optics, link state, management access and software version
- Telemetry, configuration load, rollback and representative traffic checks where required
- Power-cycle, failure-state or recovery checks only when included in scope
- Evidence format, exception owner, rework path and retest rule
Keep the acceptance stages separate
Pre-shipment checks can show that a configured set worked under stated conditions. Receiving inspection confirms what arrived. Site acceptance checks the buyer environment and operating workflow. A result from one stage should not be presented as proof of another.
- Pre-shipment: configured equipment, agreed interfaces and recorded evidence
- Receiving: quantity, condition, identifiers, documents and transit exceptions
- Site: rack, power, cooling, cabling, management, monitoring and operator workflow
- Change control: identify what changed and which checks must be repeated
Build an evidence pack that can be reviewed later
The evidence pack should be useful to the buyer after handover. The quoted scope may include a port or optics matrix, version record, configuration revision, test results and exception notes; unsupported evidence should not be implied.
- Test identifier, date, condition, method, expected outcome and result
- Hardware or optics identifier and software or configuration revision
- Failure, exception, corrective action and retest result
- Named review or sign-off role and any remaining limitation
Test scope
What acceptance evidence can and cannot establish
What should be agreed before a test begins?
Agree the configuration, conditions, method, expected outcome, retained evidence, exception process, owner and commercial boundary.
Is lab validation the same as site acceptance?
No. Lab or pre-shipment testing uses controlled conditions; site acceptance checks the delivered system in the buyer environment.
Can the evidence format be customised?
Where agreed in the quotation, the output can be shaped around the buyer review process. The exact records and level of detail must be scoped.
Does a passed test prove standards or regulatory compliance?
Not automatically. It demonstrates the stated test only. Formal conformance or regulatory claims require the applicable assessment and evidence path.