Home / Blog / Why are automated tests important, though initially undervalued?

Why are automated tests important, though initially undervalued?

11 Apr 2018 | automatic tests QA engineer

There are projects of varying complexity, and indeed in very small projects, automated tests do not translate into ROI. In other words, the work devoted to them will never be repaid. However, if the project is at least average – automated tests will definitely be worth it. I won’t even mention large projects, where the lack of automatic tests is unthinkable for the simple reason. That reason is impossible to manually check everything in a reasonable time frame.

Why companies don’t like automated tests

From a company’s perspective, it is initially difficult to grasp the amount of work that has to be devoted to the introduction of automated tests into a project. Choosing a technology, creating even a simple framework, or finding external libraries to use in the project – all this can be daunting. These things take time – a lot of time – and hard work.

The effects of which aren’t necessarily tangible during the first day or week. In this aspect we are in a worse position than ordinary developers – they write something, the effects are immediate, the company is satisfied. However, with automatic tests, we devote a lot of time, after which we end up with one, two, three tests (which makes us happy, of course) and the company looks and says:

“You took a few days and only three test cases are automated. After all testing manually would take you a few minutes at the most”.

Of course, they would have a point but they have not yet grasped the big picture. At this point, manual testing would take a few minutes. But ultimately the more manual tests, the more time they take. And as often happens later in the life of a product, everyone wants to be sure that newly introduced functionalities do not spoil functionalities that have been working for a long time.

At this point, the company slowly starts to realize the rationale for automated tests. Manual testing every new version would take up tons of tester time. Therefore they would regularly be doing the same task all over again. It’s depending on the cycle of introducing new versions into the environment.

In a two-week cycle, every two weeks the tester has to carry out a regression test which would get longer each time. With a large project, after more than a year of releasing new functionalities, the tester would have to sacrifice a few days for the regression tests themselves. Just leaving little time for manually testing new functionalities, bug verification, and different types of documentation.

automated-tests.jpg

It is worth testing automatically from the beginning of the project

And at this point, automated tests come to the rescue. They verify what needs to work for us all of the time. Of course, if someone only just realizes at this point that it is a good moment to start writing automated tests, then he is in great error. At this point, it’s too late. Even if we introduce a new tester solely for the task of automatic testing, it will take a good amount of time to catch up. Automated tests need to be implemented as soon as possible. Period.

The reason is that at the beginning of a project, the tester still has enough time to embrace the framework and all the necessary tools and get used to them. In the beginning, he will also have the time to form and implement a habit of quickly writing automatic tests. As time goes by, all he has to do is sit back and see if the tests are successful.

Start testing automatically and you’ll make everyone happy

In conclusion. Even though the value of automated tests is not initially obvious, their worth is immeasurable at a later date in the life of a project. No one is happy if a functionality that worked from the first day and stops working after a year. It’s happened just because someone did not have the time or thought to test it when releasing a newer version.

First of all, a dissatisfied customer equals a dissatisfied boss. Secondly a dissatisfied manager – equals a dissatisfied programmer. After that, we have a dissatisfied tester. And that means unhappy tester’s cat. In other words: nobody wants a dissatisfied cat.

Avatar

Michał Trela

“We can do it” is Michał’s motto. Michał thinks outside of the box which is a valuable asset to the team. Michał is interested in sci-fi literature and leading a fit and healthy lifestyle.