These lessons are my personal favorites from the book “Lessons Learned in Software Testing” and I discuss why they are of particular importance, but I deliberately left out lessons from Chapter 5: Automating Testing.

There are two reasons for this:

  • It’s a huge chapter with 40 lessons
  • I’m an automation engineer, so issues and challenges in automation are of particular importance to me

So I couldn’t resist but write a separate story discussing the most important lessons on automation. I like and agree with most of those 40 lessons, so it was a challenge to pick the top ones. I applied two criteria to do so:

  • Lessons that reflect the most **frequent **issues I encountered throughout my career or heard from others
  • Lessons that highlight high-impact issues

1. Don’t automate a mess

Lesson #107

Frequency: medium

Impact: very high

You’ve read some documentation about the System Under Test (SUT), you’ve had several sessions with your colleagues who explained the SUT to you, and now you’re tempted to get started, automate some tests, and show others how you add value to the project!

But you’re probably not ready yet! Before you write your first line of automation code, please invest more time into gaining a greater understanding of what you’re dealing with. Be curious, ask for greater detail. A single innocent fact might significantly alter your understanding and impact your course of action.

You may have heard this classic quote by Bill Gates:

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

Or as the authors of the book put it even more succinctly:

If you have bad tests, automation can help you do bad testing faster.

Indeed, the universal Garbage-In-Garbage-Out (GIGO) law applies to automation as well.

Did you receive a suite of tests created by manual testers and your job is to convert them to code? I’ve never seen this work well. Manual testers create tests to suit their needs (that’s OK) without understanding the challenges of automation. The resulting automated tests are clunky at best, unmaintainable at worst.

Also, are you knowledgeable enough to challenge some of the tests done by others? Perhaps they’re wrong, or there is a gap, or there is an overlap, or many scenarios verify multiple things, or the suite is poorly structured? If you don’t know the SUT well enough, you will miss these flaws and “migrate” them right into your codebase.

As an Automation Engineer, it is absolutely your job to gain an understanding of the domain and the SUT that is deep and broad enough to create robust, valuable test scenarios yourself!

Tests and the testing process are directly under your control and as a QA professional, you should ensure high quality of what you do.

Of course, other factors may be less under your control, such as a large, complex, and unstable testing environment or developers not writing unit tests, but those are separate matters.

#testing #quality-assurance #programming #coding #test-automation

My Top 5 lessons on Test Automation
1.15 GEEK