Testing

This is probably not the perfect analogy, because at some point you will have to stop and change the tyre. But it may be if you don’t do it quickly, there will be a much nastier outcome and expense.

However, looking at the things that can bring benefit with minimal effort, it is possible to make progressive incremental changes which buy you time from the outset and start you on the journey to greater savings. If the majority of your testing is currently manual, then adopting in the first instance technology that makes this less manual (less effort) is an easy and quick win

If something important on your car needs fixing, you do it. You don’t really have a choice because you need your car. It’s the same with your ERP platform, but often senior management don’t look at the details of how you do it, the internal cost of doing it or the fact that the process might be less than ideal with unnecessary risk of failure. It’s been a long time since I’ve done any car maintenance and whilst it might be a lot cheaper for me to do somethings the risk is too great.

Persuading senior management to invest in technology to improve, reduce cost and de-risk should be easy, but in reality, it often takes a good deal of selling.

In the ERP world, whether on-premise, private cloud or SaaS cloud the impact of any change is not as clear or easily understood as it might have been in a home-grown application. The risk is magnified because a third party is making changes to an expensive system, which is critical for running the business, providing changes that we probably did not ask for, that we don’t understand, that may impact other integrated systems and that might have hidden features which can bring business to a standstill.

So, whereas before we relied on quality being determined by effectiveness and good practice across a number of stages in the Software Development Life Cycle (SDLC), the responsibility for quality “Shifts Right” exclusively to the function of testing. At the same time, the testing team may have been reduced, or more probably the emphasis placed on the business in User Acceptance Testing, that is even further “Right”.

The business users of course are best placed to spot the unwanted features and issues having the best knowledge of how the processes work, but they are not professional testers, they don’t think like testers and are not likely to carry out the most effective quality assurance process. Not without help anyway. Do they get that help? Help in the form of planning, management, analysis, training and technology? The answer is likely to be at best; “partially”.

One of the reasons for buying an ERP style application (typically at vast cost) is the avoidance of the development effort that goes with designing, building and maintaining home-built applications. There is also potential for fewer staff in all roles such as Business Analysts, Systems Architects, Programmers and Testers. This on-going cost reduction and the added benefit of a readily available flow of the latest market-led features means you will have a modern, bug free, up to date platform to support current and future business needs, at a fraction of the cost of the old system. For these reasons, the painful price tag becomes acceptable and the ROI case a matter for the accountants and crystal-ball gazers.

The reality may turn out to be a little different to this enticing vision, particularly when considering the effort, and associated cost involved to move to this new world. When looking back it may transpire that the investment made has ended up being greater than anticipated. That is not to say that it is not worthwhile, but just more costly, possibly considerably more costly, than was expected. The result is that the new ERP, and this includes upgrades or migrations not just new installs, is now of even greater financial significance because of this major investment.

I absolutely love reading testing blogs… they tend to focus on the future of testing and the advances we can make to get to market quicker. But, is this just a dream? The reason I ask is that I feel the frustration coming from software testers and their leaders that they are not valued when I meet with them.