Your Developers Need to Be Writing Automated Tests

This article is written for the CEO, Founder, or Entrepreneur who is making leadership decisions for a software product company. However, some Developers really need to hear this too. I’m going to cover what Automated Tests are, why they’re important, and why not writing them is unacceptable.

What are Automated Tests?

Think about the last time you needed to service your vehicle. How did you know that there was an issue in the first place? Chances are, it was from an Automated Test. When you start your car, it runs through a bunch of Automated Tests and tells you if the oil pressure is low, the battery is weak, or the brakes are malfunctioning. These are tests that are too tedious for a human to do on a regular basis, so they’re automated. This way, you are alerted if a problem pops up. What would happen if you didn’t know that your oil pressure was low? You’d probably destroy the engine before the next oil change.

While this is a great example of Automated Tests, it’s an apples and oranges comparison. In actuality, your car is a static product. Apart from some of the newer E.V.s, which are becoming more and more a software product themselves, the car isn’t receiving new features and changes that might cause them to malfunction. They’re just getting used and sometimes require maintenance. Automated Tests are even more important in a software product because you are constantly changing and improving the product while it’s being used more and more. The more good work your doing, the more opportunities there are for a bug to arise. This bug may not leave you stranded at a gas station in the middle of nowhere, but it might break your signup flow, payment processing, or other core functionalities in your application.

Developers use testing frameworks to write tests that state how the application should function in certain situations and all of the tests can be run in convenient ways. It’s common for your automated deployment process to run tests and halt if any of the tests fail, keeping buggy code from making it to your users.

Why are Automated Tests important?

The obvious answer to this question is that Automated Tests alert you to problems before they negatively impact your users. Without this, users would have to report bugs to your support team, the support team would have to triage these reports, QA would vet the bug reports and then Engineering would have to fix the bugs. You can see the inefficiency with this approach, not to mention the frustration felt by your users. Automated Tests allow Developers to work much more efficiently and limit the impact of mistakes, shielding everyone else. This means that a QA team becomes much more optional, and the Customer Support team can be leaner as well.

There is another major benefit to writing automated tests. Automated Tests become the best possible documentation of your codebase. Have you ever tried to document a complex and ever changing system? It can be a futile task. The person that documents a section of functionality doesn’t know that someone else has changed it and the documentation is doomed to be inaccurate in no time.

However, imagine that the first person instead wrote an automated test that stated “when a this action is taken with these circumstances, the result should be this”. Now, when the second person comes along and made changes to the product that change the expected result, the test will fail. That second person will review the notes around that test and verify that the result should indeed be different, and they will update the test and the notes accordingly. This forces this “documentation” to stay up to date, and any new person on the team can easily read the reasoning behind the behaviors of the application. This value will be felt as soon as you make your second engineering hire, and it will multiply from there.

Automated Tests are a requirement for modern Software Development.

I’ve heard all the excuses, they usually take the following forms:

• We can’t afford to spend time on this. We’ll come back to it later.

• We’ll just let the users report bugs.

• That’s why we hired a QA Team.

• We don’t make mistakes, so we don’t need tests.

I’ve already described the efficiency gains from having Automated Tests, both within the Engineering Team and for the business as a whole. I can also assure you that once the frameworks are in use, writing tests directly add about 10% of time to a particular code change. But indirectly, they save you tremendous time because you don’t have to test all the other features and functionality with each change.

If you’re okay with users experiencing bugs and being forced to report them back to you, then I’m not even sure why you’re reading this article and on this website at all. That should be considered unacceptable and you should be ashamed! It doesn’t matter what industry you’re in or if you do or don’t have competition. You want your users to love your product, so you need to protect them from the mistakes of your team.

If you have a QA team, that’s awesome. They’re still humans who you’re probably paying for their time, right? You want to automate the tedious stuff and use their time wisely. In my experience, its still best for the Engineers to drive the feature-related automated tests. The QA team will come up with automated tests of their own, which are usually more holistic in nature.

I once heard a Developer in an interview say that he and his coworkers are world class Developers who don’t make mistakes, and that’s why he doesn’t write test coverage. This argument is hot garbage. Show me a world class Developer that doesn’t write tests and I’ll show you a delusional Junior Developer. World class software requires a thorough, methodical approach, not shortcuts and excuses.

Once you’ve absorbed all of these points, there’s one last thing to consider, and it has a multiplier effect. Most of the test coverage that needs to be written CANNOT be written after the fact. If you wait to write tests “until later”, you’ll lose the context needed to write good ones. And if you don’t think you have time to spend an extra 20 minutes today to write a test, you’re not going to be able to swallow a multi-month effort to backfill all of your test coverage. This is one of those things that needs to be done as you go. “Later” will never become a reality.

Conclusion: Write Automated Tests

I hope that I’ve demonstrated why Automated Tests are so important. Don’t make excuses and don’t put it off. Align your leadership team around prioritizing Automated Tests. You won’t regret it.