The great automation debate
This Worksoft blog caught my attention- ‘Do the Math: Automation is No Longer Optional’ – http://worksoftinc.blogspot.com/2009/01/do-math-automation-is-no-longer.html
The author is trying to put her finger on why it is that people still test manually rather than automate.
Mcfinder’s comments on the topic have started up an interesting debate on this – “The real problem for me however is maintenance of these scripts. We live in a fast paced ever changing world, every time the application under test changes the scripts that were written to originally test the application have to be re-written to accommodate the changes. This is a time consuming task and can often take longer than manually testing the application in the first place. This high maintenance burden is one of the big reasons why so much automation software is just gathering dust on shelves. As soon as the application changes the tools are useless, unless significant time and resource is thrown at them.”
I think he has a point here – It is the principal reason why our products are built with code free and self healing script technology. I wonder how many others agree. Is this the biggest hurdle to automation or are the other factors – undefined test process / unrealistic expectations bigger issues?
The Early Bird Catches The Worm
In a recent survey we commissioned, it emerged that over 40% of CIOs admitted little or no corporate regard for the quality of their software. The reasons for this have been widely debated since we announced the results and there have been some really interesting points raised – one of which being that the reason there is CIO apathy towards quality is because many are working to short-term goals.
“They will get hammered if they go over budget or miss a delivery date, but poor quality can usually be patched and covered up long enough for them to be promoted and reassigned away from the problem.” said one commentator.
There have been numerous reports in the IT press indicating we spend 70% of our total development budget maintaining existing applications. From what I see, increasing the quality of the software would decrease the cost of maintaining it. Surely, that would be of interest to a CIO?
The short term goals on cost savings by CIO would only lead long term revenue leakages due to rework, production bombings, performance issues etc. In short a Visionary CIO would never compromise on quality…!
There was a nice article on ZDNet about this issue a while back, with a great diagram showing the escalated costs of finding a bug throughout the software development lifecycle.
We all know that the earlier bugs are picked up in the application development lifecycle, the cheaper they are to fix. It is an undisputed fact. A recent article in Computer Weekly Magazine stated that the cost of poor quality “in the US alone is estimated to be upwards of $75bn a year in re-work costs and abandoned systems”. It noted that “Re-work can account for up to forty percent of the project cost, so the earlier defect problems are identified, recorded and rectified, the lower the cost”
So there you have it, ensuring you build quality into your application developments should be a no-brainer. Unfortunately your CIO might not agree with you.
did you break your toys?
Did you break your toys?
I came across this great forum post today in the Software Testing Club – http://www.softwaretestingclub.com/forum/topics/did-you-break-your-toys – about how when the writer was a young boy he would take apart his toys to see how they worked. Curiosity is often cited as one of the main traits of a tester and apparently we all do this.
It reminded me of the time as a toddler that I got hold of the mantle piece clock and took it apart piece by piece. I probably wouldn’t have managed to put it back together again anyway – even if my brother hadn’t eaten half the small clockwork parts – I was never forgiven for that!
So how many people had destroyed their Christmas presents before Boxing Day?