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 the 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.
We manage to reach this objective 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 the DFT process will not be able to modify the design for increased testability.
The design analysis consists in listing and understanding all of the system’s interfaces and how they interact. The interfaces are traced into a matrix to make sure they are all taken care of by our test strategy and test plan.
Once the design and all its interfaces are all well understood, the test strategy is elaborated. The test strategy is the high-level definition of how the system will be tested. But first, 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 decisions:
Deciding whether and how much to automate testing
Selecting a preliminary test BOM: i.e. choosing whether to use a mechanical test fixture and external test equipment
Deciding how to setup the production line: i.e. are subsystems tested individually or always as part of the system
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 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 (Choosing the Best Automation Strategy).
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 important not 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.
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 include 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.
The following figure summarizes the different DFT phases.
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.
In our next entry, we will discuss in detail the consequences of skipping the DFT process as we have defined here. Tack’s experience with the design to testability process can help your team design highly testable systems and transfer them efficiently to production. If you would like to discuss in more details the DFT process, or if you would like to inquire about our services or our expertise, please leave us a message at firstname.lastname@example.org.