mabl’s product structure provides a flexible framework that allows you to set up your testing workflow according to your needs. This article describes how four key components in the mabl workspace fit into your overall testing strategy: environments, applications, plans, and tests.
Organization of a mabl workspace
Environments
Environments in mabl represent the stages of your software development lifecycle. By naming environments according to the environments where you deploy your code, such as Dev, QA, Alpha, Beta, Release Candidate, and Production, you can set your mabl workspace to mirror your team’s software development lifecycle.
Applications
Applications in mabl represent each unique product that you offer to your customers. For example, if your team tests your company’s marketing site, customer portal, and internal admin site, you could create three applications for testing in mabl.
Application targets
Application targets are the actual base URLs and mobile build files that you are testing. An application can have one or more application targets, which are associated with specific environments. Every time you create a test or plan in mabl, you have to indicate which application targets you want to test.
Selecting an application target for a new plan
Plans
Plans are ordered groups of tests that focus on a certain area, such as tests for a specific user role or tests that focus on a specific set of connected features. You can associate multiple plans with a single application, but you may only associate one application to each plan.
Plans are where you configure your automated testing strategy, setting tests to run on a schedule or in before or after a deployment event in your CI/CD workflow.
Tests
A test is a set of steps used to validate that your application is working as expected. You can associate tests with multiple plans at the same time. In mabl, you can create standalone browser tests and mobile tests in the mabl Trainer, API tests in the API Test Editor, and visual smoke tests. Using existing tests, you can also validate performance and accessibility.
Tests should focus on smaller pieces of functionality that fit within the context of the plan, application, and environment that they’re being applied to.
Putting it together
The total number of applications, environments, plans, and tests will vary based on each team’s testing needs. When put together, these key components form a single mabl workspace.
Home page for a sample workspace
For more information on how to set up your mabl workspace, see our Getting started guide.