Slashdot Mirror

← Back to Stories (view on slashdot.org)

Suggestions for Performing Regression Testing?

Posted by Cliff on from the let's-verify-that-it-all-works-like-it-should dept.

gmletzkojr asks: "The company that I am currently working at develops a fairly complex industrial controller, complete with embedded software, a GUI on the controller, and a Windows app to connect over Ethernet. On previous versions of a similar project, we have performed testing manually - ie, monkey presses button, and sees that light turns on, widget turns, GUI updates, etc. However, this is extremely time consuming (previous complete regression testing took ~3 weeks) and is error prone in itself. How do you perform complete system regression testing? Do you use shrink-wrapped packages, or build your own? How do you test features that are easy for humans to observe, but not as easy for software to detect (ie, the light came on, the GUI updated when I pressed the external input, etc)?"

1 of 37 comments (clear)

  1. Testing physical devices by dubl-u · · Score: 5, Insightful

    How do you test features that are easy for humans to observe, but not as easy for software to detect (ie, the light came on, the GUI updated when I pressed the external input, etc)?"

    For the GUI, I recommend instrumenting your app so you can programatically tell what's going on. An API is one way, but a quick and dirty way is just to keep an internal event log and then probe that. Then for free, you get a detailed log you can dump if there's an error in production.

    For the physical hardware, consider building a simulator. You could do it partly in hardware, adding simulation logic to your hardware controller, but running disconnected from the machinery. Or you could build another board that connects to your production board's inputs and outputs and simulates the machinery at an electrical level. Another option is to simulate your production board entirely, leaving the embedded code out of the testing loop.

    The right choices depend a lot on where you can get the best bang for your test automation buck. Unfortunately, starting with a lot of untested legacy code means you have a long slog ahead of you. Start with the modules that generate the most bugs, or the bugs hardest to find during manual testing and automate your tests of those. That will teach you a lot about good ways to test in your environment.