“It will be easier to get people to write automated tests if we make it easier to write the tests.”

I hear this a lot. It seems sensible. It it also ineffective.

The key to getting dev teams to write automated tests isn’t reducing friction. Friction isn’t the issue. It doesn’t matter if you can get things to a point where it only takes a few minutes to write tests for a feature that took days to build. Those tests will not get written unless there is value seen from having those tests.

That value also has to be instrinsic. “My boss told me to do this” or “Everyone says this is important” are not intrinsic. People need to believe that automated tests will make their lives better. Otherwise, any cost in time, no matter how small, will just be a cost. People will feel like they’re spending time for nothing, even if they won’t say it.

I remember the exact moment I started believing in the value of automated tests. I was at an e-commerce company where a critical part of our product was a dynamic pricing “algorithm”. I use that term loosely because it was a massive if/else statement, with a deep level of nested if/else statements, and no tests.

There was a collective groan from the team every time a bug was reported in this code. It always took days to investigate and fix. The fixes were always tiny. And of course regressions kept popping up because the code was barely comprehensible. These bugs seemed to pop up every other week.

There was an intentional revamp of the entire pricing structure across all products to ensure that prices reflected our real costs. This was the perfect opportunity to rewrite this code since it was all going to change anyway. The developer who did the rewrite made sure to include tests this time around.

Fast forward a week after release of this new code. The original developer was sick. A bug did pop up in the code. I volunteered to look into it.

It took me all of 15 minutes to investigate code I had barely seen, find the missing test, find the bug, fix it, update the test, and deploy it all to production. I had never heard of another bug in that code since.

That is the power of automated testing. That is when I started feeling the value instead of just hearing about it from others. I was brimming with intrinsic motivation to write more tests. I’ve been adamant about writing tests ever since. It has been a boon to both my professional career and my personal endeavours.

The challenge of course is that not everyone will have that same opportunity I had. Ideally, your systems never end up in such a poor state that such a contrast is possible.

So how can we get our teams to write automated tests if we have team members who haven’t felt the value?

I’ve tried mandating tests for bug fixes and new features. It sounds reasonable if you have a large untested system and no time to backfill tests for everything. The problem with this is it will take significantly longer for the value of those tests to be utilized. You may be slowly increasing the test coverage of the entire system, but you can’t actually rely on the tests for any release because there are so many gaps.

Every time your developers write a test, they will conciously or subconsciously think “what is the point?” There aren’t enough tests written to be able to trust them without also running a whole bunch of manual tests before each release.

What is more effective is to get to 100% coverage for some aspect of the system. The result is that you will still have to do heavy manual testing for most of your releases. However, for releases where changes are confined to the part of your system with 100% coverage, you can have confidence in doing that release without running all your manual tests. There is now a strong contrast for your team when they work in a tested system versus the untested system. This is similar to the situation I was in when I first realized the value of tests.

Side note: when I say 100% coverage, I mean in terms of use cases. Not code coverage. Very important difference that I will get into in a future post.

The good experiences with the tested part of your systems versus the bad experiences with the untested parts creates a strong motivation for your team to get more parts of the system tested. Every time they can do a release with little to no manual testing, they will itch to get every release to be like that. You’ll never have to worry about people maybe skipping tests if you’re not around. They’ll be believers and want to write the tests.