IT Software development and delivery live today live their best years. It is an integral part of every financial, insurance, merchandise, logistics, or online activity around the world. And each of us — users of webpages, apps, software, online services — have a very good notion of what kind of product we want to experience, use and incorporate into our busy schedule.
To cut the long story short — each company, bringing IT products into the market, wants to ship reliable products fast and within budgets. Usually not releasing is costlier than release and deal with customer feedback afterward. Companies are challenged to use available financial resources and dedicated team efforts in the most effective way.
In this light I want to explore one of the notions, that is always in the air, sometimes even blinding. It is the expectation that there is a straightforward option to save money while automating tests. (For the sake of clarity — you could not automate testing, as this is an activity done by humans using their experience and knowledge. We automate tests, scripts, scenarios, or checks. If you want to automate testing, we could start talking about automating management as well…. )
The logic behind bottom line accounting is simple:
- we invest in creating automated checks
- automated checks could be executed faster in comparison with manual work
- people who perform manual tests have less work to do
- a company could save money while you need less testing
However, the not-so-obvious fact is also true — nothing in system delivery is simple. Where and how people spent their time could not be measured linear as one sum game.
I would like to suggest an alternative view, what automation could do to your company: If you automate simpler or repetitive tasks, finally your team could work on what matters.
In other words, you get more benefit from the money you spent. Time spent and cost of that time are to simplified measure and do not disclose intangible value, created by the project team.
Let us take a closer look at what happens when you automate tests across the delivery chain (unit tests, API tests, code checks, system integration tests, responsiveness tests, etc):
- at first, it costs more money than anticipated. It takes time to build a solid automated test coverage, thus for a few months, several people continue executing tests manually and supporting automation.
- at some stage, the team starts saving time while executing automated checks after each deployment or built. The test team could concentrate on testing new functionality or exploring not tested areas. As a result, the risk to ship undiscovered defects into production is reduced.
- later, it is possible to reduce manual testing of business or stakeholders, while many checks were already done by the scripts. While business analysts or Product Owners are freed from long-lasting acceptance testing, they could invest more time clarifying requirements with clients, trying prototypes, or analyzing user behavior.
- The fun continues! Unit test coverage helps developers built working software from the first try, reducing the time needed for rework Also, a fixed bug is itself tested with unit test, reducing the risk of being sent back to the developer again. So now a development team has more time to discuss the architecture model, initiate refactoring, or simply deliver more new features.
- Finally, with fewer bugs reaching production, operation and maintenance teams invest their time into monitoring and infrastructure error prevention solutions, automate releases or clean up databases for better performance.
In the end, it might cost you the same, but the work that is required is more fulfilling, less stressful, and more meaningful for the development cycle. You might even notice that you do not save money, but you earn more, as customers are happy with your product and are keen to recommend it, use it, or buy premium subscriptions.
I wish us all meaningful projects, where we are guided to achieve good results, not to minimize or avoid negative outcomes.