By Kaelly Farnham, PathWave Solutions Manager, Keysight Technologies
Increasing test complexities are now forcing many companies to question whether homegrown test software is the ideal solution they once envisioned.
Product development cycles continue to accelerate as companies strive to keep up with competitive pressures and customer demands. Electronic design and simulation software are pushing boundaries in the test and measurement industry with integrated electromagnetic simulators, 3D layout capabilities and optimisation cockpits. As designers continue to innovate, test engineers struggle to keep up with all the data. Shorter design cycles increase pressure on validation and manufacturing test teams, who do not want to become the bottleneck in the overall release schedule.
According to a recent survey, 91% of design and test engineers spend up to six months correlating simulation data to test results. Taking the time to correlate is important for reliability and performance, but it slows time to market. Test teams are working to speed up the correlation time while still maintaining product quality. In the Testing and Validation Workflow Report from the same survey, 91% of test engineers say they use homegrown software tools for testing and validation work. So, why are so many test engineers turning to custom software scripts?
The most common reason engineers use homegrown tools is to save time. They write custom scripts to reduce the amount of manual work required and to reduce overall test time. Writing a script can reduce errors if there is a lot of manual work in the process.
Another common reason for building custom software is that not many test engineers are aware of tools that can do what they want. They want to run a specific test and they don’t know of any commercially available solutions. Sometimes engineers see a concept and want to bring it into their own workflow with custom scripts.
Finally, test engineers are becoming more and more sensitive to avoiding “vendor lock-in”, the inability to integrate various software tools, products and platforms that they may want to use, or may already be using, including legacy software and systems that they simply cannot decommission overnight.
To this last point, and further complicating matters, test engineers are using an increasing number of software tools for testing and validation. Gluing them together in a workflow requires homegrown tools. In the same survey, 48% of test engineers use three to five tools for testing, 29% use five to ten, and 14% use more than 10 tools just for testing and validation. Each additional piece of software adds time to the workflow due to importing, exporting and correcting errors.
Homegrown test software often sounds good on paper because it connects the different required software tools. In practice however, many companies realise that finding and training the right people to support a homegrown environment drains R&D resources. The amount of time and capital to maintain homegrown tools can keep resources tied up indefinitely. And what happens when the original homegrown software creators move on to a new project or company, or no longer have time to maintain the software? Although homegrown test software might solve today’s challenges, there is no guarantee it will scale in the future.
Fortunately, improvements in design and simulation software are major contributors to faster product development. Today’s rapid design cycles require a faster, more agile approach than traditional homegrown test software can handle. Today’s product designs often require more tests while test deadlines remain the same. Homegrown software cannot keep pace with the demands for faster test times. It is difficult to speed up software built for smaller, less complex tests. It is equally challenging to optimise a test flow and execution speed in a legacy system.
Modern test software environments provide an integrated suite of test automation, test project management, test station management, test monitoring, and analytics tools. With a distributed architecture, users can exchange data from a variety of stations and locations, enhancing collaboration across the product development workflow.
[Image credit: Markus Spiske for Unsplash]