The sink is full of washing, I am wearing odd socks and I haven’t been out of the house in days. It must be time to put out that new release. But how can I be sure my testing hasn’t missed a hideously embarrassing bug? Maybe I introduced a major bug when I made that ‘cosmetic’ change at 2am?
In an ideal world I would just run a comprehensive automated regression test suite. Unfortunately it is difficult to automate graphical user interface (GUI) testing and the majority of lines of code in most applications are GUI. I estimate that the code for my own table planner software is at least 75% GUI code (not including generated code, which would push it even higher).
So I try to manually execute every line of my application before I release it. If I have to make any changes to the code, I start over again. This is very dull, but at least I have a tool to help me: Coverage Validator. Coverage Validator instruments code and shows, in real time, which lines have been executed. Click a few buttons on your application and watch the executed lines of code change colour from pink to yellow. Execute every line in the file and all the lines change colour to cyan. No recompilation or relinking is required and it doesn’t slow down the tested application too much. This real-time feedback is incredibly powerful for testing.
Unfortunately it also has a lot of shortcomings:
- The usability isn’t great. There is a confusing plethora of options for instrumenting your code that I would rather not have to know about.
- It isn’t able to ‘hook’ (instrument) all the lines of code. Whole blocks get missed out for reasons I don’t fully understand. Single line branches are particularly likely to be missed.
- The GUI isn’t great. For example, the display flashes horribly if you resize it.
- The automatic results merging is just plain weird. At the end of a session it can merge your coverage results into a previous session. This information isn’t much use to me at the end of a session. I want to merge previous results at the start of a session so I know which lines I haven’t tested.
- The GUI is quite ugly. They really need to update those tired old icons.
However being able to see line coverage information in real time is just so incredibly useful that I am prepared to put up with the many shortcomings. I just run my application alongside Coverage Validator and, file-by-file and function-by-function, I try to turn the lines of code yellow (or, better still, cyan). Every time I have used Coverage Validator I have found at least one potentially embarrassing bug that I hadn’t discovered by any other means. The support has also been responsive. It is just a pity about the flaws, without them this would be a ‘killer app’ for testing.
Coverage Validator works with C++, Delphi and VB on Windows NT4, 2000, 2003 and XP[1]. A single licence costs $199. A free 30-day evaluation licence is available.
[1]I am using it on Vista currently, and it seems to work fine.


If people buy your software in bulk they expect to get a discount. But how much of a discount should you give them? A simple formula I have seen used is:
I have belatedly got around to reading Bob Walsh’s new e-book: “MicroISV Sites that Sell! Creating and Marketing Your Unique Selling Proposition”. This is the first in a series of e-books for microISVs that allows Bob to go into selected subjects in more depth than was possible in his book “
In the 10 months that I have been writing this blog I have pointed the finger at quite a few companies I consider to be giving less than great service. I would like to even that up a bit by recommending
Ripoff: A ripoff (or rip-off) is a bad deal. Usually it refers to an incident in which a person pays too much for something. A ripoff is distinguished from a
Fraud can be a very big problem for online software vendors. Fraudsters can easily use throwaway email addresses that can’t be traced back to them (e.g. Hotmail) and IP addresses aren’t difficult to hide. Not only does the vendor lose the payment when the fraud is reported, they also often get hit with a chargeback fee. This is pretty outrageous when you think about it – the credit card companies are charging vendors for the fraudulent transactions that they themselves have failed to detect.
There are a few certainties in life: death, taxes and harddisk failure. I have no less than 6 failed harddisks sitting here on my desk patiently awaiting their appointment with Mr Lump Hammer. 2 Seagates, 3 Maxtors and 1 Western Digital. This equates to roughly one disk failure per year. Perhaps this is not suprising given that I have about 9 working harddisks at the moment spread across various machines. Given the incredible tolerances to which harddisks are manfactured, perhaps it is a miracle harddisks work at all.
We all like to think that our software is easy to use. But is it really? How do you know? Have you ever watched anyone use it? When I asked this questions to a room full of developers last year I was surprised at how many hadn’t.