Let’s start! Why is automation UI-test evil?
Every company providing development services need testings but some of them use only graphical interface or UI tests. They seem very useful but extremely dangerous, in fact. UI tests sometimes provide good results and help to find bugs and mistakes. However, they aren't able to give enough information in the long run.
What is UI tests?
UI means User Interface, so during UI tests, engineers are checking how does application work with an average user. It seems very logical and natural to do them, also this approach to quality assurance doesn't request a lot of resources. Even more, some people think that only this way of testing is really needed.
But there are some unobvious nuances:
- UI tests aren't sustainable because they depend on layout. It means a team can add or remove something and change performance.
- UI tests require a lot of time because test versions of application usually work slow and spent resources in vain. Most of all companies can't waste their time, so this kind of testing is not suitable for them.
- UI tests sometimes cause crashes of apps when calling to unready features.
All of this is very important in automation tests because this kind of applications is very sensitive to mistakes.
How to make high-quality test automation?
The first thing you need to do in the general is to negotiate with the developers, so they don't forget to register every element as unique attributes on which the automation tool can be unambiguously identified. So, we should abandon the five-storied XPath expressions or CSS selectors, and, if possible, always use a unique id, name, etc. It should be clearly spelled out in the development of the guides and to be one of the points in the definition of done for developers.
The first and simplest way which can speed up the process is to deploy the app and run the tests on a "fast" hardware, to avoid situations when the interaction test and applications affect network latency, etc can make significant savings in time, up to two times or more. At the second time, you should test your framework design and check case the ability of independent and run in parallel. Parallelization of test runs allows very significantly reduce the execution time. The third and most radical is to create as little as possible of the UI tests. Less testing — we get the result of their run faster.
The testing pyramid
The pyramid is a very convenient metaphor it demonstrates the desired number of automated tests on each of the levels of the architecture system. The principle is very simple. First, the developer introduces new code changes. The tester is waiting for building and deploying a new build to the test stand. The tester conducts the test, finds the problem and gets a ticket in the bug-tracking system. The developer instantly responds to this ticket and fixes the problem. This is the new code changes and then build, deploy, and retest. If everything is OK — the ticket is closed. The time from identifying the problem until it fixes to range from several hours to several days or even weeks.
Another story, when there are automated tests that use the API for communication with back-end applications.
There you can find some “tasty” options:
1) Tests are run only at the deployed app with all external systems. In comparison to clean UI tests is greatly reduced runtime and analyze the results, as there is much less of false positives.
2) Here the gain in speed between detection and correction of problems is huge.
3) Unit - and component auto-tests do not require assembly of the entire project, start immediately after compilation of the module without leaving your favorite IDE, the response is instantaneous. The time of making changes to fixing possible problems is counting in minutes. It is obvious that if we will move down the pyramid, the faster will run the appropriate auto-tests.
The main recommendation: you should have all types of auto-tests in the right amount at the every stage. Then there is the opportunity to obtain effective output from these tests.