Working as a Team in mabl

Feedback Request

Since there are so many teams that work so differently, it is hard to capture all of that in one document. Hard, but not impossible! Please use the "SUGGEST EDITS" button in the top right corner of this page to share any of your best practices or suggestions and help out the rest of the mabl community!

Index

Tests

Test Details

Naming Conventions: Define a naming convention that works well for finding tests and defining what they do.

* Ex: 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: Explanation of the test case so others can 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.

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

* Ex: 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:

  1. Review screenshots and see if there is a visual explanation
  2. Check the Network Logs to see if there were any failed network requests
  3. Read the mabl Logs to understand what mabl was doing to try and complete the step
  4. (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
  5. Duplicate the issue manually
  6. 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

Failure Classification: After looking at a test failure, classify that failure so your team knows...

  • what the issue is related to
  • that someone has reviewed the failure

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.

Updated 10 months ago


Working as a Team in mabl


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.