For years, engineers have neglected the "design" part of design-for-test. DFT shouldn't be an afterthought and test engineers can take on some of the task.
Design engineers need to be aware of the manner in which functional board and system tests will be performed and analyze their fault coverage and fault isolation capacities. This is no small task, and it's not surprising that many designers (and their managers) simply forego this activity—waiting for feedback from test engineers to do this during test program development. But by that time, the design is mature and with design changes costly requests for change will probably be denied.
For decades designers wanted "as little as possible" DFT. Why? Because most of the testability issues only surface during the test development stage and by then, it's too late and/or expensive to make changes. If the paradigm changes so that it is test engineers who do the testability analyses and they do this during the design, there will be less resistance from designers and their managers.
The main reason testability analysis is missing during the design stage is probably because the designers feel they have more important things to do in the short design cycle and test does not appear to be a priority this early. So even those supporting DFT wait to hear back from test engineers when test programming difficulties arise. The best way to satisfy both design and test requirements is to have both activities performed together, in parallel and iteratively.
Many aspects of the test design can be performed prior to design finalization. For example, developing the test strategy and the mix of tests selection can be performed with some understanding of the scope available even at the block diagram stage. This is also a good time for the test engineers to learn the detailed functionality of the UUT. The test equipment and its specification can be determined without the actual design details. Furthermore, as design implementations are progressing, the test engineer can begin procuring test equipment, designing the UUT/tester interfaces and creating a test flow diagram. Any impediment in these activities that are caused by specific design choices can result in a design change that is far less painful than any that would occur later. The process may be iterative in some cases, but it does not necessarily mean that design completion is going to be delayed.
Test development times, including the time spent on testability analyses and recommendations, will likely be substantially smaller. More importantly, tests will be available faster and time-to-market will improve. The added costs will be limited to the time designers spend on implementing testability recommendations. That's likely to be a small fraction of the entire design activity. Such time will be far lower than it would be if the design was first finalized and then changes were made to improve testability. Moreover, the DFT analysis, while implemented by the designer and during the design stage, will actually be performed by DFT engineers, who are more suitable for the task.
Designs with this type of parallel organizational activity can have the best of both worlds without appreciable cost impact. The benefits will greatly outweigh any of the costs and annoyances that this organizational change may crate. Finally, testable designs can be produced in less time and will continue to reap benefits from better testability and supportability throughout the product life cycle.