We always have great expectations of automation, but sometimes they are not met while the investments do not bring profit. Not to lay an egg, let’s try to understand why it happens and how to prevent the most common mistakes.
Do You Need Automation?
- The project lasts for a year or more, and you need to run more and more tests.
- You have more than two developers, and they must be confident that the changes they make won’t break someone else’s code. Without auto-tests, they will know about this in a day or two at best.
- You support several versions of the product and from time to time release patches/service packs for each of them.
- You develop service with the main task of treatment and transformation of various data. (Entering the data into the system, visual analysis of the results, sending requests and analysis of the replies – these are the tasks for the machine, not for real people in XXI century).
If your project doesn’t fit any of these features, then you probably don’t need to worry so much about automation.
Why Do You Need Automation?
As you understand from the above, any automation saves people from routine work, and automation testing is no exception.
However, there is also a misconception that auto-tests should completely replace the manual labor of a tester, and scripts must test the product. Up to the date, there’s no script that can replace a living person; it just replicates human actions and signals if something goes wrong. This feature is used to get information about any change in the quality of the tested product faster than any living tester can provide.
There are also some other requirements that make automation effective:
- The completeness of test coverage.
- Clarity and reliability of the results.
- Lower costs of development and support.
- Ease of launch and analysis of the results.
Common Fails, or Why Expectations Are Not Always Met
There are many reasons due to which automation may not live up to expectations. And all of them are somehow connected with wrong decisions in engineering or management fields, and sometimes in both simultaneously.
The most harmful management mistakes are:
- The desire to save money on hiring experts in the field of automation (the belief that it is cheaper to hire students who will click the regression manually will likely lead your project to bankruptcy).
- An attempt to implement automation without a thought-out strategy and planning.
- Too late start, when the testers are already burnt out.
Under engineering mistakes, I consider the decisions that engineers take in the development and implementation of automation strategy (for example, choice of tools, testing frameworks, etc.).
Why the Automation of UI-Tests ONLY Always Fails
The most common mistake is the decision to implement automation solely through the GUI.
However, this does not seem bad at the time of its adoption. Sometimes it even solves some problems for quite a while; moreover, it can be sufficient if the product is already at the stage of support (and no more developing). But in the longer term, that’s not the best solution for the developing projects.
UI tests are the natural way to test applications, the simulation of how users will interact with them. It may seem the perfect and the only true option, but the two big drawbacks are that UI-tests are unstable (they depend on the layout of the interface) and slow (the app interface is slow and requires redrawing, loading resources, entering some data, etc.).
So what to do?
- Stabilize. The first thing you need in the general case is to negotiate with the developers so that they don’t forget to register the unique attributes for elements on which these elements can be unambiguously identified by the automation tool later.
- Accelerate. The problem of slow tests needs to be addressed holistically, as it affects the development process in general.
- The first and the most simple trick that can speed up the process is deploying and running the app on faster This alone can provide significant savings in time, up to two times or even more.
- The second thing to do is to initially put the possibility of an independent and parallel run in the test framework and the design. The parallelization of test runs will allow you to significantly reduce the execution time.
- However, there are some limits, too. First, not always the logic of the application allows you to test it in multiple threads. Such situations are quite specific and rare, but they do happen. Second, everything depends on the hardware, and you can’t parallelize infinitely.
Not all projects need full automation. In some cases, helper scripts are enough to make life easier for testers. But when dealing with a project that is developing and will develop for a long time, involves many people and has a complete testing department, you just can’t ignore automation. The best basis of successful automation is taking well-thought decisions at each level of the system architecture.
Bio:
Lucy Adams is an outsourcer from bestessay4u. She’s interested in business, marketing, hi-tech, etc. Simply put, Lucy is a generalist able to cover any interesting idea. As a rule, Lucy responds in 24 hours so that you can expect a fast and grounded reply to your each and every request. Share with the blogger your intriguing ideas and get a few high-quality articles in return!
