A product’s lifecycle consists of a few phases: planning, design, development, maintenance and further stages of development. The first two steps require the evaluation of received results, but we won’t focus on them in this article. Further stages of product’s lifecycle are all about reaching the aim established in the previous phases. But why do I even mention the product’s lifecycle?

The main reason behind talking about product lifecycle is that when a project is evaluated, we need to think about how big and complex it may become, how many additional iterations it may have, and how many elements will depend on other elements. If the complexity of the project increases, new issues can come to life. This is where the automation of testing shines.

Not going deep into details, the aim of the automation of tests is:

  • to assure small pieces of code work like they’re supposed to (unit testing),

  • to mock probable paths a user will take in order to do something (end-to-end testing),

  • to ensure a website or application is able to survive normal/above average numbers of connections/users at the same time (load/stress testing),

  • to assure new integrations don’t break the already existing code on various operational systems and browsers (regression testing/continuous integration).

The pros of test automation

Saved time

Yup, that’s it – the best thing about test automation is that it saves time.“Saving time” may sound nonsensical since you’re actually writing even more code, but it’s really handy in the long run. Let’s just imagine that you want to create a huge website. Writing good, automated test suites and executing them will probably take less time than testing such a website manually.

There’s always a risk a new deployment will break the already existing functionalities or have a negative impact on how the website/application looks or loads. A well-written test suite allows monitoring (depending on test coverage) almost all functionalities a website/app offers. It greatly reduces the time required for testing thanks to a few things:

  • already deployed functionalities can be  very quickly tested in each iteration,

  • it’s easier to trace the bug in case anything breaks,

  • growing projects can be maintained more effectively with automated testing,

  • you reduce the chance of a human error (described later).

Think of it as of the investment that pays off in the long run. While the initial testing of a newly-created website will take a bit more time than a standard, manual approach, you’ll be very happy with the results after a few weeks of continuous development of your site.

Reduced costs of automatic tests

It may seem that I’m just retelling what I’ve said in the previous point, but automated testing reduces the overall price of the development and maintenance of a product. The thing is, you can run tests against functionalities multiple times. While the initial cost is greater than in the manual approach, in the long run it’s easy to evaluate the amount of saved money. How is this possible?

Before we start – keep in mind that the next few paragraphs regard a hypothetical situation. Let’s assume the initial part of testing (the phase one) will take approximately 100 hours while developing a test suite will take about 150 hours. You’re probably shaking your head in disbelief, thinking “Extra 50 hours for a few lines of code?”. However, I’m sure that after our recommendations you’ll decide to choose automated testing. While this looks like we’re asking for extra 50 hours just for the development of an initial automated testing suite, it will reduce the cost significantly. Be patient – you’re yet to notice it.

We’re going to phase two now – you’ve changed your website and its functionalities, now you want to add some new elements that are related to the already existing ones. We will probably have to recheck everything. This will either take another 100 hours of manual testing, or around 50 hours in total to rerun our testing suite and add extra test cases to cover new functionalities.

Ok, now let’s go to the third phase. You decided to add even more functionalities and to spice up your website. This time you decided to add new options to your website’s/application’s core features. Again, you have to verify nothing’s wrong with what you’ve already had – and this is where automated tests shine. Provided that you have these in your project, the verification will take up to few minutes, in opposition to hours spent on the manual verification. Even if you want to add tests covering new functionalities to your test suite, it will probably save you time in the future as it’s easier to rerun your core ( initial testing suite) and improve it/add new elements rather than perform manual testing of the whole website over and over again.

Reduced probability of a human error

This, in my opinion, is the biggest advantage of automated testing. How often did you hear such excuses as “Yeah, I know, I just didn’t think about it” or “I just forgot to check it”? If you’re working with people, these are some very common answers to “Why isn’t it working like it’s supposed to?”. You always have to think about the relation between the effectiveness of people’s work compared to automated work when they have to execute same tests over and over again. People may forget to check something or to think about potential issues arising from a newly implemented functionality in the already existing code. That’s why automation is important – a well-written test suite will keep that in check.

Increasing test coverage

We can’t skip the topic of test coverage when talking about automation. The implementation of your tests should be thoroughly planned since aiming for the automation of everything means you’re actually overdoing it. On the other hand, if you want to, for instance, completely ignore unit testing, then you’re exposing your product to software issues that could have been fixed at the early stage of the development. Generally speaking, it’s good to have a decent code coverage and since we’re talking about web development, a good mixture of a unit, integration, and end-to-end testing can be extremely beneficial to your product, while the lack of those may lead to unwanted, not-previously-found issues.

The benefits of code coverage

Firstly, manual testing is more time-consuming in the long run if we are to provide the same quality as in automated testing. Re-running automated tests takes less time than repeatedly doing the same quality control manually, especially when it comes to complex functionalities.

Secondly, you can choose what parts of your website you want to automate. You can touch the surface (end-to-end testing), go deep into methods (unit testing), or check whether nothing has changed after the integration of these two layers (integration testing). You can also focus on ensuring the quality during new iterations of the project (regression testing). These tests are independent and help to find errors, ensuring the high quality of the final product.

Finally, you always know what was (or wasn’t) tested. Sounds simple, but while working on complex projects your team goes through many templates, thousands of code lines and hundreds of possible outcomes of what a user is allowed to do with your website. There’s always a chance that after yet another iteration of tests the team forgets about one small thing, which then can stop working correctly. So, you simply reduce the probability of human error occurrence.

Is choosing automated testing for your next project really worth it?


I won’t beat around the bush – yes, it is, but it’s not always a must-have in your project. It’s more related to how you see your website in the future and what are your expectations for the project. If your plan is to release a small website and simply let it be, then automated testing is something you probably don’t want to use for your project. On the other hand, if you want to develop a robust website with many possible interactions between users, payments, or advanced content management, then you should at least consider the automation of tests as a possibility.