Unlike app development, QA automation always deals with two codebases in parallel: 1) automation code, 2) the actual application under test. Let’s take a look at the relationship between these two – specifically, stable and unstable branches, and how “cross-targeting” these branches can improve your automation results big time.



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



It’s a lesson learned in ~blood~ lost profits. Unfortunately, many or most QA automation efforts don’t implement such a system. Which leads to our next point:

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



Implementing an automation-stable branch



  • merge your new automation features to unstable first
  • run your new tests in autom-unstable
  • carefully promote changes to stable only when they’re proved in unstable first

Cross-targeting

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:



In this scenario, we are isolating instability to only one of the two applications. When we see bugs, we have a high degree of confidence where the problem lies.

Additionally, when we we have an “unstable” branch for automation, we’re now free to take more risks without cluttering up the main pipeline. We can restrict messaging / alerts on autom-unstable to QA only. We can make complex refactors and cleanups, break and fix and re-break, and all the noise from these failures is completely isolated. Your cleanup of a core helper class, your upgrade to python requests, just f**ked up the whole ballgame and nobody ever needs to know.



Two test vectors, two different priorities

For each test direction or vector, we need to consider, “which of the two codebases are we trying to test”?



By establishing an automation-stable branch and curating it with care, we can cross-target our repositories for a dramatic improvement in performance.

It’s a fair amount of work of course.

But consider: it’s also a lot of work chasing bugs around. You’re uncertain about the state of QA at a given time. You’re afraid to cleanup or refactor. That’s a lot of work too and that work sucks.

You can clean your room or leave it a mess. Either way it’s work. One way is painful – one way is professional.

Happy branching !