Enterprise Boozang: Aligning tests with code branches

Tips & Tricks, New Features

Enterprise Boozang: Aligning tests with code branches

This article explains how to align your test automation work in a software project running on several branches at once.

Boozang is Cloud-based and uses it’s own servers to store the test automation scripts that is created. As developers might use a versioning system for their code, it’s often desirable to align the test automation code with the code in the versioning system.

Imagine the following typical scenario. The code being developed is maintained in 3 different branches

  • master – the master branch
  • ver40 – an upcoming (disruptive) version of the product
  • release – branch used to make product releases

The master branch is being used for the normal work-flow, adding bug fixes and minor code updates on a daily basis. The “ver40” branch represent a future release, and is actually “ahead” of master. The release branch is “behind” master and is used to create stable releases into production.

This setup is fairly typical, and it’s not uncommon that different parts of the development team are working on different branches. Maybe half the team are working on master branch, and half the team is working on the “ver40” branch.

The challenge in test automation would be to allow for the creation of new tests for “ver40” features, without breaking any of the existing tests. In Boozang, the easiest way to handle this is simply to replicate the exact branches on the Boozang side.

Simply use the “master” test branch for maintaining tests for “master”, “ver40” for tests on “ver40”, and the “release” branch for the release. This probably means that all your CI jobs are being run from the “release” branch.

Imagine the follow regular release at the end of a Sprint

  • Code “master” merges into “release”
  • Test “master” merges into “release” to prepare for CI runs
  • Release is deployed into staging
  • CI runs regression tests on code (on “release”)
  • Release is deployed into production

Now, imagine a larger release when “ver40” needs to be deployed.

  • Code “dev40” merges into “release”
  • Test “dev40” merges into “release” to prepare for CI runs
  • Release is deployed into staging
  • CI runs regression tests on code (on “release”)
  • Release is deployed into production

As you can see, you can maintain the same ways of working in these two cases. There are some benefits with this approach

  • No big lag time to build test automation for “dev40” features.
  • Less dramatic release event

There are also some drawbacks

  • Need bandwidth to work on several test automation branches at once

In the end, you decide what works for your team.

Create your account for free!

No credit card required.