Pragmatism Wins When It Comes To Functional Testing
by Pat Neary
There are lots of really cool and interesting tools and technologies that we can take advantage of as we work hard to lower the cost of running, maintaining and evolving our enterprise software applications. The challenge for many of us however, is that can be really difficult to decide which tools, technologies and ideas should be given consideration when trying to solve a particular problem. It gets even more difficult as you try to bring everything you like together as a solution to a specific problem.
The problem I spend a lot of time thinking about is how companies and teams can quickly, easily and effectively test and ensure that their package enterprise software applications meet their business requirements. Companies test when implementing and then test again and again and again whenever they apply updates, makes changes or extend their solutions. It is a big recurring problem and one that is definitely worthy of attention.
When you go to the internet and research functional testing solutions, it is easy to become quickly confused and overwhelmed. There seem to be no end to the number of companies that have different solutions to the testing problem. Each of these solutions weirdly seem to be very similar and very different at the same time. From artificial intelligence and machine learning, Robotic Process Automation and Open Source functional testing tools, it’s difficult to decide which one would be the best fit for your organization. This is because they each seem to approach the testing problem from a different perspective, frame the testing problem differently, employ different cool technologies, and then set different boundaries in respect of what their solutions are designed to achieve.
The consequence of all this is that a lot of companies (most, in our experience) have done little or nothing to improve their approach to functional testing. If they have, many have chosen solutions that are wrong for them or have not had a lot of success making their chosen solution work.
If you are one of these companies, the answer is to go back to basics – to keep it simple, “stupid”. Define what you are trying to do in very simple terms. Then choose a simple, easy to use solution.
This advice, by the way, applies to companies that have bought and are looking after their own package enterprise software implementations and to systems integrators that want to help their customers do a better job of testing, or want to improve their own testing services.