Set Your mabl Workspace Up for Success

Starting with any new work application can be an intimidating process: there’s pressure to demonstrate ROI, help your team onboard quickly, and create new workflows that maximize results. Test automation with mabl is no different, which is why the Customer Success and Support teams are dedicated to helping every user make the most of our intelligent test automation platform, improve product quality, and support key initiatives like CI/CD. 

No matter what your quality engineering goals are, the foundation you establish in the early days of mabl adoption is critical to long-term success. How your team organizes their mabl workspace, manages test failures, and uses mabl’s wide range of integrations allow your team to quickly grow their impact on the development process and customer satisfaction. So whether you’re an experienced mabl user or just started your free trial, there are a few best practices to consider when setting up your mabl workspace. 

Key Concepts in the mabl Workspace

First, let’s cover the core terms that will help you and your team understand the features of mabl. Some of these will be familiar to software testers, but others are more specific to mabl’s low-code test automation platform. 

• Test: a test is a series of automated steps that tell mabl how to interact with and validate a specific functionality within your application or website. Examples include locating a specific URL or adding text to a form. 

• Test Plan: a test plan is an ordered group of tests that tell mabl how and when to run your automated tests. Plans can vary widely depending on your environment, application, execution frequency, and which browsers you're targeting, but the basic concept remains the same across all mabl workspaces. 

• Label: a label is a word or phrase used to identify tests within a plan for the purposes of identification and classification. Effective labelling should make it easier for everyone to navigate your mabl workspace and facilitate testing collaboration, a critical component of integrating automated testing into CI/CD. 

• Description: the description is a brief summary of each test/plan that tells your team what the test or plan does, and provides the necessary context. 

• Flow: a flow is a reusable set of test steps that can be inserted into any test by any  mabl user. Flows are extremely useful for expediting test creation and making complex tests accessible to all members of the software testing team, regardless of their coding experience. 

With these components, you’re ready to start setting up your mabl workspace, begin creating tests, and set the foundation for collaborative test automation that fits into your workflow.

Your First 30 Days with mabl

There’s a lot of ground to cover in your early days using mabl. Your team will start exploring our test automation platform, begin learning low-code automated testing, and start establishing their goals for testing and quality engineering. 

Worth noting: the advice and goals outlined below are suggestions. Every organization has different software testing and quality engineering needs, and your mabl timeline will depend on the nuances of your team and company. 

Start with A Scaling Mindset 

Most Friends of mabl start their testing journey by introducing mabl to their core QA or software testing team. But even if your plan is to keep testing concentrated within a handful of quality professionals for the time-being, organizing your mabl workspace will help your organization adapt and scale test automation as your needs and product evolve.  

You’ll find this dashboard by clicking “Plans” on the left hand side of your mabl workspace. This section allows your team to manage test plans, including descriptions, labels, and environment data. You can also filter your tests by the same criteria. 

Moving to the “Tests” tab, you can see the name of your tests as well as the description and the labels from the previous view. If you click on an individual test, you’ll be able to see the test steps, which are the building blocks of your automated tests. These steps allow you to understand what each interaction in the test is trying to accomplish. 

As you can see, there’s a lot of information available within the mabl workspace. A critical part of setting your own workspace up for success is creating consistent, clear standards for labels, names, and descriptions so that new team members can easily navigate your tests and test plans. As you integrate automated testing with mabl into your development environment, transparent labelling will support easier collaboration as developers, product managers, and other team members start interacting with software testing. 

30 Day Objectives for Test Automation and Quality Engineering

As your team starts familiarizing themselves with mabl, we highly recommend exploring Mabl University, our self-paced learning center for all things mabl, test automation, and quality engineering. Giving your team time to complete the interactive lessons in Mabl U will help your organization master the advanced features of mabl, reach the full potential of software testing, and establish a shared understanding of quality engineering for long-term success. 

With a solid understanding of mabl, quality teams are able to set internal goals and begin shaping their early testing strategy. The early stage of mabl adoption should be filled with experimentation, data analysis, and communication so that your test automation strategy is effective, scalable, and collaborative. Setting clear goals from the onset will help your team have the highest impact possible on the product and development organization. 

90 Day Goals for Test Automation and Quality Engineering

After establishing naming conventions, completing lessons in Mabl U, and setting internal goals in your first 30 days with mabl, your team is ready to start building a thorough, data-driven testing strategy. As I mentioned earlier, much of this early stage will spent on analysis and communication as your organization decides how to best use mabl’s advanced test automation features in support of your quality goals. 

Expanding Test Coverage

A key metric: test coverage. As one of the most common metrics in QA, your team is most likely already focused on expanding test coverage as your product evolves. Once you’ve built out basic functionality in mabl, you can shift focus to expanding test coverage and establishing the workflows across QE, development, and product management to ensure that your automated testing strategy matches the needs of your product and your customers. 

Expanding test coverage might also include expanding how your organization defines product quality altogether. As quality assurance takes on a larger role in validating the entire customer experience, they’re also asking important questions about accessibility, localization, and the mobile experience in addition to supporting better engineering processes. Though test coverage is most strongly associated with the traditional definition of software testing, mabl features integrations with customer data platforms like Segment to make it easy align test coverage with the customer perspective and spark larger conversations about product quality. In your first 90 days with mabl, consider how re-defining metrics like test coverage can help your company build better customer experiences. 

Understanding Test Failures

In addition to improving the customer experience, successful test automation can improve how your organization develops software. Once you and your team have created a core set of tests, you can begin classifying failures and start tracking test quality over time. 

Looking at the dashboard, you can click on one of the tiles that shows an environment’s name, which will show you an overview of test history related to that environment.  Assuming your team is diligent about classifying failing tests, you can quickly understand the trajectory of your product quality. Though often overlooked, this feature gives both product management and QE  great visibility into how your team is utilizing mabl and how product quality is evolving within your organization. As automated testing is scaled across your development pipeline, test failures can be a valuable warning sign for environment issues and more. Creating a continuous loop of testing - test results - analysis allows the entire development organization to benefit from mabl, as well as continuously improve your product, development process, and automation practices. 

Integrating mabl into CI/CD

Around the 90 day mark (remember, this timeline is a suggestion, not a deadline), your team should be comfortable enough with mabl to start scaling across the development pipeline, including collaborating with developers to triage defects faster, setting up automatic alerts on test results, and improved reporting. Our suite of integrations enables QE to seamlessly integrate testing into their existing tech stack to create a culture of quality. When implemented successfully, intelligent test automation should not only make testing easier, but also support better collaboration between teams and continuous improvement for the product and the product organization. 

Mabl is designed to make all of this possible. And if you get stuck, Customer Support is available to answer your test automation and quality engineering questions. 

Six Months of Test Automation...and Beyond 

By the six month point, your team has likely built out basic smoke tests, a regression suite, and have instituted a clear labelling system for each type of test within a plan. Testing is integrated (or semi-integrated) into your development pipeline and the results can speak for themselves: fewer bugs are sneaking into production, defects are resolved faster through mabl integrations with Jira, Slack, and Teams. Ideally, your entire development organization is able to ask tough questions about quality, accessibility, and the customer experience. Congratulations on setting your mabl workspace and your entire QE team up for success! 

This blog is based on my discussion at mabl Experience 2021, our second annual conference on all things Quality Engineering. You can watch the full presentation: