Why test automation is so important in project life
Automation testing is a popular buzzword. The goal of this action is clear: to save time and money. So why, in the world of IT projects, especially in the group of Managers and Developers, do we happen to hear:
“Automation tests suck. It’s not efficient, costs too much, you need to spend too much time on it, have a qualified team of testers or developers, the client won’t pay for it…”
Haven’t we read it somewhere before? Was it in ‘The A word’ book? The one that is used to be popular recently? No. It’s just the sad reality of project life.
So, is that really the cost, is that the lack of client’s knowledge (yes, it’s always easy to blame the client for the project situation) or is that nothing more than being used to the overall opinion without even testing it? Yes, testers, every solution needs to be tested first in order to talk about it, simply do not listen to the opinions. If something is new and quite exotic, that simply doesn’t mean it is bad. And that may be… well, not a good opinion at all. As a matter of fact, this is just rumours about the common myth and a lot and lot…of lack of knowledge.
To think about it deeper, test automation is not as bad as it may seem. This is not the nightmare that wakes you up before every deployment. If you are a programmer, you probably hate testing. But test automation is also about coding. Well, let’s be honest, if you write the tests – you code. So a test automation engineer is also a developer.
Then, you are not so different, are you?
From the ‘management’ perspective it may be all about the money. Test automation means coding. Coding means time and high-level skills. So, altogether – paying more. But do you really think it is only about money?
Let’s focus on the way we automate, the tools we use and the time we spend on it.
Probably we will use the tools that let us scale the automation process freely. We also should use the same programming language that the project relies on. The more time we spend on processes automation, the less time we will spend later on doing things manually. So if you think money-wise, probably spending more at the beginning will mean spending tons less later.
Test automation vs project reality
In reality, test automation may protect you against bugs getting back from production and loss of money due to angry clients demanding their apps to be clear, eye-catching and work fine together with the low cost and short-time effort. It is really worth investing some time and money not to lose it later in a much more ‘dirty’ way.
Every time you think about any process in your company or your project, always think about optimization. Regardless of the cost, test automation will reduce the overall impact of the bad things that may happen in the process.
When software goes bad, it creates a domino effect that isn’t pretty. Performance failures like apps crashing or components shutting down (defects) can be devastating to a company, causing a substantial reduction in ROI, suspended production, loss of customer confidence, and loss of enterprise reputation.
(Here to my mind comes the famous example of Flud, which was a social news reader application dedicated for iOS, Android, and Windows Phone. Unfortunately, the startup failed because of poor Q&A services. The aim of the Flud team was the development process and its main goal was to create code. When the product was finally released, it was bug-infested and loaded with mismatches. No matter that everything was fixed, the bad reputation and awful user experience prevented its success. )
Automated testing is prevention, not a cure
The tests by themselves won’t fix the problem or guarantee success. It’s about the proper estimation and continuous integration, which also means the building process and automation of every other.
The test automation without any relevant, easily deployed framework makes no sense. We need to choose the one which answers the questions and meets the needs of not only one but at least two or three existing projects which the company has done. The framework should be easy to implement. Is there any way to handle this along with reducing the costs? Yes, there is. One word – Gherkin. The business-oriented language may be used for writing tests scenarios, estimation, automation and many more. Using Gherkin language, it is pretty easy to reduce the costs and answer most of the project needs.
You may think to yourself now ‘But… wait. This still needs some adjustments or knowledge. And it won’t stop the bad feeling. Some extra people need to be hired to handle the additional tools, to teach the processes, best practices, new language, programming languages, etc. And what about the administrative things? What about maintaining the scripts, the changes?’ Do not worry. I will go through all of the steps and show you how to do it in an easy, fast and efficient way, without a lot of knowledge.
Now, what needs to be done to avoid such situations, concerns and problems:
- Use the framework or write your own. Whether it’s simple or complicated, use the one that suits your needs. From a business perspective you may want to take a look at the Gherkin language to maintain scenarios.
- Gather scenarios and create the database for them.
- Gather the estimations for each scenario as well. Use them for the future estimations or business offers.
- Play with them, create or use the tools to change the scenarios into the automated tests.
- Make some effort, learn a new language or give your testers a try to learn it. The opportunity of self-development is sometimes more valuable than a pay rise (not saying that more money for new skills wouldn’t motivate more). Invest in yourself and the team that creates the product for you.
- Include CI in your process and connect it with the test automation. Spend less time on testing common scenarios, focus more on the other testing areas; decreasing the technical debt, lower the overall cost of maintaining the software in the future.
Looking for support in automation testing? Just let us know.
