testRigor Reviews & Product Details

What I like best about testRigor is how easy it is to create and maintain automated tests using plain English. It allows us to build complex end-to-end scenarios without writing a lot of code, which makes test development much faster. Reusable rules are also very helpful for reducing duplication and keeping our test cases easier to maintain. Additionally, testRigor enables us to cover a wide range of real user workflows and run our regression tests regularly with relatively little maintenance effort. testRigor provides good value for the cost. It helps us reduce repetitive manual regression testing, increase our automation coverage, and save significant time. While there is still room for improvement in execution stability and debugging, the overall value it provides to our QA process is strong. Review collected by and hosted on G2.com.

One of the main challenges with testRigor is test stability. We occasionally experience false positives or flaky failures, especially when the application or test environment is slow. Sometimes elements are visible but not immediately clickable, or actions fail because of timing issues, which requires additional waits or workarounds. Debugging failed tests can also be difficult in some cases, as the error message does not always clearly indicate the root cause. Improving execution stability and providing more detailed debugging information would make the overall experience much better. Review collected by and hosted on G2.com.

One of the things I really appreciate about testRigor is how much faster it makes our testing process. I often use the plain English approach to create tests quickly, but I also like having the flexibility to use different selectors when needed. Being able to choose the best approach depending on the test is really useful.

For a company like ours, where we release every two weeks, speed is especially important. testRigor helps us create, run, and maintain tests faster, which makes it much easier to keep up with our release cycle without spending too much time on repetitive testing work. Review collected by and hosted on G2.com.

Sometimes updates can change existing behavior and affect tests that were working before. We’ve also experienced occasional access issues, which can be frustrating, especially when we’re close to a release.

I also think the CI/CD integration could be more flexible. It works well for triggering and managing test runs, but having more granular options to retrieve specific data and manage or create test cases programmatically would make it much easier to integrate testRigor into our existing workflows.

The plain English approach also doesn’t cover every scenario, so sometimes I need to use selectors to target elements more precisely. It’s not a major issue, but these are a few areas where I think the product could still improve. Review collected by and hosted on G2.com.

What I appreciate most about testRigor is its remarkable ease of adoption and exceptional customer support.

Seamless Onboarding: The learning curve is minimal, making it very easy for team members to pick up and start creating tests quickly regardless of their technical background.

Outstanding Support: Their support team is top-notch. Whenever we had a new requirement, encountered an edge case, or needed assistance with a new feature, their team was always responsive, proactive, and ready to help us find a solution.

It’s a straightforward tool that truly delivers on accessibility and customer success. Review collected by and hosted on G2.com.

While testRigor was great for quick adoption, there were a few architectural and operational limitations that impacted us as our suite grew:

Limited Code Ownership & Dev Collaboration: Because it is a proprietary, codeless platform, we didn't have direct access to underlying test code. This made it harder to integrate into developer workflows or share granular debugging data beyond exporting static execution reports.

Maintenance & Refactoring Overhead: Updating tests after UI changes (like modified element IDs or layout updates) required manual, step-by-step updates within the platform interface. Refactoring broken tests took significantly more time than updating centralized selectors in a standard code-based framework.

Heavy UI Reliance: The platform was primarily UI-driven when we used it, making test suites slower to run. It lacked seamless support for backend preconditions, API-based test setups, or direct database cleanups, which are essential for fast, reliable, and scalable test automation. Review collected by and hosted on G2.com.

I really like how easy it is to create and maintain end-to-end tests using plain English. It cuts the effort of building UI automation and helps us expand coverage without spending time fixing locators. Review collected by and hosted on G2.com.

There can be a bit of a learning curve, especially when working through more complex scenarios. At times, the tool may also need extra guidance to identify the correct element or to carry out an action the way I expect. I would also like to see further improvements in execution speed and in the overall debugging experience. Review collected by and hosted on G2.com.

How easy it is to create and maintain automated tests using plain English. This makes automation more accessible to the wider QA team without needing everyone to have strong programming skills. It has helped us increase our automation coverage, reduce the time spent on repetitive regression testing, and get faster feedback. The support team has been exceptional and has made a big difference in the overall experience Overall, the value has been good compared to the cost. The biggest benefit for us is the time saved on repetitive regression testing. As we continue to expand our automated coverage, the value becomes more noticeable through time savings, faster feedback, and reduced maintenance effort. Review collected by and hosted on G2.com.

There is a learning curve when working with more complex scenarios; that is how testRigor interprets certain commands or elements in the application. Troubleshooting a failed test can take some trial and error. Review collected by and hosted on G2.com.

What I like most about testRigor is that it allows us to automate end-to-end business workflows using natural language, without heavy dependency on coding or maintaining complex locators. It helps our QA team build and maintain regression coverage faster, especially for critical customer journeys. I also like its ability to run large regression suites in parallel, which gives us faster release confidence. For our team, the biggest value is reducing manual regression effort while allowing QA engineers to focus more on exploratory, risk-based, and new-feature testing. Review collected by and hosted on G2.com.

The main challenge I see with testRigor is that some complex or highly customized workflows can still require additional effort to create, debug, and maintain. While natural-language automation makes script creation easier, troubleshooting failed tests can sometimes take time to identify whether the issue is with the application, test data, timing, or the test itself. Also, as the automation suite grows, maintaining test stability and execution time becomes increasingly important. Review collected by and hosted on G2.com.

I like testRigor because it makes automation simple and saves a lot of time. In my daily QA work, I use it for regression testing. For example, I can automate a flow like logging in, creating a contact, and checking the result by writing the steps in plain English.

I don't have to spend much time writing or maintaining automation code. When there is a small change in the application, I can usually update the test steps quickly. This helps me automate more test cases and spend more time on new features and exploratory testing. Review collected by and hosted on G2.com.

The main area I feel could be improved is debugging when a test fails. Sometimes it takes a bit of time to identify whether the failure is caused by the application or the test itself.

More detailed failure messages and logs would make it easier to find the issue quickly, especially when running a large number of regression tests. Review collected by and hosted on G2.com.

I have been using Tr for the past three years in this organisation, and I find it to be the most stable automation tool I have come across. It’s easy to convert manual test cases into automated test cases using plain English.

The team’s immediate responses to queries make them easy to reach, and we get issues resolved very quickly.

Now that Tr has released MCP, we are able to use along with our AI tools and it is easy for us to update the test cases and label runs are more efficient to trigger now. Review collected by and hosted on G2.com.

The UI can feel a bit slow at times. When we need to look into the test cases or labeled runs, we sometimes have to wait a few minutes for everything to load. Also, the pricing for the servers seems a bit high; it would be better if it were more economical. Review collected by and hosted on G2.com.

What I like best about testRigor is how incredibly accessible it makes test automation. We can write our test cases using easy, free-speech command words in plain English, which means anyone on the team can understand exactly what the test is doing. I also love that it takes screen recordings and screenshots after every single step. If a test fails, I don't have to guess what went wrong—the visual evidence is right there. Combine that with the fact that it doesn't rely on fragile XPaths to find elements, and I expect our test maintenance time to drop significantly. Review collected by and hosted on G2.com.

The error messages generated when a test fails can be difficult to interpret. Because they aren't always straightforward, I often have to rely on AI tools to translate the errors and figure out the root cause. This adds an extra step to the debugging process that feels unnecessary. Review collected by and hosted on G2.com.

Before getting into the modules, I have to give a shout-out to the testRigor support team. Their responses have been seamless, and they’ve been really helpful in understanding and resolving my queries quickly.

This was also my first time trying a true no-code automation tool, and honestly, I didn’t expect it to be this good. testRigor has been better than many of the automation tools I’ve used before. Being able to write tests in plain English instead of dealing with complex code, locators, or selectors makes a huge difference and saves a lot of time.

The regression testing part is another area I really like. It’s surprisingly simple to create, maintain, and run regression tests without spending hours fixing automation scripts. Overall, testRigor has made automation feel much more straightforward and manageable. Review collected by and hosted on G2.com.

There are a few areas where I think testRigor could be improved. The recent UI felt a little overwhelming and less professional to me because there are a lot of options presented on a single screen. A cleaner and more organized layout would make the overall experience easier to navigate.

Pricing is another concern, especially for teams with a large number of test cases. We currently have 1200 + test cases and use four servers, so adding another server becomes difficult to justify to management because of the additional cost. We don’t use the AI features heavily either we mainly draft, save, and run our tests, with some use of Claude MCP so a more flexible or usage-based pricing model would be helpful for teams like ours.

I also feel there are sometimes too many commands available for performing a single action. Having two or three well-tested and stable commands instead of many alternatives would make the platform easier to use. A few commands have also been inconsistent or flaky at times, which can be frustrating when maintaining a large automation suite.

Finally, execution speed could be improved. Compared with tools like Playwright or Selenium, I’ve noticed that testRigor can feel slower during execution. Improving performance and stability would make a big difference, especially for larger test suites. Review collected by and hosted on G2.com.