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:
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:
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:
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.