More deterministic tests + better signal-to-noise with branch ‘cross-targeting’

A Tale of Two Repositories

Maintaining a stable branch

In the mainstream app development world, every organization (hopefully) carries both a stable and unstable branch. The names might change — release or master for stable, integration or dev for unstable — but the theme is the same:

  • Continuously maintain a version of our code which is more reliable / less buggy
  • Carefully curate / manage changes to this branch
  • If a bug is found in production, we can “hotfix” against stable quickly
  • Bettter understood code, less fear of breaking changes

If you don’t maintain a stable branch, then your main branch is _unstable_

Implementing an automation-stable branch

We create a new branch in our automation repo. Next, remove cruft, old tests, old libraries. Assign a test developer on cleanup duty for a week or two (three?).

  • Merge your new automation features to unstable first
  • Run all new functionality first in unstable
  • Once a test has burned in successfully with other code, then you can promote that change to stable and let it play for the adults.


At first blush, you might think that stable tests stable and vice versa. But that is actually exactly wrong. What we actually want is a cross pattern, like so:

Two different test vectors, two different priorities

With an “unstable” or development branch for automation, we’re now free to take more risks.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Add Lightness | Better Testing, Better Software

Add Lightness | Better Testing, Better Software


A software dev in test thinking against the grain. “To go faster, simplify, then add lightness.” ~Colin Chapman #cleancode #minaswan #innovate