Best Practices

Learn best practices for creating and executing Visual Editor tests.

We recommend using the following best practices for creating and managing Visual Editor tests.

Run mobile tests with the Tester Community.

The Automation Service isn’t fully compatible with mobile yet. Execute mobile tests using our Tester CommunityTester Community - Human test execution. Harness the ingenuity of on-demand QA testers. Pay more and wait longer for test results but with the benefit of more detailed output..

Use the Tester Community to verify unique data.

The Automation Service is best suited for stable and static test data since it relies on pixel and text-based matching. There’s no way to validate dynamic datadynamic data - Values that you define in a comma-separated values (CSV) file and upload to Rainforest. Dynamic data allows you to assign each tester a unique value, such as login credentials. or built-in databuilt-in data - Random values that Rainforest generates for testing. These include first name, email address, inbox, and Social Security number.. Use the Tester Community instead.

Optimize for a single browser.

Run Visual Editor tests with automation on the same browser the test was created on. Automated tests rely on screenshot and text-based matching, resulting in tests optimized for a single browser. You can still run cross-platform tests using our Tester Community.

Follow screenshot size best practices.

Providing relevant screenshots is the best way to ensure accurate results. Including a screenshot that’s too large could result in unexpected failures. Conversely, screenshots that are too small might miss an essential part of the screen.

Note that it’s not necessary to include the entire area when capturing fields and buttons. Just make sure there’s enough to make the information unique. Let’s say the screen shows multiple rows, and each row contains a Submit button. Instead of taking a screenshot of one button, include additional information from the row to make the screenshot unique.

In the example below, the step is verifying that the “Try for free” button appears. While the first screenshot may work, it includes excess elements that aren’t the focus of the step. The second screenshot is focused on the “Try for free” button and allows text matching to be enabled, which means testing is more reliable.

A less than ideal screenshot compared to a better screenshot.A less than ideal screenshot compared to a better screenshot.

A less than ideal screenshot compared to a better screenshot.

Use the Target Indicator

When creating a screenshot, Rainforest automatically places a target indicator in the center. This is where an action such as Click takes place. However, sometimes the action occurs somewhere else on the screen. Adjust the target as required.

In the following example, the target needs to be moved to the left. As a result, “Where” is clicked instead of “going.”

The default target location of the screenshot.The default target location of the screenshot.

The default target location of the screenshot.

The updated target location.The updated target location.

The updated target location.

Use Text Matching.

Text Matching provides an additional level of review for elements and should be used under most circumstances. When the same text appears multiple times on the page, Text Matching should not be used. A good example is when several data rows contain a Submit button. For more information, see Text Matching.

Follow test data best practices.

Though you can use test datatest data - Placeholders that allow you to inject other values into your tests. Rainforest supports three types: dynamic, static, and built-in. in Visual Editor tests, validation is limited to static datastatic data - Single values such as credit card numbers and URLs that you can share across multiple steps and tests.. For more information on Test Data, see Using Test Data.

  • Include test data such as Login credentials, names, and email addresses.
  • Dynamic and built-in data cannot be validated when using Automation Services.
  • If your test requires test data validation, run it using our Tester Community with the Tester Confirmation action.

Example: Did the welcome page say Welcome [random person]?

Embedded Tests

Visual Editor tests support Embedded TestsEmbedded Tests - Tests you can include in other tests. Write repetitive actions once and reuse everywhere.. For more information, see Visual Editor Embedded Tests.

Tester Instruction and Tester Confirmation

Visual Editor tests are built to run using the Automation Service. However, some tests can’t be automated; they require human logic. Here are some examples:

  • An instruction to select a date on a calendar control
  • Captcha
  • Validate dynamic or built-in test data
  • Compare and contrast
  • Other complex instructions

Note: In these instances, use tester instructiontester instruction - An action required to complete a step.s and tester confirmationtester confirmation - The expected result of a completed action. Framed as a Yes/No question, such as “Are you taken to a page with a Welcome title?”s.

Name elements appropriately.

Naming elements is a requirement. Use names that clarify the step’s action. Doing so is useful when reviewing and updating the test. Moreover, it helps the Tester Community. When naming an element, use a word or phrase that’s short yet descriptive. “Submit - login page” is more precise than “Submit.”


If you have any questions, reach out to us at [email protected] or via the chat bubble below.


Did this page help you?