A plan contains a group of tests and all of the information needed to run them, including, but not limited to, application, environment, browsers, stages, and specific timing triggers. Plans make it possible to share variables between tests, run tests on a schedule, and integrate mabl tests into your CI/CD workflow.
There are many different options for configuring and running a plan, and what works for one team might not work for yours. The purpose of this guide is to offer some general tips for organizing plans in a way that makes sense for your team.
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.
In addition to setting tests to run in parallel or sequentially, you can also group tests together by stage. Running tests sequentially or in stages makes it possible to pass variables from one test to the next. For more details on how to define the order of tests in a plan run, see our documentation on plan stages.
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