Testing, something I have never been happy about - there are just to many options. Maybe I’m a bit mathematical, a bit completist, alright perfectionist but if I can’t do it properly I don’t like to do it at all. I remember in my university days I was asked to write a “comprehensive” RAM test. Since any RAM cell could theoretically leak to any other I figured the only way was to try every combination by counting from 0 to 2^(8*4K) (it was a 4K 8 bit chip). I got an idea of how long this would take (checking every bit at every increment) when I converted the run time from seconds to years and it didn’t dent the figure much! This still wouldn’t be a complete test as it might take a fixed time for the leak to happen so the test should pause between each increment…

My latest GUI is in QT so I had a look at http://www.ics.com/products/qt/kdexecutor/index.html Which has some ideas on testing. Because of the way QT works it is possible to assume the clicks will work and then just test the event handling of simulated clicks which is a good start. Testing methods that rely on recording mouse positions (click at 300,400) and checking against bitmaps (you should get a screen that looks exactly like this) have got to be limited. Most of the bugs that get reported from customers relate to weird (ie ones I haven’t tried) settings they are using - 640×400 screens, 2000×60000 screens (OK I Lied about that one), default fonts of “Hip Hop Graffiti 3″, Korean locale…

Oh well, back to my usual GUI testing. Aim for pressing everything, in every order at every screen resolution but settle for the old company standard. (I should explain that the “old company” started out in hardware so the official testing of a unit was to power it up and see if it performed its self test successfully - indicated by a single beep. )

The old company QA standard is therefore - if it beeps ship it!