In this episode of “The Future Of,” Jeff Dance speaks with Elijah Kerry, Software Director at National Instruments, to explore the evolving landscape of test automation. Elijah shares insights from nearly two decades in the test and measurement industry, including the growing importance of software skills among engineers, the critical role of testing for reliable hardware and software at scale, and the dynamic interplay between tools like LabVIEW and Python. They discuss the increasing impact of AI, containerization, and distributed systems, emphasizing the ethical responsibilities and cybersecurity considerations for the future. The conversation highlights the continuing evolution of test automation and its importance in ensuring technological innovation is both safe and reliable.

Podcast Transcript:

Jeff Dance:
In this episode of The Future Of, we’re joined by Elijah Carey, the software director at National Instruments, to explore the future of test automation. Elijah, thanks for joining us.

Elijah Kerry:
Thanks so much for having me.

Elijah’s Career Journey

Jeff Dance:
Great. I want to share a bit more about your background and then get your thoughts on your journey in this space. Elijah is the director of the NI Software Community and brings nearly two decades of expertise in the test and measurement industry. He’s held numerous positions at National Instruments, including Chief Product Manager for their software platform and LabVIEW, which is a significant part of National Instruments and their worldwide leadership in test automation.

I’m really excited to hear more about how you’ve contributed to their product management strategies and managed teams to accomplish big things, both historically and as we look to the future. Tell us more about your career in test and at National Instruments. How did you land there? What contributed to your focus?

Elijah Kerry:
I’m happy to share. I started at National Instruments in 2007, straight out of college, with a strong background in software. I’m a computer engineer by degree. My initial assignment, which led me into product management, involved talking to the market and our customers about how to build large, complex software. Up until that point, the market and our products were in the early stages of transformation, as our customers moved from simple laboratory automation to more complex systems.

It’s interesting to look at how things have changed. At the time, many people who didn’t identify as software people—think electrical engineers, mechanical engineers, aerospace engineers, chemists, physicists—were suddenly doing more with software as a means to their ends, whether automating or measuring something. Many of our customers were reaching a level of complexity where they had to understand software concepts they weren’t classically trained in. My initial role as a product manager was to help the market understand how to use our tools at that level of sophistication and to ensure we were investing in products to serve those use cases.

One example that comes to mind is that, back then, most test engineers had never heard the phrase “source code control.” Everyone was using zip files labeled “final” and “final2.” That was just how things were done. Fast forward to today, and I’d argue that most people building even moderately complex test engineering software are now familiar with these tools. That gives you a window into the state of things at the time. We were right there, helping our customers master these concepts and making sure our tools worked well with them. That was my initial focus.

Evolution in Test Automation

Jeff Dance:
In our eight years of working with LabVIEW and hardware test automation, we’ve seen a lot of evolution in software best practices and methodologies merging with LabVIEW and test automation. We’ve definitely seen it here as well. For our audience, many might not know exactly what test automation means. It can mean different things in different contexts, especially between software and hardware. In the context of hardware products, test automation typically refers to using specialized tools and systems to execute testing processes without manual intervention, ensuring that the hardware works efficiently and correctly. This differs from test automation in software development—like mobile app or digital product development—which focuses on software performance and breaking points. Is there anything you’d like to add to that definition for those less familiar with test automation?

Defining Test Automation

Elijah Kerry:
When we say test automation, as you mentioned, we’re talking about interacting with the physical world—testing something physical, mechanical, or electrical, rather than just pure software-based tests. The definition is somewhat self-explanatory, but there are unique challenges from having to talk to real devices and measure real signals. It’s interesting to consider how that impacts how you automate things and the nature of the software and tools involved.

Many people don’t fully understand or consider, in advance, the complexities involved in automating something that interacts with the physical world. That’s really what we do and what we’ve built a whole platform and toolchain for—to help our customers master those unique challenges. So, while the definition is straightforward, there’s a lot that goes into it. We’re really focused on automating interaction with the physical world.

The Importance of Test Automation

Jeff Dance:
For those who aren’t engineers, you can build things in many different ways. People might think software, firmware, or hardware construction is purely mathematical, but it can be very creative. Testing the outcomes and performance of something physical—or even digital—requires extensive testing to ensure stability. When you build something at scale or something critical, like a space system, you can’t afford errors. Errors can have serious consequences, and producing something at scale that doesn’t work can threaten a company’s survival.

Test automation is critical from a business perspective when considering scale and stability. National Instruments, now under Emerson, is central to this emphasis. You’ve been a big part of this space for decades now, right?

Elijah Kerry:
We’re actually coming up on our 50th anniversary, so you can expect a lot of celebrations. We were founded in 1976, and LabVIEW is coming up on 40 years. Our origins trace back to our founders at the University of Texas, Austin, who were trying to find a better way to take data from an oscilloscope. They thought, “Surely there’s a way to get this into a digital context where we can do more with it than just write it down on paper.” That was the initial impetus.

You accurately described the criticality of test. One of the interesting challenges we face, and the industry faces, is that most young engineers coming out of college, myself included, want to design and build things. No one really considers or understands the role of test right out of school. I know I didn’t. Building rockets, designing cars, circuits, writing software—those are the things that attract people to engineering.

But in industry, the notion of test and the level of sophistication and automation required is often underappreciated. People building spaceships, satellites, or cars often have to hire engineers specifically to build and write test automation systems. Many would rather design things, so part of the challenge is educating people about the role and, frankly, the coolness of test. You get to break things, push them to their limits, find failures, and improve. There’s an opportunity to help engineers better appreciate and get excited about the role of test and building these applications.

Education and Inspiration in Test

Jeff Dance:
It is fun, and you’re right that it’s underappreciated. We want to create and design, but innovation requires not only creation; it has to work. Real innovation reaches a market, adds value, and provides a return on investment. Otherwise, it’s just a concept or idea.

Elijah Kerry:
We’ve found a lot of traction working with students at universities around the world. Recently, we’ve focused more on students building something physical. For example, we had a team at NI Connect talking about their rocket project. It’s a big, interdisciplinary project, and it has to work. Those students suddenly understand the role of test as they control and test the motor controllers on the rockets. Similarly, in formula SAE or robotics competitions, students quickly grasp the importance of test.

Test Across the Lifecycle

Jeff Dance:
From my experience at our company—which is focused on design and engineering—test definitely has a cool factor. Sometimes it gets a bad reputation on the surface, but there’s a really interesting aspect to it. Pushing something to its limits is exciting. We’ve designed dozens of systems to test products at different stages—accuracy, waterproofing, and more. Developing systems to test something is fun. Robotics and test automation are closely related, and in our robotics work, we often use NI’s hardware and software for testing. When you unleash a robot, there are risks—scalability, reliability, and safety. I’m glad we’re discussing this up front.

Elijah Kerry:
Absolutely. If I can add one more thing—even though we’re still on the first question—it’s important to note that test automation is a broad term. Automating tests in a production facility making millions of devices is very different from characterizing something where you don’t fully know the failure modes. Having spent time in the EV world, for example, battery cells are a great case. There’s an element of exploring the unknown: What is the longevity and lifespan of a cell? What are the indicators of potential failure? Even within physical-world testing, there’s a big difference between lab activities with prototypes and production testing, and many things in between. Test is a critical activity that looks very different across a technology product’s life cycle.

LabVIEW vs. Python for Test Automation

Jeff Dance:
Exactly. It’s not just design, build, test—it’s design, test, build, test, and test again. Good design includes a lot of testing. That philosophy needs more attention, which is why we’re doing this podcast and why your work at universities is so important. We’ve had great engineers come out of school who took test and LabVIEW seriously, and now they understand the full life cycle of building great things. As for LabVIEW, I know you’ve been a leader from both the software and LabVIEW perspectives. How would you characterize LabVIEW’s position in test automation, especially compared to Python, which is gaining popularity? I know there’s room for both, but how do you see LabVIEW within test automation and in comparison to Python?

Elijah Kerry:
That’s a great question, and I have the right coffee mug for it. Python is a fantastic tool. Even though I’m in management, I still use LabVIEW regularly, both with customers and on my own, as well as Python and other tools. Philosophically, we’ve always embraced a multitude of tools and programming languages, ensuring our customers can use and even integrate them. But to your point—what is LabVIEW’s unique value in a world with so many tools?

There’s a reason there are dozens or hundreds of programming languages. Python is very approachable and widely used, but there’s also .NET, C#, C++, and firmware languages. The key is to use the right tool for the job. Python is fantastic for quickly getting code working, prototyping, and sharing IP. It benefits from a huge ecosystem. LabVIEW, on the other hand, was built from the ground up to interact with the physical world and has proven uniquely capable in that regard.

Of course, drivers are available for other languages, including Python, but what you do with the data and how you manage interactivity is key. Talking to one device is simple, but most test automation systems need to communicate with multiple devices—digitizers, handlers, scopes, RF measurement tools, signal path matrices, and more—often independently and asynchronously. The graphical data flow syntax of LabVIEW was designed to represent physical data and real signals, and over decades, it has proven to be the most productive and performant way to manage complex software architectures in test automation.

We support and encourage people to use Python alongside LabVIEW, but the concurrent nature of talking to multiple devices and dealing with the unpredictability of the physical world makes LabVIEW uniquely valuable for test automation. That’s just one point, but it’s a big reason why LabVIEW has maintained market leadership for 40 years.

Jeff Dance:
At Fresh, we’ve noticed the same. LabVIEW is fast, effective, and specific to the task, especially with all the different connections needed in product development and test automation. Python is broad and has a growing support infrastructure. My gut says it’s about a 50-50 split worldwide between people using Python and related frameworks and those using NI tools. Would you say that’s accurate, or do you have data on that?

Elijah Kerry:
It’s hard to put a number on the split between LabVIEW and Python users, especially since many people are successful using both in the same application. I don’t really see Python as competition. Some LabVIEW users want to explain to Python developers when to use LabVIEW, but I view Python as a complementary tool. It’s great for rapid prototyping and well-defined sandboxes, but it’s not usually what you’d use in large-scale, high-performance, mission-critical systems—especially where you care about determinism and build-time performance.

At scale, Python’s loose data typing can introduce debugging challenges when coordinating among teams. So, while Python is fantastic for quick development, you may reach a point where it’s not the best tool for reliability and performance. The big advantage of Python is its huge ecosystem and the range of use cases it covers. In contrast, LabVIEW programmers are usually immersed in the same fields with common challenges, which creates a strong, focused community. At events like GDevCon, hundreds of users come together to discuss shared challenges in test automation, and there’s tremendous value in that ecosystem. LabVIEW and the IP built around it are very targeted to test automation.

Community and Collaboration

Jeff Dance:
Thank you. I appreciate that perspective. You mentioned community, and I know NI hasn’t been part of Emerson for long. Is Emerson ramping up investment in LabVIEW, and how is the community contributing to future innovation?

Elijah Kerry:
Two good questions—what is the future under Emerson, and what is the role of the community? The acquisition by Emerson was rooted in their recognition of the tremendous value of our core business—the things that built the company in 1976, like digitizing signals and creating great hardware and software for those use cases. Emerson is focused on the core products and technology that built the company, including LabVIEW, DAQ, VXI, and all the platform tools we’re known for. They expect and support an exciting future for these products, as demonstrated by announcements since the acquisition, including increased investment in LabVIEW and a new portfolio of DAQ products rolling out now.

For the average user, NI remains as it’s been for decades. If anything, the focus on core products has been renewed and our commitment strengthened. The proof will be in the results, but we’re just under two years into this new chapter.

Elijah Kerry:
If my memory serves correctly, we already have a lot of great proof points to illustrate that, and there’s more to come. From a community perspective, as I mentioned earlier about G-DevCon, one of the most valuable aspects of LabVIEW is our community. It’s really amazing what they’ve done with our tools, events, and IP. A lot of my focus, and my team’s focus, is on empowering them. You mentioned your user group, which I had the pleasure of attending at the end of 2024. Throughout COVID and with our shifting focus in recent years, many user groups—entirely run by our community—stopped meeting. Physical events in general stopped, and many people switched to virtual.

We’ve now seen user groups come back with a vengeance in the last year, more than quadrupling the number of user groups meeting every quarter. We’re working with community leaders worldwide to increase that number. G-DevCon is, in many ways, the ultimate user group. These events are fantastic forums for people to share and exchange ideas. We have G-DevCon in Europe coming up in a few weeks, the Americas event, and I was recently in Australia. There’s talk of a few other ones starting up this year as well. But beyond just events, we’re also working with our community to tap into their enthusiasm and empower them to engage with students and universities, as well as contribute to the core IP of our products. We’ve open-sourced more and more of NI’s products or parts of NI’s library products, and we’re actively working to increase the number of open-source repositories, with a deliberate focus on empowering our users to contribute back to our products using their experience and expertise. All of these are examples of how we’re seeking to empower our community to create value for all users and the market overall.

The Future of Test Automation

Jeff Dance:
Thank you. Let’s shift to the future a bit and talk about where things are going. What do you see changing in the next 10 to 20 years? That’s a big question, but you’ve been there for a while, so you’ve probably seen some things and have a forecast for where we’re headed.

Elijah Kerry:
I’ve been here since I had a full head of hair! AI is on the top of everyone’s mind right now, understandably so. NI has announced some exciting investments into AI, but putting that aside for a moment, there is a remarkable change and evolution for the engineering community overall, and more specifically for test automation. Going back to my initial role, I was helping a lot of non-software people understand the role of software and how to manage more sophisticated software projects. We’ve seen a predictable progression as industry and our customers move from simple automation to more sophisticated applications. There’s a predictable progression of needs, challenges, tools, and team dynamics that organizations have to master to achieve their business goals.

Many customers are in different states of maturity and sophistication, evolving continuously due to market pressures, scale, or higher product volume. Over the last 20 years, we’ve taken many engineers without strong software backgrounds and turned them into software engineers. Test engineers are increasingly experts in software and its role in automating applications. Now, they’re talking about abstraction layers, containerization, distributed computing, and scaling performance and computational tasks for large manufacturing environments or sophisticated validation labs. These trends and technologies are what many test organizations are considering how to incorporate. AI, on top of all that, creates even more opportunity.

In fact, many organizations are struggling to figure out how best to incorporate AI. The obvious example is using it to develop software, but then you think about the data, system composition, and specifications—AI is transformative across all of those. NI is working rapidly to incorporate these technologies. Organizations will continue to evolve, and the rate of evolution is increasing. AI will create more opportunities for rapid transformation, and we’re working directly with our customers to make sure these capabilities are available in our products.

Integrating AI

Jeff Dance:
That’s great to hear. With how fast things are moving from an AI perspective, if you weren’t doing that, the future wouldn’t look very bright. Given your community and the fact that you’re already underway, I can see that really strengthening what you already have. McKinsey said if technology companies aren’t incorporating AI in the next three years, they might be on a path to obsolescence. That’s how fast things are moving for software and technology companies, and you guys are right at the center. LabVIEW has a visual side and a software side. Is there an aspect of AI that will impact both? So far, we’ve seen a lot of text- and visual-oriented things, but in reality, anything digital can be vectorized. That’s why we have AI music, AI videos, AI UI, and so on. Any thoughts on how visualization in LabVIEW might be vectorized or impacted by AI?

Elijah Kerry:
In a way, it already is. If you go into our tools today, you can launch our AI assistant and start asking questions about your code. The most obvious investment you’ll see is continued improvement in that area, using standard LLMs like ChatGPT under the hood. Right now, that’s focused on user experience—helping new users or those inheriting code they don’t understand, or helping find IP for a specific use case. It’s built around helping novice users ramp up in the code or libraries. As it becomes more capable and understands more context, and even generates code, it will become a far more powerful tool in a development context. All of that is on our roadmap, and thanks to the exponential increase in AI’s capabilities, you can expect rapid evolution in the product.

That’s the obvious intersection, but it’s not just about development workloads. When it comes to hardware selection, system integration, instrumentation, fixturing, and dealing with cable lengths, interference, and thermals, AI can play a huge role. Data is another area—many people generate massive amounts of data, such as when measuring battery cell impedance, but often don’t know what to do with it. Previously, the focus was on getting the “right” data; now, it’s about getting a tremendous amount and correlating it with outcomes. Using LLMs and AI, we can more intelligently predict and understand what that means for product quality and longevity. These are examples of how AI can go well beyond just development tasks in a test engineer’s workflow to make us all more productive.

The Role of Containerization

Jeff Dance:
That’s great. So, multiple points of integration for AI—right now we’re at the base case of having an assistant, but it will become much more comprehensive. Will we get to a point where you can just enter a prompt and get a lot of output?

Elijah Kerry:
Short answer: yes. You can already enter a prompt and get output. The question is, what’s the value of that output? In system architecture and complex design, I talk about “sandboxes,” especially with teams of developers. Novice developers should work in well-defined sandboxes with specific APIs and tasks that fit into a larger architecture managed by architects. AI will initially be very good at working in those sandboxes—writing scripts for specific tasks, handling string manipulation, doing calculations. Over time, it will become more capable of understanding and helping at a larger scale. AI is evolving so rapidly that it’s hard to say what it will be capable of in a few years, but for the next three to six months, we have a clear line of sight to some exciting improvements that will rapidly increase its impact for our users.

Jeff Dance:
That’s great to hear. Technology is definitely speeding up, and AI is a big part of that. It’s also converging, and that’s where it gets interesting—when you provide more context. The NI ecosystem has a lot of context, not just code, but other connected systems. The ability to do more at just a prompt is really interesting for the future. You mentioned containerization as well. How do you see that helping, especially as AI and containerization move hand in hand?

Elijah Kerry:
If you rewind to when I started in this role, software resiliency meant testing to make sure it was bulletproof. That applied to both the systems we were testing and the test software our customers were writing. Many of our customers build satellites, autopilot systems, or safety-critical devices like defibrillators or pacemakers—systems that have to work. The test software has to ensure they work, and you have to guarantee the test software works. There are software standards and regulations—DO-178, FDA requirements, automotive standards—that require resiliency.

The mindset used to be: make sure it will never fail or have a bug. As software has become larger and more complex, that’s almost impossible. Now, you want to understand risk and mitigate the most pressing risks, but also make software resilient so it can anticipate and respond to failure. Containerization is interesting because it allows you to update and manage components independently, scale them, and recover from failures without disrupting the rest of the system. Containers change the approach to large-scale test software architectures and how to make them resilient. They also affect how you automate development activities and continuous integration/deployment, which our customers are increasingly doing. We just launched a new version of LabVIEW with a Docker Hub container for that version.

Supporting Innovation and Scale

Jeff Dance:
That’s great. Containers allow us to combine multiple technologies, and as we think about AI, being able to couple that with containers means we can abstract out into larger nodes of creation or support, which becomes really interesting.

Elijah Kerry:
Absolutely. How you communicate between those containers is also important, and technologies like gRPC are increasingly relevant. We’ve done a lot to support gRPC at the driver layer and in thin LabVIEW. With AI and heterogeneous software components, you can also have heterogeneous compute—FPGAs, real-time determinism, analytics. There’s a lot enabled by distributed system architecture and user containers.

Jeff Dance:
That’s great. Any other thoughts on the future? We’ve talked about AI and containers, and how NI is preparing for the future. Any other thoughts about where things are going, especially for test automation?

Elijah Kerry:
The good news for us is that we operate in industries that are rapidly evolving. As soon as you figure out how to build something at scale, it’s time for the next iteration—the new device, new technology, new chemistry, new chip. We serve a rapidly evolving landscape of technology companies that require bespoke, custom solutions to interact with the physical world. Our technology trends and investments are driven by the technology arcs impacting our customers. Our resolve is to make sure they have the tools they need, when they need them, for the systems they’re building. AI and containerization are examples. Another trend is the sheer volume of systems and data. Gone are the days of having five test systems and walking around with a USB drive to collect data or push software. Now, our focus is on tools that can support dozens, hundreds, or thousands of systems, managing software configuration and data, and helping users understand and visualize all that data. That’s a trend I’m excited about, because these applications are inherently complex and require a new layer of management. Our product SystemLink is designed for connecting and managing all those systems.

Ethics and Cybersecurity

Jeff Dance:
That’s great. The history of hardware has been more contained and not as connected, but as we look to the future, hardware is becoming more like software, and software is becoming more like AI. Data connection and distributed systems, and getting more real-time information, is a key part of where things are going. Since SystemLink was introduced, how much has changed in that space? I imagine the future of test automation will be much the same, where we have to expect…

Elijah Kerry:
There are still plenty of customers walking around with USB drives, but everyone recognizes there’s a better way once you reach a certain level of scale and complexity.

Jeff Dance:
That makes sense. Does ethics come into play as we think about the future? Is there anything you’re worried about or that we need to think more deeply about as a community, especially with AI being connected to physical systems?

Elijah Kerry:
That’s a great question. There are obvious considerations around what data you’re using to train AI, and how you ensure the privacy and protection of customer data. We’re following best practices from leaders in the software industry. Many of our customers, especially those in secure or highly regulated environments, use their own secure cloud or LLMs and would never allow their data or code to be shared with a public LLM. For us, it’s about making sure our tools support those topologies so our AI capabilities can be integrated into secure facilities and sanctioned clouds. From a training perspective, we would never use private customer data to train our tools.

The engineering community has a huge responsibility in the types of applications we build. Test by its very nature is an ethical obligation for our customers, especially if you’re building critical systems. I’ve enjoyed my career in part because I get to see the breadth of customer applications we serve. We exist largely because of the ethical obligation our customers have to ensure that pacemakers work, ADAS safety systems respond correctly, and autopilot systems function as intended. That’s at the core of what we do.

Jeff Dance:
Agreed. We just wrapped up a project for a medical device company where we spent six months running hundreds of tests to get something ready for FDA acceptance. People have no idea what goes into that level of testing, but NI plays a role in supporting the ethical underpinning of reliability, security, and privacy, especially as we integrate with AI.

Elijah Kerry:
From a hardware perspective, we strive to provide best-in-class performance and accuracy so the data you get is good data. I should also mention cybersecurity. It’s a huge focus for us, driven in part by aggressive regulations from the European Union around cybersecurity and software resilience. We’re investing significant resources into ensuring our customers have all the data and artifacts they need, and that we’re strengthening the security of our tools and technologies. Cybersecurity is a very big focus for us as a company.

Jeff Dance:
AI has given attackers more power, so we need more planning, foresight, and implementation to counter what’s coming. We’re already seeing that, and I think that wave is just starting. Thanks for that. Just a couple of closing questions: Are there any other advancements in test automation that you’re excited about, either now or for the future? And what’s been really rewarding for you in your career in test automation?

Key Investments and Rewards

Elijah Kerry:
There’s a lot to be excited about from the NI perspective. We’re making exciting investments into our products, and Emerson has given us renewed focus on our core technologies. We’ve already talked about some of the key technologies and investments I’m excited for, including Nigel and our AI tools. We also have a new portfolio of DAQ products, including NeoDAQ. I don’t want this to sound like a sales pitch, but the investment into our core products is compelling, and I’m buoyed by the enthusiasm I’ve seen among our customers.

As for what’s been rewarding, I love that question. Part of why I’ve stayed in this field so long is that I have a front row seat to some of the coolest applications in engineering. I’m a technologist at heart—I love technology, engineering, and what it can do for humanity. I’ve had the good fortune to see the Large Hadron Collider deep underground in Geneva, rocket engine tests, and to visit customers around the world. The shared nature of the engineering community and our users’ passion for what they do, and the role our products play in enabling them, is amazing. People like our products because they enable them to do these incredible things. I get out of bed in the morning because I want to make sure our tools are still the best for building amazing applications. I genuinely love every opportunity to see how our products power transformative applications. Whether it’s the Hadron Collider or the National Ignition Facility at Lawrence Livermore, it’s exciting to see how engineering advances outcomes for humanity. We’re making the world a better place, and I genuinely believe that.

Closing

Jeff Dance:
That’s great. You guys are in a unique position—test is so important to the future of physical technology development, and as a world leader in that space, you get to see what’s being worked on for the future. You really do have a front-row seat to exciting innovation. Elijah, thank you for your insights, your dedication to test automation, and your perspective on the future and the ethical underpinnings of this work. We’re grateful to have you on the show and for the preview of the future of test automation.

Elijah Kerry:
Thank you so much for having me.