Question

(Cross posting from softwaretestingclub) I am testing a touch screen driver for an embedded device, unfortunately it is tightly coupled to the hardware so simulated data can't be pushed in real time in order to simulate real usage. Theoretically the resistive Touch Panel itself (the thin transparent layer) can be replaced by digitally controlled Potentiometer and some logic, anyone has experience with such arrangement or can assist with ideas ?

Answer 1

This is something I bet most folks don't run across every day!

As you indicate you aren't testing the resistive screen itself you are testing the driver that converts the voltages produced by the resistive screen to a device driver that then converts those DC-volt values into system events.

In one of our teams we used a robotic 'finger' to cycle the power of laptops automatically. But I don't think that would really be useful in your case.

I would probably give up on the idea of 100% automation; 100% automation is mostly a foolish pursuit.

Instead I would focus on testing the device driver by simulating voltage values and then relying on manual usability, exploratory, and scenario testing to make sure the device (the resistive touch screen) communicates as expected with the device driver (the actual thing you are testing) and the driver sends the appropriate events to the system (where your driver is installed).

You might want to check out http://www.embedded.com/columns/technicalinsights/164303539?_requestid=468858 and http://msdn.microsoft.com/en-us/library/ms894768.aspx

Answer 2

I'm going to go out on a limb here and start to answer a different question.

Your biggest problem isn't finding a way to simulate interaction with the hardware. Certainly it would seem you need to solve that problem, but your main issue seems to be testability. Is there a way to modify the system under test such that you, as a tester, are actually able to do your job in a reasonable way?

Alternatively, do you have sufficient tools to test embedded software? How are your developers writing and testing the code on their end? Are you able to get those tools and use them in a more detailed test capacity? Are you able to get a project board with the embedded driver loaded, attach some buttons, and poke around to see what happens? (I'm betraying my lack of experience with embedded systems here, but I believe the idea is sound.)

Additionally, if you focus your testing on the interface alone, some enterprising hacker down the road may discover on your behalf that there are ways of working around the interface in potentially nasty ways, without ever laying a finger on the screen.

Certainly there exists a need for overall integration testing, but building a device solely intended to prod a touch screen seems like a pretty big investment for something that could be done manually as needed. Focus on figuring out how to hit the code at the next level down.