Define the device variant under test
The firmware programming release checklist defines the approved image, hardware compatibility, configuration and unit record that the final-test procedure should reference.
Record the approved hardware, firmware and configuration identifiers. Identify the interfaces, accessories and power arrangement used for the required checks. Where antennas, sensors or cables are installed in the enclosure, define the test setup in that assembled state.
Use the box build manufacturing scope to agree programming, integration and pack-out responsibilities. The customer and manufacturer should also identify the owner of software-function validation and acceptance criteria.
Final-test planning checklist
| Check area | Define in the released procedure | Useful result field |
|---|---|---|
| Software and configuration | Programming source, approved version and variant settings | Version/configuration identity and programming result |
| Power and startup | Input conditions, startup sequence and product-defined limits | Setup, measured values or defined pass/fail outcome |
| Connectivity | Specified wired/wireless interfaces, test endpoint and operating conditions | Interface, setup and observed result |
| Sensors, camera or other functions | Applicable functions, stimulus and acceptance rules for this variant | Function, limits and result |
| Installed interfaces | Connector engagement, harness routing and enclosure fit as specified | Assembly checks and deviation disposition |
| Product identity | Required association between identifier, variant and delivered configuration | Serial/batch identity and configuration association |
| Pack-out | Approved labels, accessories, protection and shipment identification | Pack-out release record |
Protect device and customer data during test
If programming uses credentials, keys or customer configuration, define the authorized provisioning method, access owner and handling requirements before production. Use approved test accounts and endpoints where applicable. Do not include production credentials or customer personal data in routine records or examples.
Separate manufacturing checks from qualification
A connectivity check demonstrates the agreed connection under its test conditions. It does not prove performance in every deployment environment or software-security state. EMC, radio, electrical safety, cybersecurity and environmental qualification require their own applicable requirements, responsible parties and evidence. Review the manufacturing test scope and specify separate qualification work explicitly.
Control failures and retests
Keep the original failure and distinguish programming, connectivity, interface, power and assembly findings. Record approved corrections and the test steps repeated after repair. The harness integration guide helps separate board and installed-interface problems; the quality evidence chain describes record expectations.
Illustrative configuration mismatch
A device can complete a board-level check while the finished unit contains the wrong released configuration or label. A final procedure should verify the agreed relationship between device identity and configuration before pack-out. This is an illustrative control example, not a published customer outcome.
Bring the system requirements into the RFQ
Use the whole-product quotation checklist to identify the system BOM, software, test assets, labels and packing definition. Discuss the final-test and delivery requirements with the current product stage and open questions. Feasibility, scope and timing are confirmed for the proposed build.