Change Happens, Deal With It

My first set of Robot Framework based tests have gone live, providing some data correctness regression for a feature of a still-under-development product. Those tests are implemented using REST, not GUI, which is not where I thought I was going with this stuff. Hey, priorities change, and sometimes they drastically change what you’re doing: deal with it. (And sometimes it turns out to be fun!)

I started learning Robot because I thought I’d need to do GUI automation for this new product, because unlike the current product, there’s business logic in the GUI. OK, let’s learn how to do GUI automation!

And then … the various powers-that-be, including my boss, had a collective reality check concerning time frames, priorities, how many people are available, and how much support is required for the existing product. Both current and new products exist to provide information to end users, and that information had better be accurate. So data correctness is THE important thing, for both. The current product has a huge library of data correctness regression tests of various kinds, implemented with the in-house command line testing framework. The new product needs data correctness tests, and automated regression for them, more than any other kinds of tests.

Drop the GUI automation stuff. GUI is not a good vehicle for data correctness automation. We’ll do GUI automation eventually, but not right now.

One class of data correctness tests can be automated using the same REST interfaces that the GUI uses. The in-house framework actually does have some support for calling the new product’s REST interface, which got implemented a while ago during a previous attempt to build this new product. So using that was an option, but I knew Robot has libraries for REST (just not as extensive as for Selenium), and I was really liking working with Robot. And my boss really liked the idea of us working with some new-to-us tools, so sure – REST automation using Robot, and a secondary output of the effort is that it will be an example to show other people in our group how to do it.

This is my first experience with REST and I’ve had a blast doing it. The “Exploring Service APIs through Test Automation” course by Amber Race at the Test Automation University https://testautomationu.applitools.com/ was very useful for me, and the RESTinstance library for Robot https://github.com/asyrjasalo/RESTinstance has been fairly easy to deal with. I uncovered a few product bugs while doing the manual verification for each of the initial test cases, and will likely find more as I add test cases. I am pleased.

I’ll get back to GUI testing eventually. Meanwhile my crude little demo project for Robot GUI automation for the current product has been useful – one of my colleagues started with that and turned it into something that is doing useful work for him, setting up stuff for manual verification. I am pleased.