Yesterday I did the real demo for my GUI automation proof-of-concept project – the one for my own group.
I explained a little about Robot Framework, and gave an overview of how it works using my demo test case for our Next Generation product. This is what a test suite looks like, and this is how you set variables, and this is how you make your own keywords. That product’s GUI is not very automation-friendly, but see, the tool can cope with that stuff. Plus it may not have to, or at least not as much, as we have a commitment from the GUI Dev manager to have his people make changes for us as we target the parts of that GUI that most need automation. Then I ran it, and of course seeing the browser with the “controlled by automated test software” banner executing the steps of the test was a crowd-pleaser.
Then I switched to the other demo I’d made, which targets the current product. The current product doesn’t have much GUI automation right now because it isn’t needed, because most of its GUI is a very thin layer over the interfaces we use for command line automation. But the GUI itself mostly is automation-friendly, so the sample Robot test case for it just needs obvious-looking SeleniumLibrary keywords with obvious-looking locator values. No xpath expressions, no Execute Javascript with weird incantations. It looks easy … because it is. And it runs on the product we’re all familiar with … that product may not need GUI automation, but there are things it would be nice to have automation for.
Then I switched back to the secondary demo test case for the nextgen product. That one demonstrates the data-driven test case style, where you execute the same test for multiple data sets. One data set is deliberately incorrect, so I could show the reporting and logging for a test failure. People liked that too.
We aren’t ready to start writing production test cases yet. The nextgen product isn’t yet ready for that, though I have a list of areas that will most need GUI automation. Also we need some infrastructure, like describing the directory structure for the Gitlab repo we’ll use for those tests, and writing coding guidelines, and establishing a Jenkins setup for test execution. Also I need to make a Robot custom library to call our command line test framework – I don’t know how soon we will need that, I am sure we will need it. But first, get acquainted.
Three hours after I’d finished my demo, someone had installed the tools, pulled the repo for the current product demo, and made and executed his own first test case, which sets configuration for a test he runs. Hey, no reason not to learn a new tool by making it do something useful to you personally.