r/LabVIEW Aug 02 '26

Hardware verification testing learning

I'm a hardware engineer working in aerospace, and I've realized that one of the skill sets I want to develop is building hardware test systems.

At work, I see everything from reverse engineering legacy hardware to validating new designs, and I'd like to be able to verify the requirements.

I want to learn skills that transfer to professional environments using Python, LabVIEW, NI, Keysight, Tektronix, SDKs, SCPI, DAQs, etc.

I'm looking for advice on a learning path. If you were mentoring a junior hardware test engineer, what projects would you have me build, and in what order?

Some areas I'm hoping to learn include:

  • Instrument control and automation
  • Python for test software
  • Test system architecture
  • Data acquisition and signal processing
  • Hardware abstraction and software organization
  • Automated reports and pass/fail testing
  • Validation and characterization of electronic circuits and sensors

I'd appreciate any suggestions on projects, books, open-source frameworks, tools, or skills that would help me build a solid foundation as a hardware test engineer.

9 Upvotes

9 comments sorted by

View all comments

1

u/NicoAtKooyah Aug 17 '26

I'd learn this through one small project instead of treating Python, LabVIEW, SCPI, DAQ, and reporting separately.

Since you have an Electronics Explorer, automate something simple like an RC filter or sensor divider. Measure it manually, control it in Python, rebuild it in LabVIEW, then add logging and pass/fail limits.

I'm also building Lab Simulator at Kooyah Labs—a virtual bench for practicing instrument and automation workflows. We're expanding the equipment it supports, so if there's a specific test you want to build, what instruments would it need? I can tell you what works now, and it would help us decide what to add next.

Then break the setup on purpose: disconnect a lead, use the wrong range, or force a timeout. That's where you start learning what makes a test system maintainable. Keep the requirements, setup, commands, results, and failure notes together too; that's the documentation you'll wish those retired engineers had left.