The other day I posted about how I’m increasingly becoming a fan of the automated testing tool, Ranorex Studio. I listed a bunch of reasons and mentioned I would dive into more details about some of them.
So today, I’d like to start that, by looking at Actions.
At a simple level, Actions are just the activities or steps that you want to occur during your test. They could be as simple as a Mouse Click, or Keystrokes, or a Touch or Gesture on a mobile device, but they can also be more involved, such as Validations to decide whether the test should be considered a pass or a fail. There’s a full list in the User Guide.
One way of creating Actions is using the Recorder. The Recorder “watches” you interact with the application under test, and records your interactions with it as Actions. This is a really productive way to create tests that involved complex sequences of actions. You probably already find yourself manually performing the same steps inside an app to confirm it is working. Why not record them once and let the computer do the grunt-work.
However, this is just a starting point, as you can then go in and edit further, removing actions, adding additional ones, etc.
You can also add Code Actions, which as the name suggests, are Actions that you implement by writing code. This can be very handy where your validations are more complex and not easy to represent using the built in Validations, or perhaps you want to reference the data of the Test Case itself inside the test.
So one Test Module can be made up of both recorded Actions and Code Actions, but what I didn’t realise when I first started using Ranorex is that you can convert a recorded Action into a Code Action. So perhaps the recorded Action does most of what you want, but then you want to customise it a little. No issue. Record it, convert it to a Code Action, then tweak away.
Also, as I mentioned last time, once you have created your Test Module, whether through Recording, Code Actions, or a combination of both, you can then reuse that Test Module across multiple Test Cases. For example, you might create one Test Module for logging into your application and then use that one module in hundreds of other Test Cases that need to perform that step before doing other things.
This is not just productive for creating tests, but pays off even more when you need to change tests. Ranorex is pretty resilient to application changes (I’ll talk more about that in another post) but let’s say you make significant changes to your login screen. Rather than having to update hundreds or even thousands of other tests, you now have one Test Module to change and all the Test Cases that use it are good to go. Having dealt with other tools that break as soon as a simple change is made, this was a major benefit.
I know many dev teams either have no dedicated test resources, or not enough. This tool has allowed them to dramatically increase the testing that happens prior to a customer seeing their app, all for a license that is a fraction of the cost of hiring a tester.
If you’re interested in finding out more, there’s a playlist of videos on Actions in Ranorex here, and the section of the user guide is here.
If you’re interested in having a play with this, Ranorex have a 30 day trial available here.
