How to automate software testing

November 14, 2016

Chief Technology Officer

At a certain stage of development, each team is coming to the stage where the members have already got used to each other, they make good products, and everything they do is great, but they must move on. And here comes the time of lean production. The team begins to improve existing processes to reduce or even get rid of the loss of time, resources, etc.

And this is where the problems arise in the automation of processes to save the time of highly qualified teams of QA and DEV on more complex tasks requiring direct human intervention. This is a separate big topic, but today we want to talk only about the small piece - Test Automation.

Why do we usually start automation of testing process?

manual test execution takes too long;

a human can make a mistake during the manual checkup;

automation frees up time for the team to solve complex problems;

automated regression checkups are the first to recognize the potential errors in the software;

auto-tests provide information about the status of software quicker;

they are a great kind of documentation;

they allow us to write code once at a right level (TDD).

What are the drawbacks of automate software testing?

I would like to give a list of issues formulated by Lisa Crispin in the book "Agile Testing: A Practical Guide for QA experts and Agile Teams." Here they are:

programmers' attitude, many of them do not understand why you need auto-tests if there are manual testers, and especially if they do not want to help to make these tests, because "we're overloaded, and your testing is just fine";

a very extended period when you need to do too much for automation makes many people give up;

initial contribution takes time and efforts. It's necessary to undertake a long analysis, develop a strategy, and other things, but it's a hard job when new tasks appear that are ASAPer than other;

tests have to be maintained and re-written, "It is clear, but why the development team is always changing the application UI?" any QA expert could ask and start testing as before;

legacy code is one of the worst curses of the development team, it often happens that no one is working to improve the code, run tests, etc.

How to automate software testing?

When the question "To automate or not to automate?" is solved, it's a right time to start.

Let's take a look at the agile testing quadrants: Here we see functional tests in square 2 and "Ility" Testing in square 4 that are relevant to automation checkup. This will be counter-productive if developers are not involved in unit and integration testing. All this leads us to the following chart, which shows the dependence of the tests from each other, and their relative volume:

Implementation of checkups at the Acceptance tests level is divided between developers and testers while the QA experts take the so-called "pre-GUI testing." As you can see from the chart, manual tests still remain, but there are not many of them. When we speak of manual assessing in an agile, we mean exploratory testing.

The process of test automation integration consists of:

implementation is not possible in the absence of the process itself. Those who will be engaged in autotests have to understand the principles and approaches to assessing, and this is a big enough reservoir of knowledge that a few developers have;

when implementing an automated testing, you should take into account the costs and benefits. It is worth remembering to include the time range of employees' training and records management of the auto tests processes;

choose the right tool for the automation;

find out what needs to be fully automated, what requires only partial automation, and what is not worth automating. You should not aim at moving to autotests completely because it's not good for any product;

determine the rules and guidelines, as we approach automation because it also includes coding, so here it is necessary to comply with established engineering practices.

How to choose the right tools for automation testing?

The market offers a huge number of instruments that can solve both highly specialized tasks and to act as a "food processor" that's able to solve all sorts of problems. So, here are ground rules for selecting the right instrument:

it lets you to start writing tests immediately, the barrier to entry should be minimal;

it lets you separate test logic from the implementation. In this case, we will be able to change the tool and the implementation, but the tests will remain intact;

it allows and encourages you to use well-known development practices;

* it lets the use of the existing programming languages and IDE, no need to reinvent the wheel, in the development of languages, many things (for example, work with the database) were implemented long time ago;

it has an active community.

But regardless of the tool you need to adhere to some principles:

keep It Simple ("KISS"). It is not necessary to write complex code structures for "just in case of...", you should fix current bugs;

tests should be run more frequently to get more results. Otherwise, it will be like with the dumbbells that you've bought, and now you keep them somewhere at home;

the whole team should be involved to give you the best results;

doing the right things takes time, so do not give up as soon as there are any problems. You can ask your colleagues to support you;

more practice, less theory. It is easier to run a test to check that everything is OK than non-stop surfing the net.

The bottom line

Now you have the strategy to start your first automation software testing. Even if you do it with an outsourced QA team. Understanding the basic principles of how everything should work will help you to organize and control the process from start to finish. It won't take much time, but it will save your project from bugs.