Huw Thomas, Managing Director at PMC, talks about the importance of software testing.
It is one of the most critical elements of any major IT capital deployment – yet it is the element that is often not given the time and respect it deserves.
Retail, like many industries, is littered with capital IT projects that have failed to deliver to time, quality and cost. With often, time and cost being over plan and quality under. When projects come under time and capital constraint the one element that is often sacrificed is testing. Steering groups want timescales to be met, or over-run limited so testing is often reduced or not performed as diligently and professionally as it should be in order to get the solution into the trading environment. This often happens when the software is nowhere near fit to be deployed.
In some scenario’s the value of testing is not recognised up-front and is actually not adequately budgeted into the project in a professional manner. Testing is often seen as an unnecessary cost. The vendors have assured the quality of their delivery of the development quality during the sales cycle, so why is there any need to spend all that money on testing?
The main problem arises in that once the software has been deployed, irrespectively of how well it works or how many defects have actually been let through to the live trading environment, that tends to be the end of the project. The team that have seen the project from inception through to delivery are stood down (a massive cost saving!) and move on to new things. The project is moved into business as usual and the support organisation is left to manage the solution.
End-to-end test systems built for the project are largely removed and replaced with point test environments. Future fixes have a cursory run through this minimal test system and are then largely tested in live!
The knowledge of what the original business requirements, design specification and acceptance criteria were have been lost and the support organisation are left with a mess to manage. Without a very diligent handover, it is almost impossible for the support organisation to pick up the legacy issues and manage quickly through to resolution. They often don’t have the relationships to help drive these through and post live issues often look like changes and attract a charge to fix. In this scenario, defects that should have been removed before deployment are often ‘lived with’ and the solution never quite operates as was envisaged.
Also, very few organisations actually go back and review post-deployment the cost, time, quality and return on investment delivered versus the business case that was signed off.
No wonder implementation projects get a bad name and software quality is often called into question.
I have met many retailers over the years who have still had post-deployment bugs in their trading systems many years after project completion.
All of this can be avoided through the recognition of the value that high-quality testing delivers. It is a lot cheaper and quicker to manage, resolve and confirm defect resolution in an end to end test environment than a live operating situation. It also means that the application of fixes that aren’t completely effective do not have a knock-on effect elsewhere in the trading systems.
Projects that recognise the true value of testing, that demand sufficient testing cycles to confirm software quality and that do not compromise on the time to deliver this critical service diligently, irrespective of project time and cost pressures, generally deliver a much higher quality outcome.