We recommend using the following best practices for creating and managing Visual Editor tests.
The Automation Service isn’t fully compatible with mobile yet. Execute mobile tests using our Tester Community.
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 data or built-in data. Use the Tester Community instead.
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.
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.
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.”
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.
Though you can use test data in Visual Editor tests, validation is limited to static data. 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]?
Visual Editor tests support Embedded Tests. For more information, see Visual Editor Embedded Tests.
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
- Validate dynamic or built-in test data
- Compare and contrast
- Other complex instructions
Note: In these instances, use tester instructions and tester confirmations.
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.”
Utilize the Scroll function if you need to view a part of the page that isn’t at the top. However, for long pages, use the browser’s built-in Find function instead to locate the element on the page. Then, perform the action you want on it.
- Use the Press Key function for Control + F
- Use Type to provide what you want to search for.
If you have any questions, reach out to us at [email protected].
Updated 6 months ago