There are many different options for configuring and running a plan, and what works for one team might not work for yours. This guide offers some general tips for teams on how to organize mabl tests into plans.
When deciding how to organize plans, it can be helpful to think about the following questions:
- How is your team structured?
- What do you focus on for ownership?
While no two teams are alike, here are two common ways to group tests into plans:
- User role: Plans can contain tests that verify features for a specific user role, such as administrators or users.
- Feature sets: If your team is working on a specific feature, such as search, filtering, navigation, or settings, you can create a plan that contains the tests that cover all the scenarios for one specific feature.
When you decide with your team on how to organize plans, you should discuss what naming conventions and labels you will use for your plans.
Whatever method you use for organizing plans, we recommend that you keep the size of plans manageable.
While it is possible to run a plan containing 100+ tests, creating smaller plans makes it easier to troubleshoot when something goes wrong. If you want to trigger several plans at the same time, you can use plan labels with the mabl deployment event to trigger a specific set of plans to run.
Plan labels can be used to define specific test suites, such as regression, targeted regression, smoke, the team associated with the tests, or a certain functionality or feature area.
That way, when you trigger a mabl deployment event, you can add the
--labeloption to specify that only plans with, for example, the "smoke" label, run.
You can run tests in a plan in parallel and sequentially and use plan stages to define the order in which tests run.
Plan stages are useful for modeling the standard setup - test - cleanup behavior. For example, a hypothetical plan might define three plan stages as follows:
- Concurrency: sequential
- Create user
- Add vehicle
- Vehicle tests
- Concurrency: parallel
- Schedule car wash
- Order new tires
- Run diagnostics
- Concurrency: sequential
- Always Run: true
- Remove vehicle
- Remove user
Plan stages are also helpful for integrating API and browser tests into a plan that uses a setup, test, and teardown structure. For more information on integrating API and browser tests into a plan, click here.
Running tests sequentially or in plan stages makes it possible to pass variables from one test to the next.
Watch this webinar featuring mabl's Matthew Stein explaining the best practices for organizing your tests into effective plans, and check out the associated blog post here for text explanations.
Updated about 1 month ago