Test Automation is code! Why developers need to own automation
This event has passed
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 it's 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
• ... and about half a dozen more programming principles and concepts
Who do you have on your teams that is really good at these things? You guessed it.: developers. But you protest, "If developers are writing automation, then they won't have time to write all these new fantastic features in the backlog."
Well, there certainly would have to be a shift in time allocation...but it probably isn't where you think it will be. And I'll make the case that it's worth it and will make you more productive in the long run.
And I'll also offer a model and approach to managing test automation in a way that will enable those eager manual testers who show aptitude and drive to learn all the hard stuff listed above to become that rock star automation engineer without sending them back to college.
If you are struggling to make forward progress with test automation,
if you spend more time fixing your automated test suites than you do writing new tests,
if your automation test count is going up but your actual quality is going down, or
if you are a manual tester struggling with a mandate to learn automation or else (or if you're the one who made that mandate),
then this talk is for you.
Come take a journey with me and learn how QA and Dev can collaborate for better and more effective test automation.
Allen is Principal Consultant with Improving. He is a passionate Agile Quality Assurance Technical Coaching and Test Automation Engineer. He has 25 years of experience providing leadership and technology solutions in a variety of organizations across multiple industries. He loves cultivating quality through mentoring and training and has designed and implemented a number of test automation frameworks for all levels of testing. His wife says he's a "scruffy looking nerf herder," especially now with his quarantine hairdo.
Don’t miss your chance, register now
More Learning Events
Join us wherever you are in the world as we share some knowledge – hosted by our Improvers.