Using Test Branches to Test Early in the Development Cycle

Heraclitus, a Greek philosopher, once said that "change is the only constant in life." These words fit perfectly with today's agile approach to software development and continuous delivery through a CI/CD pipeline. In this environment of continuous software change, it is extremely hard to keep up with testing and often times teams will compromise quality in favor of speed. Why make this compromise? There has to be a way to have both, speed and quality.

You may also like: Git Branching Strategies for Maintainable Test Automation

To deliver quality software at the speed of DevOps, we at mabl believe that it is paramount to have intelligent CI/CD pipelines that make it possible to test end-to-end user journeys and the whole product experience — including emails, production documentation, and marketing site — as early in the development cycle as possible.

Introducing Test Branching

Building towards this vision, we are excited to announce support for test branching so you can shift your web UI testing further to the left and test features under development without impacting core smoke and regression testing plans.

If you already have some familiarity with git branches and the pull request workflow in GitHub, you will feel right at home working with branches in mabl.

Test branches are useful when you want to:

• Test development branches without impacting your core test suites
• Experiment with tests and get peer feedback prior to "committing" test changes
• Run different versions of the same test across different environments (e.g. dev vs prod)
• Promote tests together with code across CI/CD environments with the help of mabl CLI

 

The last two use cases above are not quite supported yet but don't worry. We are hard at work to make it happen. Also, it will not be long before you can save tests on a branch from the mabl CLI and run those tests on your local machine instead of the mabl cloud.

How Does Branching Support Shift Left in Testing?

In case you are new to the idea of shift left, it is a practice where testing is done as early as possible in the development lifecycle with the goal to catch bugs early before users do.

From an organizational perspective, to shift left in testing means that the product org is restructured into squad teams where each squad is composed of individual contributors from different disciplines — research, product, design, engineering, QA.

The team leader is also an individual contributor. In this org setup, software engineers are ultimately responsible for the quality of their code while QA professionals act like individual contributors and quality coaches for the squad.

There's no longer a dedicated QA team that does regression testing on their own before a release goes out. All testing is done continuously with every GitHub pull request (PR) build and deployment to a CI/CD environment. An increasing number of mabl customers are shifting left and reorganizing in squads. The product team at mabl is also organized in a similar way.

We believe that everyone on the team should be able to easily create and run automated UI tests without being burdened by flakiness and test maintenance. And, we have already made great progress in reducing test flakiness and the need for maintenance thanks to auto-healing tests. You can also easily run tests on every deployment and get insights, such as visual changes, directly into Slack.

Adding support for test branching brings us another step closer in helping you shift your testing as far left as possible. Give it a try!

Further Reading

Software Testing Tutorial: How to Perform Testing

DZone's Guide to Performance: Testing and Tuning

DZone's Guide to Automated Testing: Your End-to-End Ecosystem