Last month I was in Denmark at a leading European carpet manufacturer to train and consult on Qualify, our application quality management solution and TestDrive, our 100% code-free test automation product.
Their business systems are a mix of Infor M3 heavily customised to provide integrations with multiple legacy systems. This presented no problem as both Qualify and TestDrive are technology neutral and can run over almost any application whether client based or in the cloud.
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.
There are a number of areas in the cycle of managing ERP upgrades where technology can a play a big part, but very often these are not seriously considered because: –
Testing tools are usually in the domain of IT.
The tools on the market are not appropriate for non-technical users.
IT does not need to worry about testing the ERP, that’s th
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.
On a recent training engagement with one of our customers, as is often the case, there were a selection of people with different abilities and experience who wanted to learn automation. On this specific course several of the people were automation engineers with lots of experience of coding a solution and the rest were business people with no automation knowledge.
My thoughts were that it would be easy to train the engineers but I would have to put more effort in to the business people and initially this was the case.
I have been involved in presenting and positioning and proving our software test automation solutions for some time now.
Oftentimes, the sequence of events is:
• Much effort is applied by the customer to produce an RFI or RFP which is issued to a list of test automation tool vendors
• Significant effort is applied by each vendor to respond with hopes of making the cut
• A selection is made by the customer based on some scoring about the suitability related to the responses
• The chosen vendor arrives on-site to do some sort of Proof of Concept
• If the chosen vendor works well enough, a decision is made to proceed
There are problems with this approach. The RFP or RFI that is issued is a hodge-podge of sundry, sometimes nebulous requirements that have little to do with real needs from a business perspective.
When it comes to software testing, there’s plenty to think about for IT and QA management.
Choosing the best method of software testing depends on a number of factors – for example, what are the objectives? Who is conducting the testing, and how much experience do they h
On hearing that word I was reminded of the endearing broadcasts and interviews with Jess Thom, a lovely lady who spoke about Tourettes syndrome. Her inspiring frankness and humour helped me gain a sympathetic understanding of some of the challenges associated with that condition. If you don’t know it, Google it and be prepared to smile and at the same time be grateful.