Easing Test Bench Development
The development of electronic card and systems testbenches is often more arduous than it should, and the test bench’s quality is often sub-par compared to the quality of the system it tests. These unnecessary pains are typically not the fault of the test bench developer itself, but have a more systemic or enterprise-level origin. The developer has the odds stacked against him from the start.
First, a lot of electronic systems manufacturers do not value the transfer to production engineering as an integral part of the design of a new product.
- They wait until development is mostly done and a first functional prototype is available.
- They do not allocate dedicated resources to the development and deployment of the test benches.
The design, development and deployment of the test benches, which will eventually allow the company to deliver systems and earn revenue, are an afterthought. Starting to think about the transfer to production too late in the design cycle will create a major time crunch to deliver a usable test bench in time to deliver production units.
Complexity of Projects
The developer thrust into this responsibility is faced with what is a multidisciplinary project. To execute his task to the quality level required, he or she must possess the following knowledge and skills:
- Have a complete understanding of the electronics which will be tested; Know how to establish a test strategy and create a test plan which will reach the intended coverage level;
- Be able to program an intuitive GUI for use by the testers;
- Be able to interface all test equipment programmatically;
- Be able to program the test sequences and libraries;
- Be able to generate detailed results and manage a results database;
- Be able to architecture a stable software program integrating all of the above sub-parts;
- Generate complete and accurate documentation on the design and the operation of the testbench;
It is not normal to expect that a single resource can excel in all these areas. Combine this fact to the time crunch and it's no wonder test benches have major shortfalls.
These shortfalls are not only short lived either. If one resource is responsible for the design and the technology choices, as well as the development and the deployment of the testbenches, then a technological debt begins to take place. Just imagine what happens when this resource leaves. The test bench can only be modified or deployed to a new test station through even more arduous labor by a new resource which has to understand and learn everything the first resource did. The engineering team will have to carry all of the (not-necessarily informed) engineering choices made in a time crunch throughout the life of the product to permit the delivery of units.
Our Proposition: Use a Test Framework
The test framework’s objective is to alleviate the test developer’s task
We believe strongly that the only skill the testbench developer should be expected to excel at is understanding how to best test the system he means to test. The rest should be taken care of by the right tools. This becomes increasingly true the smaller the team is and if resources are shared with the system design and development.
Only one tool can have an important impact in reducing development time and effort, as well as focusing the competence of the developer on the knowledge of the system. This tool is the test framework (also known as test executor, sequencer or engine), such as Tack’s implementation of Spintop-OpenHTF.
The test framework’s objective is to alleviate the test developer’s task and allow him to concentrate only on his expertise, understanding how to test the system. It provides a standardized graphical user interface, the management of the test bench and test instances configuration, the sequencing of the test cases, the criteria management as well as the formatting and backuping of test results.
These are all parts of the test bench the developer would originally have had to code himself, with varying quality results. With a stable framework such as Spintop-OpenHTF, the developer can finally focus on his strengths and work toward delivering a quality testbench. As the framework is supported and updated by its developers, no technology debt is incurred.
Development time saving
The time saved during test bench development is most directly impacted by the reuse of previously developed tools. Using a test framework is a great way to reduce drastically the development time as the reuse of its features is its main purpose.
Spintop Suite Usage
The following diagram shows the typical usage of the spintop-openhtf test framework and its interaction with spintop supervisor and the Spintop Cloud platform.
Would you like to use our test framework to accelerate your transfer to production? Get started with spintop-openhtf.