Basics of testRigor

Basics of testRigor

testRigor is a modern test automation system that uses artificial intelligence to enable virtually anyone to create automated tests for web, mobile, and native desktop, and make those tests stable and reliable.

Unlike many other test automation tools, testRigor doesn’t require a complex and time consuming framework setup. Just select a new test suite and specify the parameters such as name, type of testing, url to run tests against, login credentials, OS, etc and you’re ready to start creating test cases.

The scripts in testRigor are written in plain English with a few requirements:

  1. Each command used should look exactly like it’s shown in the documentation.
  2. Each step should always be on its own new line.
  3. All parameters should be in double quotes.

testRigor works with elements on the screen that are visible to an actual user. In most cases, there’s no need to identify element locators, and simply refer to elements as they can be seen on the screen (more on that in upcoming sections).

testRigor supports all types of commands that we normally use in day-to-day life: click, type, scroll, enter, hover, reload, drag etc, as well as many others.

All tests are executed in parallel, meaning that all tests within the test suite must be completely independent from each other.

Users can create test cases in testRigor through four primary methods:

  1. Writing the test case from scratch using plain-English commands (Details can be found in the documentation section here. This method is also the primary focus of this course).
  2. Recording web test cases using our Chrome test recorder.
  3. Generating test cases based on testRigor’s generative AI model (discussed in the AI and Prompt Engineering section of the course).
  4. Live mode is an upgrade to the recorder which creates a test case while the user interacts with the page while testRigor’s server maintains a live connection. Live sessions do not stop when a step fails, and only steps that passed remain part of the script.
Primarily via element locators (such as XPath and CSS selectors)
Through manual input during each test execution
By importing element databases from third-party applications
By referring to elements as they appear visibly on the screen
Using the name attribute of the HTML element
Sequentially, one after the other
Only after manual approval for each test
Based on their complexity, from simplest to most complex
In parallel, without a set order