Compiler error of the week (from MSVC): 

\source\mainwindow.cpp(201) : error C2664: ‘QWidget::insertAction’ : cannot convert parameter 1 from ‘QAction *’ to ‘QAction *’

Hmmm, convert parameter from ‘QAction *’ to ‘QAction *’ - just how much conversion does that take?

If you’re interested it’s all down to my poor use of template libraries - but if they confuse the compiler that much where’s the shame in them confusing me?

QT has been part of Nokia for a while but they seem to have started making their changes. Having been bought out once or twice I can assume most of the changes will be pointless ones that make the parent company feel in control and give waste of space managers something to do (bitter? me?) but their latest mail shows signs of real innovation

• Modular architecture for feature selection
• IP communications framework based on Telepathy
• New Qt UI Test, a tool for automated system tests 
• New reference design - Video IP Deskphone

Wow, IP telepathy - makes routing tables a thing of the past…

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!