4 Signs you might need to start Automating your GUI Functional Tests

Reading Time: 2 minutes

There is a vast range of different types of testing. However, in this blog post, we will talk about when you should start automating your GUI Functional Tests. Keep reading!

1.- Manual regression scripts are becoming larger

Test cases become larger as the application continues to have more functionalities each iteration. Hence, we come to a point where our tests are so hard to maintain and perform.

2.- Application is stable enough and there are parts of it that just won’t change in the short term

Changes in software development are pretty common. But, sometimes we get to a point where our application does not require big changes or maintenance every sprint and is stable enough. If that happens, we should start thinking about automating some test cases. Having an application that is stable will provide more value than starting automation when our application is not stable. It does not make sense to automate if automating costs more than the benefits it provides.

If we started automating in an environment that is not prepared for automation we may hay some consequences. For example, we will have a lot of problems and false alarms every time we run the tests.

3.- Your regression tests are consuming more than 15-20% of the sprint time

Regression testing is a chunk of planned work that the QA team must complete prior to releasing new stuff to production. Nevertheless, it can become a bottleneck for releases as a result of having larger regression scripts when our application becomes bigger.

An agile team that uses SCRUM as methodology takes 10 days for a sprint to be completed. Therefore, if your regression tests require up to two days (20% of the time) to be completed, you should start considering automating critical and complex paths.

4.- You have complex and repeatable test scenarios in your scripts

If your workflows are becoming more complex yet repeatable, you should start taking into account automating your test cases. This will also increase the ROI (Return of Investment). That will allow QA teams to perform more thorough tests on new functionalities that do not require automation for the moment (as they might only require more engineering and test maintenance).


Keeping those signs in mind does not necessarily mean that our applications are ready to be automated. Automation can take its time, especially when our project does not align with the best practices when it comes to introducing automation for the first time. There will be certain details that should be taken into account. E.g. our project already has a testable architecture, at least unit tests for the scenarios that will be automated). But, we could talk about this specific topic in a near future.

Another thing to keep in mind is that once we get to a point where we could start Automation, it does not mean we should deprecate manual processes. Automation will only be a tool to reach the quality level we are looking for, not as a full replacement for manual tests.

You May Also Like