We've broken down the ATP (Acceptance Test Procedure) development process into the 8 steps below. These steps should sound familiar if you do test in-house, though they may meld together a little more. When we discuss your project we can tailor the steps to suite its unique needs.
To get started, download our Project Overview Form, gather some product documents, such as schematics, and get a picture of the product. Then we can proceed to Initial Discussions - see the information on our Contact page.
Our effort starts in the first phone call or email and ensuing discussions. We'll get to know each other a bit and talk project scope and DUT (Device Under Test), timeline, budget, constraints, resource availability, etc. We'll assess whether you have the resources to do the requirements in-house, or if we should drive the requirements definition phase. We'll designate a Test Coordinator - this is a person on your end who will be our point of contact for providing the documentation, hardware, answering technical questions, working with deployment, etc.
The output of these discussion will be a quote for either requirements definition & system design, or just system design if you're providing the requirements document.
In order for us to design an ATP we'll need proper understanding of your DUT and system. We come to the table from a design engineer's perspective, so we don't need hand-holding, but we will be in search for the right information.
This stage is all about communicating expectations, technical details, and requirements. Your Test Coordinator can facilitate this effort by working with a project manager and/or engineer with time set aside to provide documents and technical details. The better documentation you can provide, the leaner we can quote you. Sparse or missing documentation often means important details of the DUT's design and functionality are left out. We can study the DUT's design and develop the ATP, but the procedure and fixture hardware may need additional complexity to manage the risk of inconveniently discovering design details in later stages of the consulting process.
Below we go through details of Documents, Requirements Definition, & System Design. Though each piece can be treated separately, for the optimal solution they will all be inter-related.
Getting this right is critical to avoid costly changes later in the process. We can drive the effort on the requirements definition, or you can. If we're driving then we'll be optimizing the tradeoff of: test accuracy / coverage / thoroughness vs. cost of equipment & total-solution, depending on your priorities. If you have an engineer with experience generating thorough automated test requirements, you can provide us a requirements definition document. However, ensure you set aside appropriate hours for the engineer to get this together (typically 20 to 60 hours).
Request our template Requirements Definition Template if you are interested in writing the requirements yourself.
System design is taking the requirements and selecting the equipment to be used, test setup form-factor, DUT interface, connectors, cabling, operator workflow, deployment plan & needs, reporting integration, etc.
System design may be performed concurrently with requirements definition, or after requirements definition. If keeping costs down is a goal, we find that doing the requirements definition and system design concurrently allows for iteration of both pieces to yield the lowest-cost solution in terms of equipment and/or development costs. Sometimes a seemingly small change in requirements may allow for a cheaper piece of test equipment, or may greatly simplify the test system complexity.
We provide a quote after the documents, requirements definition, and system design are complete.
We prefer fixed-cost quotes so long as the requirements are thorough and DUT design is stable. It gives you a known cost up-front and a firm timeline that you can plan around. The firm timeline allows us to efficiently allocate our efforts as well.
If the project requires a flexible effort then we offer a Time & Materials contract instead.
See our pricing page for more details.
Once the Purchase Order has been approved, the first priority is getting hardware in-hand. This kicks off the quoted project timeline, so we can start developing the test.
At the minimum, we need a golden unit DUT. A golden unit is a DUT that has been fully tested manually on the bench to ensure that all tests that will be performed as specified in the requirements definition exhibit passing criteria. Any required software and API's are complete, and loaded on the DUT. Basically, the golden unit is known-good board that can be used as a static "this board should pass the ATP" reference. If the DUT is still in development, sometimes getting this board can take some time.
Why can't we start developing the test from all the documentation (without hardware in hand)? We can, but we avoid it if possible. Hardware in hand allows us to efficiently assess things like connectors, operator handling procedures, LED visibility, power-up procedures, etc. Additionally, it ensures the DUT is at a point in hardware maturity that the test fixture won't require a costly change down the line due to an unforseen change in the DUT.
We're working full-speed-ahead on the ATP. We'll be doing CAD for any enclosures, metalwork, PWA's, cables, etc. Software will be developed. Manual testing of the golden unit DUT to ensure all details are accounted for on the test. Parts ordered, assembled, tested. Integration of all the parts, debugging the software, running the ATP, and validating proper test coverage manually and using the golden unit DUT. Good requirements allow us to run through this ATP development & implementation with minimal time required on your end.
This is QA performed by Subinitial, and can be as simple as running a golden unit DUT through the test, or as complicated as making an automated self-tester. We'll perform the selected QA strategy on the ATP fixture, and provide a quality report of the testing.
Customers typically opt for running a golden unit DUT through the tester, or use benchtop equipment to perform a manual test. An automated self-tester is the most thorough, but also adds time and cost to the overall project.
If you require running your own test validation on the fixture prior to acceptance, we can deliver the fixture to you to validate before deployment. Otherwise, we will deploy the ATP directly.
For deployment, we'll get the ATP up and running at its final location, often at a contract manufacturer or one of your facilities. We'll get the hardware there, train the operators as necessary, and run the first units through (if available). Alternately, if you have the skills, you can perform the deployment yourself to save cost.
We tailor the support package to something that is comfortable for your company. We can either bake support into the initial contract, or wait and see if any problems arise that take more than a quick phone call to resolve. Most issues can be resolved remotely, and it's rare we need to come on site. Support contracts typically run from 1 to 5 years, and can be renewed as needed.