This is a sentence that 99% of engineers have uttered at some point in time that at its core often unearths a lack of understanding of the value that automation tests provide. We don't write tests to hide behind N% test coverage stats, or even to ensure that zero bugs reach production. Tests are the fastest option to give us confidence that the code we are writing is behaving as we expect it to in a repeatable way and that any current or future code changes do not alter that fact.

Countering the "Speed" argument

So why do some engineers continue to fall back on this fugazi? If we probe a little further and ask "How are you testing your code changes?" we can examine that a little further and try to counter some common answers.

1. "I am not testing my changes, there isn't time"

   There's not much explanation needed as to why it is a bad idea that will wreak havoc on the system. Engineers make lots of mistakes and they are passing every mistake directly through to the end users. I'm sure they will be very appreciative of that..... 😀

2. "I am debugging through the code"
   Some engineers will resist a couple of minutes (it can be even less with good templating) it takes to create a test class and add some simple unit tests. Yet they will spend hours of their week manually debugging code and checking what happens to each variable after each line is executed.

3. "I am visually checking it in my development system"
   Not only does this have similar stumbling blocks as debugging through the code, but it brings us to another phrase every engineer has uttered: "It worked on my machine". Why wouldn't we instead opt for the route that allows us to test the code in a repeatable way in any environment available to us?

4. "I'll write tests later"
   Ha - no, they won't. Writing testable code drives how our code is structured. Writing tests later is much more difficult. Add complications such as context switching and other engineers making changes without tests being in place and you can quickly see how absurd it is.

5. "The QA Team will catch it"

   A dedicated QA team to write automation tests or to manually test changes is an anti-pattern. It inevitably causes a lead time of days/weeks/months, which carries over to long periods with no value being provided to users.

   Expecting another person to understand the code and what it should be doing as much as the person that wrote the code is unfair. There will be lots of questions back and forth between QA and Dev, meetings about test scripts, bugs raised for expected functionality etc. This is all time that could be spent more wisely. See an example below of a small bug being found.

   

   When we compare this to the same scenario with the developer writing automation tests, we can see which one is faster in the short term.

   

Inciting Wider Change

If a dedicated QA team is the approach an organization has opted for then it is a much bigger challenge to incite change in comparison with convincing a single engineer writing tests is valuable. One suggestion would be to have those dedicated QA engineers focus on enabling the writing/execution of tests so it is as easy and fast as possible. Engineers are lazy (especially me) and will take the path of least resistance. If you can make writing tests that path then they will shortly follow.

Another suggestion is to start small and focus on the areas you can influence. Start writing tests for just your code and ask others in your team to try the same. When the tests provide value (finding a bug before it reaches QA, reducing bug reports, features reaching production more often) celebrate that win in a public way and encourage other teams to try the same. If you can show that the small amount of time you invest in writing tests, is saving you time and the company money, most logical people will recognize that.