- Home
- testRigor Tutorial
TestRigor Tutorial
Master testRigor — the AI-powered no-code testing tool that lets anyone write automated tests in plain English. No XPath. No code. No maintenance headache.
Key facts about testRigor:
What problems does testRigor solve?
- 1Test maintenance nightmare In Selenium/Cypress, every time a developer changes a button's ID or moves an element, tests break. testRigor tests are written from the user's perspective ("click Login") so they survive UI changes automatically.
- 2Only developers can write tests Most tools require Python/Java/JS knowledge. With testRigor, manual testers, BAs, and product managers can write tests directly in plain English — no training needed.
- 3Slow test creation Writing Selenium scripts takes days. testRigor tests take minutes — even complex flows with email OTP, 2FA, and API calls are just a few plain English lines.
- 4Low test coverage Because automation is hard, many teams stay at 30-40% coverage. testRigor customers regularly reach 90%+ coverage within months because anyone can contribute tests.
How a test runs — step by step:
click "Login" | enter "test@email.com" into "Email"
Parses English, understands intent, locates elements by what they LOOK like on screen
testRigor internally generates Selenium/automation code — you never see it
Cloud infrastructure runs the test — screenshots, video, logs captured
Key AI capabilities in testRigor:
| Feature | 🤖 testRigor | 🌐 Cypress | 🔧 Selenium |
|---|---|---|---|
| Language | Plain English | JavaScript | Java/Python/C#/JS |
| Who can write | Anyone on team | JS developers | Experienced devs |
| Locators needed | ❌ No locators | CSS / data-testid | XPath / CSS / ID |
| Maintenance effort | ⭐ Near zero | Medium | High |
| Setup time | Minutes (cloud) | 1–2 hours | Hours to days |
| Mobile testing | ✅ Built-in | Limited | Via Appium |
| API testing | ✅ Plain English | cy.intercept() | Not built-in |
| Email/SMS testing | ✅ Built-in | ❌ Not available | ❌ Not available |
| 2FA / OTP testing | ✅ Built-in | ❌ Complex plugins | ❌ Manual workaround |
| Self-healing | ✅ AI-powered | ❌ No | ❌ No |
| Suitable for | Non-tech + tech teams | JS-based web projects | Large enterprise teams |
Step-by-step — Creating your first Test Suite:
- 1Sign up Go to testrigor.com and create a free account. No credit card needed for the free tier. Login to the testRigor dashboard.
- 2Click "Create Test Suite" A Test Suite is a container for all related test cases — think of it as a test project. Give it a descriptive name like "Login Tests" or "Checkout Flow".
- 3Choose the testing type Select from: Desktop Web Testing (website on computer browser), Mobile Web Testing (website on mobile browser), or Native and Hybrid Mobile (Android/iOS app). This determines how testRigor sets up the environment.
- 4Enter the App URL Paste the URL of the website you want to test. testRigor automatically opens this URL before each test case — no need to write "open url" in your tests.
- 5Add login credentials (optional) Enter username and password for your app. testRigor stores these securely. Then in any test case, you just type the single command login and it handles the entire login process automatically.
- 6Choose OS & Browser Select the browser combination (e.g., Chrome on Windows, Safari on macOS, Chrome on Android). testRigor runs tests on its cloud infrastructure using real browsers.
- 7AI Test Generation (optional) Provide a short description of your app (e.g., "E-commerce website selling electronics"). testRigor's Generative AI automatically generates initial test cases in plain English. You can edit or add to these.
- 8Add Custom Test Cases Click "Add Custom Test Case", give it a description (e.g., "User can login with valid credentials"), and start writing plain English test steps in the text area.
Core commands cheatsheet:
click "Submit" // click button/link by text click "Login" double click "item" // double click long click "Delete" // press and hold right click "image" // right click click "Forgot Password" link // specify it's a link
enter "priya@example.com" into "Email" // type into field by label enter "Test@123" into "Password" enter "India" into "Country" // selects from dropdown too clear "Email" // clear a field type enter // press Enter key type tab // press Tab key
open url "https://example.com" // navigate to URL scroll down // scroll the page down scroll up scroll down until page contains "Add to Cart" // scroll until found scroll to "Footer Section" // scroll to element go back // browser back button refresh page // reload current page
hover over "Menu" // hover to reveal dropdowns hover over "cart icon" using ai // AI finds by visual description drag "Item A" to "Drop Zone" // drag and drop check "Remember Me" // check a checkbox uncheck "Subscribe"
Example 1 — Login test:
// Test Suite URL is already set to https://myapp.com // Login credentials stored in Test Suite settings login // one word — auto enters username + password + clicks Submit check that page contains "Welcome, Priya" // verify dashboard appeared check that page contains "Dashboard"
Example 2 — Invalid login (negative test):
enter "wrong@email.com" into "Email" enter "wrongpassword" into "Password" click "Login" check that page contains "Invalid email or password" check that current url contains "/login" // still on login page
Example 3 — Full e-commerce flow (search → add to cart → checkout):
login enter "Samsung Galaxy S24" into "Search" type enter // press Enter to search check that page contains "Samsung Galaxy S24" click "Samsung Galaxy S24 Ultra" click "256GB" // select storage option click "Titanium Black" // select color click "Add to Cart" check that page contains "Added to cart" click "View Cart" check that page contains "Samsung Galaxy S24 Ultra" under "Your Cart" check that page contains "1" in "Quantity" // verify qty is 1
// ── PAGE CONTENT checks ────────────────────────────────────── check that page contains "Welcome, Priya!" check that page does not contain "Error" check that page contains "Order Confirmed" under "Order Summary" // ── URL checks ─────────────────────────────────────────────── check that current url is "https://myapp.com/dashboard" check that current url contains "/dashboard" check that current url does not contain "/login" // ── ELEMENT checks ─────────────────────────────────────────── check that "Submit" button is visible check that "Submit" button is not visible check that "Submit" is enabled check that "Submit" is disabled check that "Remember Me" checkbox is checked // ── FIELD VALUE checks ─────────────────────────────────────── check that "Email" field contains "priya@gmail.com" check that "Quantity" field value is "3" check that "Total Price" contains "₹29,999" // ── TABLE checks ───────────────────────────────────────────── check that table "Orders" contains row with "Order #12345" check that table "Orders" has 5 rows // ── CONDITIONAL assertion (soft check) ─────────────────────── if page contains "Accept Cookies" click "Accept Cookies" // continues even if "Accept Cookies" is not present
How to create a Reusable Rule:
- 1In the Test Suite, open the "Reusable Rules" tab This is separate from the Test Cases tab. Click "Add Reusable Rule".
- 2Give the rule a meaningful name The name IS the command you will type in test cases. Name it like an action: "add product to cart", "go to checkout", "navigate to admin panel".
- 3Write the steps inside the rule Add all the plain English steps that this rule should execute. These are the same commands you'd write in a test case.
- 4Save and use in test cases In any test case, type the rule's name exactly and testRigor executes all its steps at that point.
// Rule name: navigate to checkout // These steps run whenever "navigate to checkout" is called click "Cart" check that page contains "Your Cart" click "Proceed to Checkout" check that current url contains "/checkout"
// Test Case 1: Checkout with saved address login click "Samsung Galaxy S24" click "Add to Cart" navigate to checkout // calls the Reusable Rule click "Use Saved Address" click "Place Order" check that page contains "Order Confirmed" // Test Case 2: Checkout with new address login click "iPhone 15" click "Add to Cart" navigate to checkout // same rule reused click "Add New Address" enter "123 MG Road, Ahmedabad" into "Address" click "Place Order"
Advanced features overview:
// After clicking "Forgot Password" click "Forgot Password" enter "priya@example.com" into "Email" click "Send Reset Link" check that page contains "Email sent successfully" // Check the email was actually received check that email to "priya@example.com" was delivered check that email subject contains "Reset Your Password" get reset link from email and save as "resetUrl" open url stored value "resetUrl"
enter "priya@example.com" into "Email" enter "MyPassword1" into "Password" click "Login" // App sends OTP to phone — testRigor reads it via Twilio get sms code and save as "otpCode" enter stored value "otpCode" into "OTP" click "Verify" check that page contains "Successfully logged in"
// Save a value from the page into a variable save value of "Order Number" as "myOrderId" // Use the saved value later enter stored value "myOrderId" into "Search Orders" check that page contains stored value "myOrderId" // Generate random test data generate random email and save as "randomEmail" enter stored value "randomEmail" into "Email"
// Take a baseline screenshot (first run) compare screen // compares with baseline — fails if visual difference found // Or take a named screenshot take screenshot and save as "homepage_baseline" // On next run: compare screen with "homepage_baseline"
// ── GET request ────────────────────────────────────────────── call api get "https://jsonplaceholder.typicode.com/users/1" and check that http code is 200 // ── GET with headers + save response value ─────────────────── call api get "https://api.myapp.com/products/123" with headers "Authorization:Bearer mytoken123" and get "$.name" // JSONPath to extract value and save it as "productName" and then check that http code is 200 // Use the API response in UI test check that page contains stored value "productName" // ── POST request ───────────────────────────────────────────── call api post "https://api.myapp.com/orders" with headers "Content-Type:application/json" with body "{\"productId\": \"123\", \"qty\": 2}" and check that http code is 201 and get "$.orderId" and save it as "newOrderId" // ── Combined UI + API test ──────────────────────────────────── // Step 1: Create order via UI login click "iPhone 15" click "Buy Now" save value of "Order ID" as "orderId" // Step 2: Verify via API that order was created in backend call api get "https://api.myapp.com/orders/" concatenated with stored value "orderId" and check that http code is 200 and get "$.status" and check that it equals "confirmed"
Supported CI/CD integrations:
GitHub Actions integration example:
name: testRigor Automation Tests on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest steps: - name: Run testRigor Tests run: | curl -H "API-TOKEN: ${{ secrets.TESTRIGOR_API_TOKEN }}" \ "https://api.testrigor.com/api/v1/apps/YOUR_APP_ID/retest" # testRigor runs tests in its cloud — you get results in dashboard
pipeline { agent any stages { stage('Run testRigor Tests') { steps { sh ''' curl -H "API-TOKEN: ${TESTRIGOR_API_TOKEN}" \ "https://api.testrigor.com/api/v1/apps/${APP_ID}/retest" ''' } } } }
Follow these professional best practices to get the maximum value from testRigor and build a stable, scalable test suite.
- 1Use the "login" keyword — not manual login steps Always store credentials in Test Suite settings and use the single login command. This means login logic is defined in one place. If the login flow changes, update only the stored credentials or the auto-generated login rule — not every test case.
- 2Create Reusable Rules for repeated flows Any sequence of 3+ steps used in more than 2 test cases should become a Reusable Rule. Name rules clearly like "navigate to user profile" or "clear cart". This is testRigor's equivalent of the Page Object Model (POM) in Selenium.
- 3Use the "under" keyword to scope assertions Always write check that page contains "Product Name" under "Your Cart" instead of just check that page contains "Product Name". This prevents false positives when the same text appears in multiple places (e.g., product recommendations vs. cart).
- 4Use "if page contains" for optional elements Cookie banners, subscription popups, promotional modals — these appear inconsistently. Use if page contains (soft check) to handle them without breaking tests when they don't appear.
- 5Use "generate random email" for registration tests Never hardcode test email addresses. Use generate random email and save as "testEmail" to get a unique email for each test run. This prevents "email already registered" errors in repeated test runs.
- 6Let AI generate your initial test cases When creating a new Test Suite, provide a detailed app description and let testRigor's AI generate initial test cases. Then review and refine them. This gives you a starting point in minutes instead of hours.
- 7Organize tests with descriptive names and labels Name test cases clearly: "User can login with valid email and password" is better than "Login test 1". Use labels to group related tests (e.g., label: "Smoke", "Regression", "Login"). This helps when running specific test groups in CI/CD.
- 8Combine UI + API for complete end-to-end coverage Don't just test the UI. Add API assertions after key UI actions to verify the backend also recorded the change correctly. This makes your tests true end-to-end — validating both what the user sees AND what the system stores.
- 9Run full regression after every deployment Trigger testRigor's full Test Suite via CI/CD API on every production deployment. Because tests rarely break on their own (self-healing), you can trust testRigor failures as real application regressions — not test maintenance issues.
- 10Use testRigor for regression, exploratory for edge cases testRigor excels at automating known, repeatable flows (regression testing). Use manual/exploratory testing for creative, unknown edge cases. Together they give the best coverage with minimum effort.
"testRigor is an AI-powered, no-code test automation tool that lets anyone write end-to-end tests in plain English — no XPath, no CSS selectors, no programming knowledge needed. Unlike Selenium where you write code like driver.findElement(By.id("login")).click(), in testRigor you write click "Login" and the AI finds and clicks it. The key advantage is stability — since tests reference visible text on screen instead of internal DOM IDs, they rarely break when developers change the code. testRigor also has built-in email testing, SMS/OTP testing, visual testing, API testing, and self-healing AI — features that require complex plugins or workarounds in Selenium. It's ideal for teams that want high test coverage quickly without deep automation expertise."
Ready to Master testRigor in Real Projects?
STAD Solution's QA Automation course covers testRigor — plain English testing, CI/CD, real-world projects, and 100% placement support.
Explore Courses at STAD Solution →