For this blog post, we took inspiration from Angie Jones’s great post at TechBeacon.

What's wrong with record and playback tools?

We’ve heard the reservations people in the testing community have with record and playback tools as a result of problems they’ve had in the past and continue to have today. With mabl, we’re working to make the creation of your tests free from those problems to make them as comprehensive and easily maintainable as possible. So we're aimed at empowering testers who feel left behind by the programming that test automation tools like Selenium require and want easy-to-maintain and effective tests.

First problem: Applications changing frequently and tests not adapting

One of the most common problems that hamper record and playback tools is that new development practices like DevOps and Continuous Delivery mean application changes are being pushed more frequently than ever, requiring tests to be constantly updated. With this in mind, we’ve focused on building an auto-healing feature that locates changed elements when your app is updated. When you first write your test and interact with an element, mabl will save a number of other identifiers of that element along with the part of the element you’re interacting with. If any identifier of the element interacted with ends up changing due to an update, mabl will search for the updated element in the next test run using those other identifiers.

An example of mabl's auto-healing. The test completed successfully with mabl finding the element after an update.

When the element is found this way, mabl will complete the test using the latest element, then notify you of the changed step when the test completes. mabl will update the information set for that element for future test runs. If for any reason mabl auto healed the test incorrectly, you can reject the change and train mabl to try something else for the next test run. This kind of auto-healing is especially effective for testing apps with dynamic UIs, such as those built with React or Angular. We have a simple example of this in action in another one of our blog posts.

Second problem: Assertions are complicated and unintuitive to use

With mabl, we wanted assertion steps in your tests to be as easy to utilize as possible, as they’re likely one of the most frequent steps you’ll be adding. The mabl trainer, our Chrome extension you use to train your tests, tracks all your interactions with your app as well as gives you the ability to add advanced steps in your tests. With the trainer, adding an assertion is as simple as clicking on the element you want to assert against and selecting what you want to assert.

In the mabl trainer, Add Assertions is the first button on the left along the bottom. You can see some of the types of assertions you can use in the trainer on the right.

Third problem: Editing recorded tests is either hard or impossible

When mabl started its beta at the start of this year, we were guilty of this problem too. There was no way to edit your existing tests and you had to re-record your entire journey if you wanted to make a change. However, the amount of feedback we heard from users who wanted a simple way to modify their tests made this one of our top priorities before our full release.

You can edit any step in your journey during training or after you've saved it.

Now, not only can you easily edit your tests after you’ve trained them, you can use reusable flows to define a set of steps and make changes across many journeys at once.

Flows are highlighted in purple and can be saved and used across other journeys.

Fourth problem: Inadequate reporting

One of the things we focused on heavily with mabl is providing extensive data about each test execution. Screenshots are taken at every step in your test run so you can see the last state of your app when the test failed alongside mabl’s report on what caused it to fail.

In the journey output, you can see the results of all the steps, screenshots at each step in the journey, and visual changes lows are highlighted in purple and can be saved and used across other journeys.

You can see graphs of your test’s passes and failures in the past and each run’s test execution time. mabl also does more than telling you when a test passed or failed, providing you with insights when there are visual changes, broken links, and extended page load times.

In the mabl app, you'll find graphs of your test run history and their respective run durations.

Getting info about issues is easy with email notifications about your workspaces and Slack messages containing notifications for specific events, which you can customize to your liking. If you’re using Jira or BigQuery, you can convert your test output into Jira issues or find detailed info about sets of tests through queries.

mabl sends insights to your Slack account that can go directly to you or a channel for your whole team.

Fifth problem: Lacking integration with CI/CD pipelines

mabl was designed with CI/CD pipelines specifically in mind, as our whole mission was to improve testing to keep pace with the deployment speed of DevOps. mabl has native integrations with Bamboo, Jenkins, and Slack, and with our deployment API, mabl tests can be triggered from any CI platform. This allows for mabl tests to be executed outside of the mabl app automatically on deployments. You can also take advantage of webhooks to send test metrics outside the mabl app and keep your whole team updated.

The integrations page in the mabl app..

With mabl, we’ve worked to overcome the stigma that record and playback tools have and show how effective codeless testing using them can be. There’s still a long way to go, so we plan to keep improving mabl to address further concerns our users have while adding new features that allow for more comprehensive testing. If there are other capabilities you’d like to see to help testers out there, don’t hesitate to drop into our Slack group and let us know! And of course, you can try mabl out for yourself.