Why Test Automation is Important, Especially For Startups
When you start a software startup your goal is to build software that can deliver value for your customers. When you are laser-focused on your goal you might think that anything that doesn’t directly impact the goal is not a priority. That’s why most startups focus all their efforts on building the core software or on app development. Only when release day comes do they start manually testing the software, and the shit hits the fan. It only works for the “happy path” – if at all.
Whats wrong is very simple: testing too late and testing wrong. They should have used automated testing from day 1. They should have run tests on each code change committed to the code-base. In this post we are going to reiterate the importance of using automated tests and the improvements it can have on your process.
If this is your first introduction to the topic, I suggest you read our previous blog post on Automated Testing.
A regression is when a bug you have already fixed resurfaces in your product. It happens frequently when your projects get bigger, or when multiple developers maintain the code-base. Maybe you get into your old code, change a few lines to add a new feature or fix a bug. You don’t see it but you actually create a new bug. One or more features that were working before are now broken. If you’re lucky, it will be part of the main functionality of your software and you find it quickly. If not, it could be a feature used less frequently, and takes the testing team (if you have one) or your clients a few weeks to encounter it. By that time, finding the source of the issue is like deep sea diving expedition.
The problem is not buggy code. Everyone can write buggy code from time to time. The issue is that the bug wasn’t caught. No one was testing the feature you broke at the time you broke it. It was working last time somebody checked it. Time is not your friend here. By the time the broken feature is found, you have no idea that small change you made a few weeks back is the reason. You need to put on your diving suit and dive deep into your code to debug it. That few lines of code are now look like a needle in a haystack.
If only there were a way to test all functionalities of your code each time you made a code change. (Spoiler alert: There is.)
The Spring Effect
As tech entrepreneurs we often tend to disregard the spring effect. There are some activities that you can spend time on at the start of a project which don’t seem to be completely aligned with your project goal. At times they might look counterintuitive or too time consuming, but they will speed up your process as you go. They not only make up for the time you spent on them initially, but actually decrease the time it will take to complete the project overall. I call this the Spring Effect. You need to spend time and energy to compress the spring and although it looks as though you are going backward, the end result is that you spring forward so much faster than ever possible before.
Automated testing has exactly that effect on development efforts. At first it feels like it’s just taking up time, but by the time the project is further along, you can see that it gives back the time you spent on it and has made the whole project more efficient and reliable.
Developers hate writing tests, until they do
Ask any developer who hasn’t build tests for a living before, and they will tell you that writing tests is a waste of time. It slows down the process and adds time to projects.
If you ask them (or force them) to write automated tests for one of the projects they are working on from start to finish, they (and you) will see what was thought to be a waste of time resulted in less bugs, faster bug fixes and the project being completed faster overall.
The truth is that the only thing developers hate more than writing tests is fixing bugs. If you tell them (or better yet, show them) that by writing and running automated tests they will have an easier time fixing bugs, they will do it no questions asked. They will become fans of writing tests because they will spend less time debugging and looking for “what went wrong”.
Bigger gains for smaller teams
Something I’ve heard from many tech entrepreneurs is, “We’re too small to spend time on testing”. Another phrase I hear frequently is “we build quality code” (who doesn’t) or that “our code is bug free” (really?).
The fact is that small startups need automated testing more than big corporations. It’s simple math: unlike the big corporations you don’t have deep pockets to throw people at a problem. Making a mistake could be deadly for you while the big corporations can survive mistakes. You need to use all the possible efficiency tricks you can and automated tests is one of the most useful ones.
This is not the only reason. Small teams grow and form cultures. If you don’t have the discipline of building automated tests when you’re small, as you grow your development team adds more test-hating types to the team. By that point, you can’t ask them to have the discipline. Without leading by example, the results are costly and ongoing.