0% Complete


Before taking this lesson

Make sure you are comfortable with the following lessons:

  • Mabl App Intro
  • Environments and Applications
  • Mabl Trainer Intro
  • Flows

Learning Objectives 🧠

By the end of this you will learn how to:

  • Form the foundation of your workspace
  • Organize your tests and plans according to your goals
  • Leverage Plan settings to get the most out of your testing

The Why

Establishing best practices early = greater success, but why?

Each team is unique and mabl is a flexible tool, which means each workspace is totally different. 

When you understand your individual goals, requirements, and limitations, best practices guide you in applying mabl to your individualized process.

When this working well, everyone knows:

  1. What they’re supposed to do
  2. When they’re supposed to do it.
  3. Why they’re supposed to do it

Confidence and communication lead to an efficient team that effectively carries out your automation strategy, which leads to better app coverage, and better app quality as a result! Woohoo! 

The Approach

What are we doing here?

Learn the best practices

The good news is, that’s what this lesson is for! 

If you would like to get the best version of your workspace up and running as soon as possible, learn about the tools at your disposal and how others have best used them for organizing a workspace.

Define your scope

Once you understand mabl’s components and how they’re meant to be used, it’s time to take a step back and look at your short, medium, and long term goals.

Execute and Iterate

Take your knowledge of mabl functionality, your automation strategy, and bring them together.

Always remember that nothing is meant to last forever -- your strategy will be in a constant state of change. 

Iterating as time goes on is the way to achieving the best version of your automation.

Learn the best practices

Establish naming conventions

The first best practice is to establish what you are going to name the various components of mabl that make up your automation strategy. 

Below we will cover a brief definition of the concept, and how you should think about using them in your automation.

The process of defining how you will go about naming the components of mabl will help inform how much functionality each will cover, and how each piece fits in your ‘automation puzzle’.

  • Environments
    • Name according to how your development environments play out in the context of automation - are there multiple QA or staging environments?
  • Plans
    • Plans typically cover a module, or set of multiple features
    • Ask yourself: what app is this, environment, frequency of execution, browser - put the important pieces of info in the title
  • Tests
    • Tests typically cover individual features, or subsets of features
    • Ask yourself: does this feature need to be covered in one end-to-end test, or can I break it down into multiple tests?
  • Descriptions (Plan and Tests)
    • Anecdote of what the purpose of the Test or Plan is doing
    • Ask yourself: what information would be helpful to put here for the different personas that might be trying to understand what this Plan/Test does, and why it is important.
  • Labels
    • For Plans: specify deployments in CI/CD, but also organization/search filtering
    • For tests: Organization/search filtering
  • Flows
    • Subsets of tests that are reusable in other tests (Learn more about Flows here)
    • Ask yourself: Will this series of steps be reused in multiple tests?
  • Comments
    • Ask yourself: What would be useful for someone reviewing this test to know about it? What nuances are there? What isn’t obvious about this test result?



Plan: ‘Blog site’ -- general area of functionality.

Description: ‘Verify search functionality, that each type of blog and webinar can be searched, and that you end up on the correct page each time’ -- tells you what the tests within are supposed to validate.

Test: ‘Search’ -- the individual piece that the test is covering.

Label: ‘Search’ -- tells what functionality is included in this Plan.

Leverage Plan Configuration 

Plans hold great power and great responsibility in mabl, they allow you to tailor mabl automation to your needs and goals.

  • Environments
    • You have the option to execute a Plan against multiple environments
    • Caution: in order to do so, your environments must be exact copies of one another, or else results will vary that may not be indicative of true quality.


  • Stages 
    • A tester’s control panel for their mabl automation -- it lets you dictate how your tests execute in relation to one another (VERY important)
      • E.g. Data setup/cleanup
    • Concurrency - parallel or sequential - the order of how tests execute
    • Browser coverage
    • Visual change learning 


  • Device settings
    • Allow you to control what browser and/or device your tests will execute in the cloud against.
    • Disclaimer: different subscription packages have access to different browsers, if you would like to learn more about this, reach out to support@mabl.com
    • Desktop vs. Mobile web
      • A Plan will run against either desktop or mobile web, not both, so if you want to have tests run against both, duplicate the plan and set one for each.
      • Learn more about Mobile web here


  • Triggers
    • Control when your tests will execute 
    • Think about how this might impact your development environments, especially if there are data dependencies or if the environment shuts down at certain times.


  • Advanced options
    • Access controls
      • HTTP Basic Authentication
      • Send Customer HTTP Headers
      • Login Credentials -- allow you to utilize auto-login, such that you do not need to include logging into your app as steps in a test



We’ve compiled these core best practices here, but mablers are learning new exciting tips and tricks every day.

(Tune into our Friends of mabl Slack community to learn more -- reach out to support@mabl.com if you’re not already familiar.)

Define your scope


Establishing a “vision” of your automation strategy will help you identify the specifics of how it will come to fruition.

One key aspect of that is setting clear, actionable goals -- what do you want to accomplish, when, and why?

It’s tough, we know, but try your best to picture the perfect world of automation for your product and team.

The flexibility of mabl

  • Each team, product, development process, overall strategy, goals, etc. is different, so you have to understand where you are right now, and where you want to be within a certain timeframe.
  • Mabl is built in a way to handle a variety of applications, industries, and use cases -- it is up to YOU to configure it for YOUR needs.

Automation at scale

Understand what aspects of your application and development environments that will impact automation at scale.

  • Does your app have state and/or data dependencies (i.e. data needs to be established and reset, and/or changes will affect other tests)?
  • Does your app have user concurrency limits (i.e. certain # of users can log in at any given time)?
  • What are the limits of your environments, do they go down at certain times or have security restrictions? (If the latter is true, check out our lesson on mabl-Link here).

Teamwork is key

Understand how your team best collaborates with one another to achieve your goals

  • Who owns test creation/review for each part of the app?
  • How do we see the team evolving over time?
  • What do we do if a key team member leaves?
  • What kind of visibility do we need to provide to each other and upper management?
  • Who has the most automation experience?

What’s in your scope? 

The scope of what you’re including in a given test, plan, or flow: What you automate first, which members on the team handle it, and how you approach that

  • What areas if you automated would help form a foundation of automation?
  • What areas provide the most business value? (e.g. E-commerce checkout)
  • What areas of your app are more complex and harder to automate?
  • What areas are prone to bugs?
  • What areas are easier to test and could be automated first and/or useful to train newer/less technical people?

Goal setting for success

Set actionable short-term goals and longer term stretch goals asking yourself and your team:

  • Where is the automation coverage today, and where do we want it to be 3, 6, and 12 months from now? (actually set goals for each interval)
  • How do we anticipate the app grow and the features to change in the next year based on the roadmap?
  • How often do users interact with certain parts of the app?
  • How often should we run our tests to ensure application quality?
  • In order to achieve proper coverage, in what order do we run our tests, and how much functionality is included in a single flow, test or plan? (This is a really big one)


  • Cover main user happy paths by 30 days, and full regression suites running smoothly by 60 days.
  • Have the team ramped up on basic functionality after 30 days, and by month 3 mabl is integrated into the CI/CD pipeline.

You can always course-correct as time goes on, but keep in mind that creating and organizing tests in a way that makes it easy to reorganize them if needed is important.

Execute and Iterate

What does that even mean?

Things change -- management priorities, product development goals, team structures, tech stack -- evaluate your strategy quarterly at the least, make tweaks and changes as needed.

Keep track of what works and what doesn't -- use the comments section on the results page to leave a trail of your thoughts for your teammates.


Ask mabl - reach out to us about your strategy and we will give you our feedback.




What did we learn?

  • How to approach understanding your unique requirements, team, and goals, in the context of mabl automation
  • How to take the scope that you’ve established, and apply it to your mabl workspace using the tools at your disposal
  • How you can use this new understanding and configuration to iterate on your strategy moving forward, in order to get the most out of your efforts to ensure quality for your users


Was this helpful?

Take this 2 minute survey to let us know how we can make mablU better!