Index
Test Details
Test Creation
Flow Creation
Plan Creation
Application/Environment Management
Understanding Test Failures
Reviewing Test Results
Tests
Test Details
Naming Conventions: Define a naming convention that works well for finding tests and defining what they do.
- Example: Application Name - Module - Test
Labels: Used to help organize tests
- Components: Search, Login, Settings
- Status: WIP, Broken
- Ticket Number: JIRA-1234
- Test Suite: Smoke, Regression
Description: Adding an explanation of the test case can help other users in the workspace quickly understand what is being tested.
Test Creation
Rename test steps: Double click on step text to reword it to make it more understandable for you and your team
Use existing flows: Save time with test creation and maintenance later by using as many existing flows as possible.
Create new flows when applicable: If you know that certain actions your test does will need to be done in other tests, group that into a flow.
Data-Driven Variables: Any value that you might want to change from outside of the test. Powerful for entering text and assertions. Variables {x} > Manage
Focus your tests on what you are testing: If you need to test something on a specific page in your application, once you log in, use another visit URL step to skip navigation steps and get right to what you want to test. (make sure that navigation is covered in at least one test so you can skip it elsewhere)
End tests with an assertion: A test is only as good as what it validates.
Only use "Is present" or “Is not present” assertions on XPath or CSS Selector assertions, not recorded assertions
Echo Steps as Headers: If you put "#", “##”, or “###” at the start of an echo step, it will become a header in the test to visually break up different parts of the test.
Finding Elements: When trying to get mabl to find an element, always try to create steps in this order:
- Record the step
(if that doesn't work then...) - Configure find the recorded step
(if that doesn't work then...) - Find elements step using XPath or a CSS Selector (Never copy the selector from DevTools as those are brittle and will easily fail!)
(if that doesn't work then...) - JavaScript
Flow Creation
Naming Conventions:
* Ex: Application Name - Module - Action (Parameters)
Limit flows to one action:
* Good: Fill out form
* Bad: Fill out form and submit
End with an assertion: This is so you can validate that the flow did what you would expect it to do.
Parameters:
- Create flow parameters for steps that use variable values
- Enables flows to work in multiple situations
- Enables more technical teammates to create very powerful flows that work in different scenarios:
- API call to create test records and/or variables
- JavaScript steps for more complex use cases (ex: generating a date formatted a certain way)
- Custom CSS/XPath Selectors that use tests data to find elements
Make sure the flow does not already exist: Good naming conventions will help you know if a flow has been made before and help avoid doubling your efforts
Creating plans
Naming Conventions
- Example: Application Name - Module or Feature
Labels: Plan labels are very important as they allow you to have more control over what Plans are run when you trigger a deployment
- Functionality: Search, Login, Settings
- Test Suite: Smoke, Regression
Application/environment management
All URLs should end without a trailing slash: This allows you to create dynamic Visit URL steps in your tests that work on any Environment: {{@app.url}}/shop/item/{{@item_id}}
Understanding test failures
Start at the failed step and work your way backward:
- Review screenshots and see if there is a visual explanation
- Check the Network Logs to see if there were any failed network requests
- Read the mabl Logs to understand what mabl was doing to try and complete the step
- (If Chrome) Download the Step Trace Data and open it in Chrome DevTools > Performance to see more granular screenshots and what the page was doing
- Duplicate the issue manually
- Reach out to mabl support via the in-app chat and provide the URL from the test output
Share the URL to a teammate for assistance: All test output exists at a static URL so you can directly share that with teammates. There is no limit to the number of mabl users so anyone you want can have an account and see results.
Reviewing test results
Results > By Deployment: When your plan runs are triggered by a deployment, you can see just the plans that ran and their tests from the results page under By deployment.