The Hard Truth: Nobody Has Time To Write Tests
Automated testing is a heavily debated topic in our industry. Some feel like it’s the only way to build quality software, while others roll their eyes at silly dogma. Then there are those that fall somewhere in the middle: those that claim to see the benefit of testing but just don’t have the time. I’m going to just go ahead and say it: the harsh reality is that nobody has time to write tests. Unit tests, integration tests, or browser simulation tests; nobody has the time to write them.
The Usual Suspects
Managers — they’re the worst, aren’t they? If only we could have management buy-in, we could all write tests and live happily together! Management always pushes back and says “why should I pay you to write tests when you could write twice as much code instead?!”
Sometimes, the industry moves too fast to write tests. This one is interesting because there are certainly some very fast paced industries out there (looking at you, high frequency trading).
I think this is one we can all relate to: “We don’t need to write tests, we can test it manually. We have an entire QA department for that!” Besides, it takes a human to write the test anyway, right? Why waste our time?
The Interrogation
Management buy-in really could make a lot of difference in some of these cases, however, do you really need it? What if all you had was buy-in from your team?
Industries moving too fast is an interesting case, but you really need to pick your battles. If accuracy doesn’t matter, then all bets are off. However, if accuracy does matter (and honestly, when does it not?), do you want to be the one that lost millions of dollars because you couldn’t be bothered to make sure nothing broke?
I’m truly saving the best for last here: manual testing. Do you really save time with manual testing? Do you really have confidence that your human testers will hit every endpoint in the system every time they test?
Closing the Case
To all of you managers out there, I’m going to try and make this as clear as possible. I understand that you’re worried about paying a programmer’s salary for something that a QA person can do cheaper. I am going to show the short-sighted thinking here:
My entire test suite (about 500 tests) runs in less than a minute. This is a very small test suite, but I’m still trying to catch up from when I started on this project. Let’s say that your QA person can go through these at 10 per minute, which is highly optimistic as that’s input + checking the output in 6 seconds per test. It would take this person 50 minutes to run the same battery of tests. Do you pay your QA team 50x less than you pay your programmers? If not, you are bleeding money!
You might argue that my above math is off, because clearly QA won’t be testing parts of the system unaffected by new features. It’s never a bright idea to assume one part won’t affect another part, and as developers, I’m sure we can all say we’ve been bitten by this when we least expect it. If we don’t test every available endpoint with every known good and bad combination, how much confidence do we have in our system?
A Signed Confession
Writing tests isn’t always easy, fun, or a guarantee. Writing tests is a way to get fast and repeatable results. Remember, the primary goal of testing, automated or not, is to increase confidence; any way we can speed up that feedback loop is a victory.
Nobody has the time to write tests, but true professionals make the time. As I said in my last article, right now is the second best time to start writing tests!
