Test Automation For Small Companies
Test Automation For Small Companies
There is always this one thing that, if done, has a dramatic impact. Like having kids. If you have kids, think about the impact. In the end, what would you do without them? I assume, that is not a scenario you would like to imagine.
But remember back, when you were unsure about having kids… too young, might change job, not enough money, right partner etc.. All of those doubts that you had in mind. But you did it, the impact was huge and in the end it is the best that could have happened to you.
Most of the time I see small IT companies struggle. Struggle with what they believe they do the best: Developing their software and being successful at the same time. If, on the other side, your company doesn’t struggle you can skip this blog post as it will not affect you and you might not even understand the pain most of us suffer.
Small companies struggle with software development
This blog post will not provide you with the universal truth on how to fix your problems but it will tell you why we struggled from a software development perspective. It is as simple as: Because customers started to use our product. There is typically the R&D phase, followed by the operational phase (leaving Continuous Delivery projects aside). In R&D everything is fine, your small team develops the software, you get the first user opinions, you develop exactly the features users wanted, the developers fix a few bugs they found and the software can be delivered.
Afterwards the operational phase starts and customers really start to use your software. And, as with all software, they will find defects. It might be a feature they thought should work different or it might be a real bug. While your customers start finding those defects your developers start fixing the bugs and might implement some change requests to fine tune the features.
Next release, new round of bugs. Next release, new round of bugs. Next release, new round of bugs. And the worst are bugs in areas that worked before, as those make the customer mad.
When the problem happened
My experience from multiple projects: It happened before the first version was released to the market, before you became successful.
Let’s discuss: If you challenge any of my points or have a different or even completely different experience, I am interested in your story. Leave a comment at the bottom or send me an email.
Simple answer: You are not able to proof the quality of your software in a reproducible way. Read this sentence again. It is not that you are not able to do it, but you missed the chance to implement a system that allows you to proof that your software works and continues to work even after changes.
You know why, because you felt in the development trap: As a small software company you develop software. Developers write unit tests and unit tests guarantee quality. Because they guarantee quality you did not even look in how to challenge your software like the customers will. Unit tests are a good start, but trust me on that, your customers will not use individual functions from your source code, but will use an integrated system. For instance:They click a button. You fully understand (as you are in a small company you most likely have some kind of development background), that this click of a button triggers a chain of interconnected functions defined on objects that are linking to each other. While you test the easy way with unit tests, your customers take the «difficult» route by clicking a button.
Think about your software development as a production chain. Like a car manufacturer. They need multiple prototypes to setup the serial production of cars. Once they think everything is ready, they start a small Series-0 production, just to make sure everything is really ready. And afterwards serial production starts.
Hopefully, you have already guessed it: Your continuous integration pipeline a.k.a. DevOps pipeline is exactly that production line.
At this point in time you might ask “Where is the problem, I do have all of this”. Congratulations, you are already far ahead of a lot of other companies in your sector BUT I still assume that you missed a critical part in your production line: The quality check.
The quality check: That is were small companies have developers, their unit-tests and some manual testing by the same developers or other people in the company. Why? Because automated end-to-end testing is expensive. And that is a given, it is expensive if you don’t become successful but it is even more expensive to become successful and then notice that you cannot keep up with your success.
In my experience: Every company misses the importance of testing. But while big companies have the budget to just survive and fix this later on – and trust me, testing is always an afterthought – small companies usually do not.
While you can rely on community driven testing tools that are free, keep in mind that the community will drive your testing.
Let’s say the community agrees that a new pattern is way cooler than the current one. The next version of the testing framework you have just implemented behaves completely different. If you don’t have the resources to keep up with this changing landscape, you should rely on a test automation platform that supports independent test engines in independent run time environments.
Is the real problem testing? That is a great question you have asked. My answer would be “no”. There is always a single root cause to all problems: Resources. If you would have unlimited time with unlimited money and unlimited people you could do everything perfect. But resources are limited and therefore you need to accept risks.
Speaking about risks, the only possible option is to mitigate the risks as good as possible. And for small companies that doesn’t need to be “No Testing”.
If you have 30 minutes, let’s do a short assessment and see what testing is possible with the resources available to you. Over the years I have seen many projects succeed and some projects fail. Those that failed did not always fail because of the quality but those that succeeded always had a good testing strategy.