TestRigor - Review

Full honest disclaimer: I haven’t used many no-code automation tools, and the ones I’ve used have always been just out of curiosity, and I never went deep into any of those tools until now. I’m a QA who’s mainly focused on working with coded test automation frameworks and never had much time to look into such tools. So when the folks from testRigor approached me with a question if I would like to try out their tool, I was curious although a bit skeptical.  

While in the past I disregarded any no-code automation tools, as I didn’t have a need for them, in more recent years I’ve become more open to the idea of giving such tools a try. There is a time and place for everything, and coding a complete automation framework can be a waste of resources - unless you produce it exceptionally specific in terms of testing. Hence, you need to utilize all the customization that is available to you. One of the reasons I changed my mind about tools like this one, was the fact that a couple of people in the testing community (Hosts of the AB Testing podcast to whom I look up to) suggested that these tools can be helpful if used in the right context.

Tools like testRigor can help when we have fewer technical testers who aren’t comfortable with coding. It turns out that the technology has come a long way in recent years, and given my recent experience, such a tool can be an excellent choice for UI automation. Compared to an older tool like Selenium, it takes virtually no time to set up, and test creation and test maintenance are much more streamlined as well. So it might be worth looking into your automation requirements and considering a codeless tool - as it might be the most efficient and budget-friendly option.

Apart from having quite a lot of handy features, like checking the steps of the UI tests and viewing the details, what I liked the most is the fact that test steps are being created in plain English language, just check this simple test case I made for experimentation purposes:

You can either record tests by simply using the browser extension, or write them from scratch - completely codeless in both cases. This is something that can be very useful for the whole team, including business-oriented people, like Business Analysts and Product Owners. So they will be able not just create, but also get back to the test and edit it at any time. Also, if you do things “right” and cover most of your business logic at lower (faster and cheaper) test levels, you could have fewer crucial end-to-end UI tests, which can be recorded with a tool like testRigor to save additional time.

So to sum it up, testRigor looks quite promising, and I think it might be a great choice for certain products. Analyze your context and needs, and you’ll find that often it’s way cheaper to use a tool that can help you speed up test creation and execution rather than building everything from the ground up and re-inventing the wheel.