The power of modern computational power is a blessing for testers, allowing for impactful and complex tests to be run at lightning-fast speed on-premises. However, this blessing only extends as far as a team’s local infrastructure can stretch it, and as the number of tests that team wants to run at once increases, the higher the likelihood that these contemporary machines will run into a similar problem faced by their predecessors.
To illustrate this, let’s say you’ve just started running regression tests on your dev team’s deployments. So far, each dev has been running tests locally, checking their individual branches before committing them. Everything looks good on their ends, so they send their changes in and the team decides to test the full application before sending it live. You start the tests running in parallel on the deployment, and suddenly you see your build queue start to back up, with your builds beginning to fail. The tests have all slowed down substantially compared to their runtimes on the local branches, as running them all at once is causing some to time out and fail. It seems like you’ve hit the limit of your infrastructure, and the tests that should be running as quickly as they did locally are grinding to a halt because of the sheer number of them you have running in parallel. The strain caused by this parallel testing is monopolizing your resources, leaving you stuck with an untested deployment. So what’s your next move? Do you choose to instead run the tests in sequence, having each test run one at a time with a higher success rate but at a massive time cost? Do you call up your vendor and wait for them to increase your infrastructure (and your resource costs)?
You don’t have to worry about any of these; there’s another solution.
When you run mabl tests, you aren’t bound by the same limitations as running tests on your local machine or in a grid, as mabl runs your tests on their own containers in the cloud. Mabl also doesn’t limit the number of tests you can run concurrently, so the scalability you need is always available on demand.
The more tests you run, the more containers mabl spins up in the cloud.
When you start running more tests in parallel than you have previously, mabl will dynamically scale the amount of resources dedicated to them using scaling Kubernetes clusters, making running your entire regression testing suite in parallel and running a single test equally easy and fast. This means you can focus on your testing without having to worry about maintaining or increasing the size of your infrastructure, removing any need to reach out to your architecture team or an outside vendor, and jump through budget approval hoops. Mabl will always keep pace with your development and testing velocity, making your deployments more frequent and better tested, which leaves more time for expanding your test coverage and increasing quality.
We believe the quality and impact of your testing shouldn’t hinge on the limits of your infrastructure, so we made scalability a key part of how mabl handles your team’s tests, both by dynamically scaling the amount of resources dedicated to your tests and by removing the limit on how many team members you can have creating, running, and getting value out of testing in a single workspace.
With mabl, you don’t pay for seats in your workspace, so no matter how large your team is, you can all work in the same space for the same price. Mabl is a testing tool built for testers of all levels, from product managers looking to lend a hand in test creation to experienced automation engineers with scripting experience and developers looking to run lightning-fast tests against their local branches. We believe that testing is a team sport, and the responsibility of quality falls on every team member. We’ve made it as simple as possible to create and run tests with the mabl Trainer Chrome extension. If you’re just looking to run smoke or regression tests against your local changes, check out our CLI-based headless runner, which by rapidly delivering your test results enables you to spend less time waiting and more time increasing your test coverage. All you need to use both of these is to be part of a mabl workspace.
|
Whether you're testing your local changes or scaling them up into your team's most recent build, |
To create your own workspace and start testing, you can use mabl’s free 14-day trial. Feel free to invite as many of your team members as you’d like to try out mabl as well. If you need help getting started, you can check out our quick start guide or get in touch with us through the in-app Intercom chat.