We all know that testing is essential for making sure that you are developing high-quality products, and we also know that automating some of those tests can save you time and money. But when you start automating your tests, how do you choose what tools to use? You might pick tool X because someone on your team has used it before. Perhaps after doing some research to find the most commonly used tool, you might pick tool Y, because that many people cannot be wrong, can they?
Once you have chosen a tool, the automation can begin. Over time, however, you might notice that the test coverage starts to decline because the testers are spending more and more time just keeping the existing tests running, leaving less time to automate new tests.
When tools are chosen without having a carefully designed test strategy, the result is a large amount of effort expended for no gain. Creating a suitable test strategy is a very important first step.
There are several factors that go into a good test strategy, including understanding the big picture which is an architectural role. You’ll also want to work through the testing quadrants (any of the various incarnations) which will provide a more structured and focussed way to consider what types of tests will be needed and which of those will be automated or manual. Referring to the test automation pyramid adds further understanding in terms of how much testing should be done at each level, and this brings us to the architecture.
Not understanding or ignoring the architecture means that all automated testing is probably done through the front end (a UI or an API). This type of testing is very slow and results in tests that are very fragile. A few minutes of work by a developer can cause many of those tests to break, leaving you spending all your time fixing them rather than testing new functionality.
We still need to test the front end, but we should not be testing the business logic through the front end. There should be a small number of tests that validate the front end and only the front end, but the bulk of our automated testing should focus on the business logic without going through the front end. This strategy results in automated tests that are much faster and require minimal ongoing maintenance effort.
To achieve this, the architecture/design must keep the front end and the business logic separate at every level of detail, and here is where the worlds of tester and architect/designer collide. If you do not understand the architecture, how can you know what can be tested and in what way? And how can you be sure this is possible without being involved in the architecture and design?
Testers may not be architects, but to succeed at test automation you need to understand the architecture and work with the architects/designers/developers. Should you choose to go down this path, some good topics to start exploring are:
Posted by Colin Garlick.
Your details have been submitted and we will be in touch.