Anna Thorsen
The answer to this commonly asked query comes down to two simple answers: yes and no. If you are using a desktop version, then no. If you are using a web version of SAP, then yes, you can use Selenium. But it’s not ideal. Here’s why:
Automating SAP using Selenium and why you shouldn’t
Selenium is a great tool. It’s open-source which means you don’t have licensing costs. You can extend and modify the source code, and it supports multiple programming languages. And while that sounds great on paper, in practice, it’s difficult to set up and use, leading to high start-up costs.
The biggest time sink is in the maintenance of an automation framework with Selenium. Test development is slow, and once a test has been built it requires constant updating to make sure it is not spitting out false positives. This makes it an unreliable solution for quality-focused businesses.
And finally, if you’re using a non-web version of SAP, it won’t work.
Why Selenium doesn’t work with a desktop-based SAP system
While some businesses have transitioned to the cloud-based SAP solution, SAP S/4HANA, not all have.
The transition can take years, and with a deadline for 2027, we’re still some way away from all SAP customers being fully in the cloud. Hence, using Selenium for testing SAP isn’t possible. This is because Selenium is a browser-based API, which means it does not work outside of a browser.
There are, however, other solutions for testing SAP with automation. We’ll cover that in the next section.
Automating SAP
Some of the options available for automating SAP are through commercial solutions (you can read more on that below, linked here). However, there are also open-source and SAP-owned solutions available.
- Selenium. To get Selenium to work with a non-browser version of SAP, it is possible to “use the built-in SAP GUI recorder to record VBScript. The VBScript can then be daisy chained with Selenium scripts for end-to-end browser-based tests. This approach is not recommended as it requires heavy maintenance and will become a time-sink for important developer resources.”
- SAP TAO. Another option is SAP TAO; however, the SAP-owned test acceleration tool will soon be decommissioned. You can read more about SAP TAO in our extended post.
- eCatt. SAP’s tool for integration and functional testing with the ABAP script editor. It’s often used for regression testing too. The benefit is that it doesn’t require additional licensing costs, but it is limited to SAP UI and API, and HTML is not supported.
Commercial test automation solutions
Commercial solutions fall into three buckets. You have heavy code, low-code, and no-code solutions.
- Heavy code. To build your automation you are dependent on developers or quality assurance (QA) managers that have coding experience. You’ll be hard-pressed to find a developer that would spend his time on a quality assurance task when their time could be spent building new features or fixing bugs. QA managers with coding experience are hard to come by, and those that are available come at a cost. In this case, you must invest in a tool and the resources needed for this tool to succeed. That’s not a very attractive proposition for the stakeholders involved in passing this investment.
- Low code. The benefit of low-code platforms is that developers can hard-code any part of the system, and non-technical users can automate up to a point. More complicated tests will still require heavy maintenance and developers to build.
- Codeless test automation. Codeless automation for testing gives non-technical testers the autonomy they need to build automation. No coding required. Usually, codeless test automation uses smart recorders and drag and drop boxes that imitate user interactions with a computer. They are designed to make the automation process faster and easier, with less maintenance.
What’s the best solution for automating SAP?
The answer to this question will differ depending on the organization.
If you have a wealth of developer resources available that are given the green light to write a test automation script or a QA team with a high level of coding experience, a code-based testing solution may work for you.
If you have a strong testing team, in the sense that they are very familiar with SAP processes on the front-end, but they don’t have coding experience, then a codeless solution may be a better option.
If you are opting for a codeless solution, here are some of the capabilities to consider:
- A short learning curve. Does the solution have a short onboarding period that enables those with non-technical experience to set up test cases?
- Integrates with agile setup. Can the solution work in an agile setup like a scrum, DevOps, and CI/CD?
- Scalable. Can you scale the solution beyond siloed projects? For example, you may need the tool to regression test your system which could include end-to-end tests across non-SAP systems like Salesforce.
- Cross-technology automation. Can the tool work across web, mobile, and desktop apps and technologies?
- Easy to maintain. How much maintenance is required to upkeep tests and ensure their reliability? Is it possible, without development intervention, for non-technical users to find and fix issues in the automated tests?
To find out more about testing SAP with codeless automation, watch our on-demand webinar with consultancy NNIT. In the webinar, you will see a demonstration of no-code SAP automation, and learn about ensuring the continued functionality of business-critical processes.
