Recommendations to others considering mabl:
Mabl's proper implementation at a larger company requires dedication of time and energy. If (a) you don't have those resources, (b) you don't have a lot to test in your site or application, or (c) you already have dedicated SDETs who can script their own tests now, Mabl may not be as beneficial for you as it is for others. However, if you have a lot of application to test and a core community of manual testers and developers interested in boosting quality and streamlining their path toward it together, I would certainly take the time to look into it. It's changed everything about the way our team tests. Review collected by and hosted on G2.com.
What problems is mabl solving and how is that benefiting you?
There's the easy answer to this one: we're improving the quality of our applications by finding bugs quicker and more consistently. But I think the more important answer is that Mabl puts more power in the hands of our QAs and offers more potential to integrate our work with that of our developers. Because Mabl lets our black-box QAs script the most-run and most useful tests on our own, we've become more active participants in a part of the development cycle we previously didn't really contribute to. It makes our work more effective and takes some of that burden off our developers, especially with the use of the CLI tool and its integration into our deployment pipeline. Review collected by and hosted on G2.com.