Design For Testability - Definition of the process
Design for testability (DFT) is often a casualty of time-to-market imperatives. The R&D team chooses to rush through the design and development of an electronic system schematics to obtain a prototype as soon as possible, ignoring all testability requirements to go faster. It is reasoned that testability features can be added later, but as more and more deliveries loom, the transfer to production team becomes stuck with the system as it is.
As we will discuss in this new blog series, skipping the DFT phase will without fail have insidious and sometimes catastrophic consequences on the ability to scale these deliveries without an associated cost explosion. We will detail these consequences and propose ways to orient the DFT effort to make sure they do not appear. We will see the energy deployed in DFT will yield major time and cost savings in the future, especially as the delivery volume goes up. Let’s start by defining what DFT is and what are its typical steps.
The main objective of DFT is to ensure a high testability of a new system. It aims to permit the system to be tested
- As completely as possible
- As quickly as possible
- As cheaply as possible
- With as much repeatability as possible
And thus to ensure the final quality of the system more efficiently. How we manage to reach this objective is by front-loading the effort of the test design and by feeding back the results of the analysis, adding test features and tools into the product design itself.
The first step is the study of the system’s preliminary design, starting with block diagrams and schematics, be they electronic or mechanic. It is very important for the schematics to be preliminary otherwise DFT will not be able to modify the design for increased testability. The analysis consists in listing and understanding all of the system’s interfaces and how they interact. The list of interfaces is inputted into a traceability matrix which will make sure all of the interfaces are taken care of by our test strategy and test plan.
Once the design and all its interfaces all well understood, the test strategy is elaborated. The test strategy is the high-level definition of how the system will be tested. Prior to determining it, the following operational test objectives must be defined, as they will directly affect the strategy.
- The target volume
- The maximum total test cost per unit
- The target delivery throughput (in units per week or months)
- The intended test coverage extent
The elaboration of the test strategy involves making the following choices:
- Deciding whether and how much to automate testing - lien vers blog
- Selecting a preliminary test BOM; choosing whether to use
- a mechanical test fixture
- external test equipment
- Deciding how to setup the production line
- For example, are subsystems tested individually or always as part of the system, etc.
- Determining the general flow of the test, from the reception of all sub-systems, through assembly and until the delivery.
The objective is to detail the strategy up to a degree of detail which convinces you that all of the operational test objectives will be met. Many strategies can be evaluated concurrently to make sure the best and cheapest one is selected, as we showcased in our previous blog entry.
Elaboration of the preliminary test plan
Once a strategy has been selected and committed to, the next step is the further elaboration of the strategy into a preliminary test plan. Following the strategy’s outlines, the individual subtests are defined. For each are listed the flow of the test and the necessary test tools.
At this point, it is not important to go in too much depth in the definition of each test. For the DFT, the main aim is to list all test tools necessary to perform the tests. These test tools can be electronic, mechanical or software, and are either
- In-system : meaning that the system will be delivered with these features in it or
- Peripheral to it
The following table shows examples for all types of tests tools to be listed.
|Test tool type||In-system||Peripheral|
|Electrical||Test points for probing, measure taking hardware such as an ADC for test purposes, test signal generating mhardware||All test equipment (external controllable sources, multimeter, signal generator)|
|Mechanical||Modifications to the form factor of electronic card or enclosure to better accommodate test||Mechanical test fixtures|
|Software||Test functions added to API, test features added to system operating GUI||Specific test software for the system, automation of test equipment|
Using the traceability matrix, make sure each of the system’s interfaces is covered to satisfaction by the preliminary test plan and that the intended extent of the test coverage is reached. Once the preliminary test plan is complete, make sure all assumptions made during the elaboration of the test strategy still hold and that all operational objectives are still on target.
Aggregation of test tools
From the test plan’s listed tools, a comprehensive list is created. This step is the crux of the DFT phase, where the testability imperatives are fed back to the design. The test tools list is discussed with the R&D department and the best way to import them into the design is determined.
- In-system software test tools are added to the software team stories backlog.
- In-system hardware test tools are verified by the hardware team and added to the schematics.
- In-system mechanical test tools are validated by the marketing and design teams if they modify the product form factor or overall look, then the drawings are completed.
The design is iterated through the DFT cycle until all stakeholders are satisfied with the design.
We can recap the DFT phases and the energy to dedicate to each thusly
|Design analysise||Fully understand the product|
|Test strategy||Determine the right test strategy to meet the operational objectives|
|Test plan||Implement the strategy in a test plan up to a point that allows the listing of all test tools|
|Test tools||Aggregate all the necessary test tools in a comprehensive list and feed them back into the design|
Note here that DFT is not solely a transfer to production endeavour. The hardware R&D team should also use the same approach to make sure their system design validation test tools are present on the product when they need them.