Test automation from MS Excel
By: Bernhard Buhl
Tags: Selenium, Test Automation

baangt screenshot

Automation testing can be tedious and costly. To test a critical business functionality depending on the size of your organization and the number of back-end systems you may have many roles working on securing proper application behavior before and after deployment, but the outcome is not always satisfying.

Why does automation testing need to change?

Ideally people who worked on user stories or functional specifications would be the best authors of test cases for automation purposes. Unfortunately today’s tools are not easy enough to use. People need trainings, additional software on their computers and a lot of knowledge about testing processes. Apart from that, the amount of parameters and their combinations, that influence system behavior can be overwhelming to master and keep track of.

Developers on the other hand should produce value and not spend their time with creation of E2E test cases, which usually require wider knowledge of systems, data and business processes than the developer of a single functionality has or needs.

So companies hire professional testers, who will — based on their natually limited domain knowledge, a few artifacts from the last sprint and a lot of sweat and tears — create test cases. This is quite some additional investment for the company, but in the end we all prefer stable productive systems to loads of new JIRA tickets after each release, right?

Companies go down this road a lot. The success is not always according to the expectations or according to the invested time, energy and money.

The reason is not, that external testers are incapable of doing their job. The reason is the missing deep domain knowledge, that is required to prepare meaningful test cases.

Photo by JESHOOTS.COM on Unsplash

Another approach that doesn’t work

Usually 3–6 months into the experiment with external testers the frustration levels are high. Apart from increased costs the quality of deployments didn’t improve. 1000s of test cases were designed, written and executed. More hardware was dedicated to automation testing. CI-Tests are running for longer than 1 hour after each commit, and developers complain about reduced productivity due to long wait times for the builds and switching costs between tasks. Still the pain is not gone, it even increased because it now takes even longer to bring new features. Deployments to production bring new loads of tickets, old errors reappear with new parameter constellations. On top of that, automation costs increase as more and more test cases need to be adjusted with each change of the UI or API or Back-End system. A vicious circle.

Bring in the knowledge of business people

How helpful it would be to have those gems define test cases with all needed parameters and values? Real test cases with real values. Not some random guesses. Wouldn’t it? But how you ask?

Photo by Marten Bjork on Unsplash

Chances are, people with the deepest knowledge of internal data flows and business processes have at least occasionally used Microsoft Excel (or similar software). That’s all it takes to harvest their knowledge in order to build great regression tests — no matter how complex the scenarios.

baangt to the rescue

baangt starts, where unit tests stop — when it comes to test valuable business processes. All you need are your business people, MS Excel (or similar software), Chrome or Firefox with an Addon to record their steps and access to baangt (on a single computer, a server or docker, on-premises or in the cloud).

15 minutes of YouTube videos should be enough to get anybody with basic computer knowledge started to record test cases. After recording, use baangt importer to extract the data associations for this specific test case and fill in all relevant test data combinations in a simple MS Excel sheet (the sheet is pre-filled with columns and the line from the recording).

Sometimes tuning beyond the capability of business people is needed, in those cases you can hire an expert for a few hours. Often the built-in functionality (e.g. IBAN Generator, Date/Time-Generators, String generators with various options) is already enough for full E2E Testing of corporate applications.

As the test case definition and the test data is in the same file, it’s very easy and simple to adjust both when the underlying system or functionality is changed/updated/improved.

How to deal with different versions of software on different stages?

Photo by Yancy Min on Unsplash

Don’t worry. You’ll not have to copy your test case definition or data when you have different versions of software in different stages (e.g. Dev-System, Pre Quality System, Final Quality System, Migration-Systems, etc.). Each execution line in the Excel sheet has an optional parameter “Release”. Before you execute a certain test case on a certain stage you’ll tell baangt, which Release is deployed to this stage. The rest runs automatically.

1000 business people in 10 different locations?

Worried about lack of reuse of their knowledge or building of knowledge silos, difficult to reproduce results, developers not being able to reproduce test errors on a specific stage?

Photo by Lanju Fotografie on Unsplash

If your organization is that big or complex you’ll want centralized management of test cases, test runs, resource usage and hopefully integrate your tests centrally into CD/CI pipeline. You should take a look at baangtDB. baantDB runs on exactly the same core functionality like baangt and additionally provides a central stage for administration (and reuse!) of test cases and test data. Now you think “OMG! Sunken costs again, when we move from Excel based solution to baangtDB”. Don’t worry. baangtDB and the Excel-based solutions are 100% interchangeable. Import Excel to baangtDB or export from baangtDB to Excel with one click and without loss of data or manual processing.

When the core is not enough

Test engineers and especially developers are still needed. So your system landscape includes Mainframes with 3270 Emulations, some SAP-Systems, some JAVA-Backends, some fancy JS-Frontend like Vue.JS, Angular, IOT-Concentrators and all that stuff, that makes testing actually interesting?

You’ll not find support for every unique requirement in baangt. But whatever it is — as long as it is in reach of a computer or robot — it should be easy to be implemented. baangt can be easily enhanced by plugins or so called “subclassing”, where a developer overrides code from the standard modules and enhances with custom functionality.

How much does it cost?

Yeah, right. A versatile solution to bring business people and developers closer together via test cases and test data combinations, that runs on pretty much any platform with any browser and can even be enhanced to fit specific needs would usually make you cry like a little child, when you see the per seat license costs. baangt is not only free (not even freemium. Just free.), it’s also open source. No hidden data collection, no hidden fees, no dependency to a producer of software.

What stops you?

If you have a good answer, please let me know in the comments. If not, head over to baangt and see, if the solution eases your pain.