Skip to main content

​
1. Incorrect or Misformatted Starting URL

What happens: Tests fail immediately or start on the wrong page. Why it matters: The Start URL is where Testavi begins your test flow—it must be complete and properly formatted. Correct example: Always include https:// and the complete URL. Incorrect examples:
  • Missing protocol (https://)
  • Incomplete URLs
Always copy and paste the URL directly from the browser’s address bar.

​
2. Mixing Actions Inside “Verify” Steps

What happens: Tests become semantically unclear or are misinterpreted. Bad example: Combining verification and action in one step. Good example: Separate verification and action into distinct steps.
Rule of thumb:
  • Actions = things the test does (e.g., click, scroll)
  • Verifications = things the test checks (e.g., visible, present)
Keep them in separate steps.

​
3. Non-Scenario Table Tests in Scenario Table Test Suite

What happens: Static tests placed inside a scenario table suite will execute once per scenario row, potentially causing duplicate confirmations or side effects. Bad example: Static verifications running in a scenario table suite. Good practice: Keep tests that do not rely on scenario table variables in a separate test or suite. This prevents static verifications from running multiple times.

​
4. Using “Go to URL” Inside Test Steps

What happens: Testavi can’t interpret “Go to URL” commands mid-test, causing scripts to fail. Bad example: Using “Go to URL” as a test step. Good example:
  • Set the Start URL in your test’s settings
  • Use actions for in-test navigation (e.g., click on navigation links)

​
5. Tab/Browser Navigations

What happens: Tests may break or misinterpret intent if you attempt to change tabs or navigate the browser without using supported actions. What to do: Use browser action steps for any tab or navigation changes.
Always use the documented browser actions component for tab switches, window focus, and URL navigations.

​
6. Scrolling

What happens: The agent only interacts with elements in view unless instructed otherwise. Tests may fail to locate off-screen elements. What to do: Explicitly include scroll steps before verifications or actions. The agent will also scroll to find out-of-viewport items, but specifying scrolls improves test stability. See Discrete Actions: Scroll.
Remember that the agent sees only what a human sees. Include scroll instructions to ensure consistent element visibility.

​
7. Accessing Restricted Domains via Preview Editor

What happens: Direct navigation to restricted domains (e.g., Testavimail.com) may be blocked due to IP restrictions. What to do: Access these domains through the Preview Editor, which proxies requests and bypasses IP blocks. When you run the test normally, the agent routes via Preview Editor and executes steps successfully.
Use the Preview Editor view to interact with Testavimail.com. Direct browser access may show a blocked IP error, but tests will pass when executed through Testavi Preview.

​
✅ Authoring Do’s & Don’ts

❌ Don’t✅ Do
Use incomplete or incorrect URLsUse full URLs including https://, copy directly
Mix actions and verificationsKeep actions and checks in separate steps
Use “Go to URL” mid-testSet the start URL in test settings
Combine static steps inside scenario loopsKeep tables fully dynamic; extract shared setup
Attempt tab or browser navigations without browser actionsUse browser action steps for tab/window navigation
Omit scroll instructionsExplicitly include scroll steps before actions/verifications
Rely on direct navigation to restricted domains (e.g., Testavimail.com)Access via Preview Editor to bypass IP restrictions