0% Complete


Lesson Objectives

  • Understand the key building blocks of mabl
  • Know where each component exists in the mabl app
  • Feel comfortable with how each component relates to one another in mabl testing

Key Terms

  1. Workspace
  2. Environment
  3. Application
  4. Plan
  5. Test
  6. Test Results

Keep in mind: These are foundational concepts, so make sure you have them down before exploring other lessons where we go into more specific detail.

Map of mabl

Below is a basic model of how the key pieces of mabl are meant to fit together when configured properly.

Keep in mind:

  • Total # of Environments, Applications, Plans, and Tests will vary based on each team's testing needs.
  • Although there are best practices for its configuration, mabl can mold to a variety of test strategies

mabl Application Components


A Workspace is THE basic building block of mabl, housing all of its key components.

In the rest of this lesson, we will build out how the remaining key components relate to one another.

But before we do that, we recommend you open up the mabl app and follow along.


Your home base, your captain's chair, your command center…

The dashboard gives you (among other things):

  • A 'status-check' of the components of your Workspace.
  • Recent usage numbers.
  • Easy navigation to different parts of the app (by clicking on the hyperlinked names of various components).

⭐️  Gold star if you can find all 6 of the terms from this lesson on the Dashboard ⭐️


Environments in mabl typically line up with the same environments that your team uses in the development process.

  • E.g. If code typically goes from Dev to Staging to Production, then those three should be included as Environments in mabl as well.
  • Environments can also hold configuration settings, such as Environment Variables.
  • I.e. Variables that are accessible for any test within that environment.


Applications in mabl are associated with their respective URLs.

mabl leverages the URL so that you can create tests and then run them automatically.

E.g. At mabl, some of our apps include:

  • app.mabl.com
  • sandbox.mabl.com
  • mabl.com

❗ As you can see below, multiple Applications can be associated with multiple Environments, just like in the real world!

How are these set up you ask? Great question...


The Configuration tab is where you go to establish/change how your Applications and Environments are organized.

See above: the left column shows Applications, the header shows Environments that they are deployed to.


A Plan is an ordered group of Tests focusing on a certain area of functionality in your app.

A Plan carries the configuration for how mabl will automate your testing, and links up with the Application and Environment(s) of your choice to do so.

❗️ See above: multiple Plans can roll up to a single Application, but a single Plan cannot be associated with multiple Applications at the same time.


A Test is a set of steps used to validate certain functionality in your application.

Tests should focus on smaller pieces of functionality that fit within the context of the Plan, Application, and Environment that they are being applied to.

❗️ Tests can be associated with multiple Plans at the same time

Tests are mainly found in the Tests tab as seen below, but you can also find them by clicking on the name of a Test anywhere in the app - it's true!

Among other configurations, you can view a breakdown of tests in 4 ways:

  • DETAILS: breakdown of the steps in order
  • RUN HISTORY: test results of recent executions
  • PLANS: what plans the test is associated with
  • CHANGE HISTORY: how the test has changed over time

Now that you understand the basic building blocks of mabl and how they connect, let's take a look at what happens once everything is set up properly.

Test Results

First, let's show you how to get there:

Navigate to the tab on the left navigation bar named 'Results'.

Click on either a ✅ Passed or ❌ Failed status.

Test Results provide a step-by-step breakdown of what happens during test execution, and whether it yielded a passed or failed status.

When a Plan is triggered, mabl takes each test, applies the configuration, and executes it in the cloud.

Screenshots, Network Activity, and a full DOM Snapshot serve as tools to provide a complete picture of the application during that step.

Use these to get to the bottom of why a test failed, or learn more about what happened during a passing test.

Those pesky bugs don't stand a chance!

Deployments allow you to link up to a CI/CD tool of your choice and run mabl tests as a part of your development process.

If correctly configured, Plans will run automatically when code is merged to certain environments, so that full Continuous Integration and Continuous Deployment can be achieved, and mabl can catch bugs before they go somewhere they shouldn't!



What we learned

  1. Workspace - the basic building block of mabl, containing all of mabl's key components.
  2.  Dashboard - 'status-check' of the components in your Workspace.
    1. Environment - typically line up with the existing environments that your team uses in the development process.
  3. Application - represent your application(s) under test.
    1. Configuration - where you go to establish how your Applications and Environments are laid out.
  4. Plan - an ordered group of Tests with specific configuration settings for automation.
  5. Test - a set of steps used to validate certain functionality in your application.
  6. Test Results - provide a step-by-step breakdown of what happens during a test execution.
    1. Deployments - allow Plans to automatically run Tests when code is merged (when configured properly)


Was this helpful?

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