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.
Table of Contents
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 software 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.