When and when not to automate tests in software development

Everyone (hopefully) knows that testing is very important to provide appropriate quality of software development. Testing can be performed by multiple people throughout the process, even at the concept stage. The more testing is done the better level of certainty is achieved.

Why would you automate testing

Let’s start from the beginning. Software testing is process that should ensure good quality of the software. Core responsibility of tester is to not to let bugged or incomplete application be deployed to clients. They should understand all the requirements and make sure that end product matches the project. The best way to achieve this goal is to maintain well-structured test plan and work close with developers, learning and logging all the nuances using common tools in the project i.e. participating in meetings, working within Kanban board.

The basic tool

Whilst you cannot automate human interactions, a test plan is a perfect fit for our task. A test plan is a document that grows with every iteration, consisting of test cases that explain how to test a given part of a feature. In a perfect world such a test plan would cover every part of the software as it grows and most importantly, all tests should be performed at the end of each iteration as part of regression testing. Regression is a type of error that occurs when a change in a supposedly non related part of an application breaks something that no change was introduced in. That is why there is a need of performing all tests before each release.

Upgrading the tool

With test suites growing, doing manual regression testing can be grave boring, and here comes automation! With having tests automated everyone wins. Tester is relieved from doing the same task, therefore there is more time to do creative work, computer does not know the concept of boredom, therefore human error is mitigated. Automation speed is rocket-like comparing to manual clicking so much more runs can be run within the same period of time. Worth mentioning – fortunately or not, in today’s world drafts often change multiple times thanks to agile methodologies, so that not everything can be automated or regular changes are mandatory.

Shortscreen of aoftware test automation
Transfer your testcases to code

Reasons not to automate testing

Automation should be introduced always when possible. There are just few reasons that may disqualify automating tests. The easiest reason is when there is no particular reason to do this at all, for instance, project is very atomic or created for one use only. It is often that there are not enough “human resources” in the team and the tester is occupied with manual testing of new features. If project is growing rapidly, hiring automation specialist is good option as such person can start automating simple things right away so there is no need for long introductions, also they will be getting more expertise with time.

The problem with visuals

A less obvious reason might be the need for visual confirmation. Currently, computers are not prepared for recognizing variable images. Of course there is artificial intelligence that may come up to this challenge but it requires high computing power and very sophisticated software, that even professional automation tester most probably will not be able to create (if they would they would rather be developer already, very good one). Not to search too far, just think about captcha images and their power against any kind of automation.

Ultimate reason

You should not automate tests that you do not expect full predictability. Keep in mind that one input should result in one and always the same result. For last but not least, automation should aim for 100% coverage of tests. If this goal seems to be impossible to achieve automation is advised when tests that can be prepared are saving a large amount of time.

How to Automate tests

This question cannot be simply answered. There are numerous ways to automate testing, and there are lots of different things to automate. The question to answer is to which tool will be used. In Onex Group, we use Cypress written using TypeScript, a real combine for testing. Do not hesitate to check out other articles about Cypress in TypeScript!

Coming soon