Software Quality Matters Blog
Why is Manual Testing so manual? It doesn’t matter who does it, manual testing is amazingly inefficient
When a developer is assigned to rectify the bug, they cannot reproduce it. Is the reason environmental?
Manual testing is intrinsically flawed, primarily because one test cycle is almost never enough. Manual testing is performed by humans and humans have a finite capacity for repetition. When an application is first delivered, the test team will commence their efforts, but after a while will reach a point in their use cases where they can go no further until the bugs discovered to date have been rectified.
Application software has always contained bugs and will continue to contain bugs for as long as developers exist. So, from the moment that the first application program was run by Tom Kilburn on 21st June 1948 (to calculate the highest factor of a large binary number) the necessity to test developed programs to ensure they work as required has been accepted.
So, for almost 70 years a significant piece of human endeavor has been testing and some of it has been fundamental to some of humanity’s greatest achievements.
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.
I’ve got your attention, right? Before I explain, I first want to thank the attendees for being so supportive. The room was so crowded, we scrambled to find extra chairs and even more people came after we started.
ASUG Ohio – “You like me, you really like me” (in my best Sally voice)
Let me start out by saying again that ASUG stands out on top for me as one of the most well prepared professional organizations. I can’t even describe how easy they make it for their presenters and booth vendors. It doesn’t matter what location, vendor or chapter… they do such a great job.