Allen Moore

Test Automation is code! Why do developers need to own automation.

What exactly is test automation? I mean, what are the nuts and bolts of this thing that we call test automation? The real nitty-gritty stuff that makes up this magical thing that lets me sip my coffee and (don't tell my boss) browse YouTube while the browser goes off and does its thing without me. You know, like Elon driving riding to work in his Tesla.

When the latest "codeless" or "low code" automation vendor salesperson comes along with their slick demos do you ever wonder HOW their tool does all that magical sounding stuff?

The answer to both questions... “It's code.”

"Codeless" and "Low-code" is marketing speak for, "we wrote a bunch of code for you so you (ostensibly) don't have to". But guess what, you are still going to have to write, or at least maintain, some code.

Here's another question:

Are you wanting all your manual QAs to go learn how to become automation rock stars You might be looking at the hundreds, maybe thousands, of manual test cases in ALM or Jira and the 3-week regression cycle it takes to execute them (ooh, is too ambitious?)  and think, "If our QA/Es can just learn to automate we can cut that time down to days, maybe hours".

Who should own test automation anyway? It should be your Quality Engineers, right? It is, after all, "Testing".  What if I said maybe.  Or maybe not.

If automation is code, then maybe expecting manual testers to build and maintain automation suites is not the most effective approach. 

Consider for a moment: What kinds of things and skills make for robust and maintainable automated test suites?

Here are a few things (this is just a sample):

• IDE/Development environments

• Clear domain-driven layers of abstraction

• Inheritance and composition

• Single responsibility

• Inversion of control

• Builder and object mother patterns