Back to blog home

An overview of frontend automated testing

Frontend automated testing is one of the most efficient ways to ensure that customer-facing systems are fit for purpose. In this overview of automated testing we take a look at some of the main points your business will need to consider.


Here's a summary of high-level considerations we'll explore in this blog post:

  • Planning: how, why and what to test using automation tools
  • Benefits: the main benefits of automation within a project
  • Drawbacks: any downsides of using automated testing tools
  • Process: running your test scripts across the project life cycle
  • Our approach: a quick summary of automated testing within Inviqa


From the outset a decision will need to be made as to which customer journeys your test coverage will take into account.

Most online businesses will have a main customer journey. In the case of ecommerce sites this will usually be the catalogue browsing and checkout process for a customer sale. With this as a starting point the test suite can then be improved over time by covering other business-critical paths – a 'my account' section, search, and register, for example – with a view to achieving as close to complete coverage as possible.
In addition to considering what will be covered, you'll also need to consider which tool to use to execute the automated scripts. There are many different tools on offer – from ones which require some level of programming or coding knowledge, to those which can be used to ‘record and playback’ user journeys.

Here at Inviqa we use a number of different types of tools across our projects to achieve the best-possible results, with a focus on Behat testing at the developer level, and Ghost Inspector for the QA process.
Once you have decided on the customer journeys to be covered, and the tool to be used, the final decision might be which test data to use for the best coverage. You want enough product / purchase / customer data to provide sufficient coverage, but too much data could mean longer test durations.

Knowing the system and the customer actions is the best indicator for how much data is required at this stage. More can always be added at a later point.


One of the primary benefits of automating any form of testing is to remove the repetitive, static, and boring tasks from the QA process – form filling and registration, for example.

Whilst having an immediate benefit in freeing up the QA analyst’s time, this also has a long-term benefit of delivering reliable and reproducible results, increasing accuracy, and improving the overall quality of output from the test function.
With any automated testing tool the user is in complete control of the tests, from creation to running, and can decide what areas to focus on, and how to deliver the desired results
Automated testing can also be used to remove difficult tasks from the QA process, improving test accuracy by removing human error from the process. Over time, as the test suite develops, you should also see an increase in test coverage as more and more areas of the system are brought into the test suite.
When using a suite of automated tests the user can choose to run the tests manually – as and when required – run the scripts to a set schedule, or link them into other automated deployment software to run the given tests when deployments are performed to a particular environment.

If the test suite is used throughout the whole project life cycle, then any test fails which arise can be highlighted automatically to the project team through the likes of email, instant messaging, and reporting.
Using the tests in this way allows the user – most likely the QA analyst, but potentially also a developer or another project team member – to step away from the automated tests and spend their time focusing on more business-critical areas or functions which return greater benefits to the company or client.

Instead of constantly checking that old developments still work as they should the project team can concentrate their efforts on delivering new features which add to the current process, and / or improve the customer’s experience.
In a previous blog post we explored different types of testing. Automated testing could be used in each of these instances – either to provide full-test coverage, or to perform a supporting function through the various stages. It should not be seen as a static tool that is only used by one person or role, or that only sits in one area or stage of a project.


Like developments of any kind, the main drawbacks when implementing automated testing will be time spent – both initially and on an ongoing basis – plus any costs incurred.
Although automated testing can be a time-saver over the long term, there needs to be an initial amount of time budgeted for writing and configuring the first tests. This period will be dependant on a number of factors, such as the experience of your QA team, the complexity of the user journeys, and the configuration of the environments to be tested.

Once your initial tests are running, an ongoing time consideration will be required to maintain the tests with each new deployment of code due to new steps in the journeys and / or failures, and to scale the tests across any new platforms.
With the tests all written and the platforms at a stable point, i.e. with no new code deployments in the short term, there will still be an ongoing amount of time required to monitor the scripts and react accordingly to any abnormal results.
Although the main budgetary impact from testing will be from allocation of staff, for creation and ongoing monitoring, there could also be other costs incurred dependant on what approach is taken.
Automated testing can be run from a developer's own machine, a local hosted server, a remotely-hosted server, or a specific third-party which offers an automated testing solution and hosting in one package.

Each of these approaches will incur different costs, but offer varying benefits and drawbacks. These should all be considered when planning the testing activity.


With your test tool decided upon, and your test scripts finalised, the next step would be to run the scripts as and when required.

One of the good things about automated testing is the level of control the user has over what and when to run. The scripts can be used to test against legacy code, or changed slightly to focus on new developments within a website. They can also be utilised to act as a high-level check on new code when deployed to test environments.
Due to the modular nature of test scripts they are reusable across the projects – on different test environments, for example – but also extensible and able to scale. They can be quickly adapted to any changes, and scale with the platform as it grows and develops.

Final observations

Automated testing requires investment in terms of time and money, but it pays for itself over the long term – multiple times.

With a clearly-defined set of test scripts, and properly planned process, the initial costs involved in automation testing – both in terms of time and budget – will easily be repaid many times over in efficiency savings and system stability.
At Inviqa, we utilise a number of automated testing methods throughout the whole project cycle to provide efficiency improvements across the whole team, and to deliver value to the end user or customer.

We can provide specific advice on the best approach and which tools to use to achieve your project objectives. Our focus is always on test coverage and quality whilst ensuring the chosen solution meets each customer’s business goals and budgets.

Learn more about the Inviqa approach, and get in touch to explore how we can support your digital journey.

Related reading