Automation is one shiny toy everyone in the technology industry is mesmerized with. From processes to hardware, we want automation to do our work for us. Someone is probably already working on automation that will help us plan more automation. But the hard fact is not every system is mature or well-established enough to benefit from automation. Automation only achieves efficiency when applied to stable environments. And there’s arguably few software environments more stable than SAP.
SAP stands for Systems Application and Products in Data Processing. Yes, maybe a boring name, but this software has defined the term since it was originally released in 1973. SAP enables real-time business processing in areas like finance, sales, and human resources. Integration with third-party databases like Oracle and Microsoft SQL were historically required, though today SAP has an in-house database called HANA that can store information.
SAP is an environment where automation is applied differently, because everything in it is a unique object that can be configured, but not customized. This means there is lots of flexibility within the system to tailor settings for your business needs, but code of the software cannot be altered. As we said earlier, this makes it very stable, but in the age where everyone wants their own personalized digital bubble, it’s also led people to open themselves to risk by integrating with other systems.
SAP’s processing power has always functioned through integration with other systems. Today that goes beyond databases to human resources portals, customer management systems, and financial dashboards. Every one of those integrations presents a risk for poor performance or a security breach, and no one is usually paying attention. Why? Because developers consider it more important to test new code, new features, and presume what has come before will stay functional. This is a safe assumption exactly up to the moment that it isn’t. What’s silly is, it would be easy to use automation to test these assumptions with little effort. Regression testing gets overlooked and ignored because it’s boring as all hell most of the time. No one wants to be the person going around after every update from every single vendor, checking to making sure no little errors have come up. It isn’t skilled testing. This is one place we recommend you start implementing strategic quality checking automation instead, and let human minds focus on more interesting problems.
SAP doesn’t have to be customizable to get complicated—configurations do that too. We met a client who was a nationally ranked university with the need to pay hundreds of staff members on three different schedules. In this case, it wasn’t an external integration that posed a risk, but rather the complexity of the internal data in SAP, and all its required interconnections. In such a system, thousands of individual approval variations must be set by department, by user, and can vary based on need.
In this instance, the university later decided they wanted to add the option to pay people quarterly. Introducing such a change represents a monumental shift in system architecture that may or may not affect other configurations. Automated quality assurance testing is the easiest way to confirm if one or more changes to certain settings will bring the whole ecosystem crashing down. When dealing in human resources and issues like employees getting paid, companies can’t afford to cross their fingers and assume.
Software quality assurance and quality testing processes in SAP are the type that are perfect for the current maturity of automation. Regression testing is exactly the kind of essential quality assurance often overlooked in SAP that no qualified testing professional wants to do day in and day out. Hence, it should be automated. Mistakes arise when a fancy unique test is considered so special that it gets automated after being run only a few times. Let the basics run themselves and let exploratory testing stay wild.