Bad tips: how to turn the automation of UI tests into a nightmare

Hello! My name is Artem, and I do test automation. Anti-patterns in development are quite a popular topic. But after all, testing also has its own "bad advice", and they are quite funny intersect with the development. Recently I came across an ironic article about anti-patterns in testing. Your attention!

We try to prove as soon as possible that we are wrong, because only in this way can we develop.
Richard Feynman

There are many ways to make life more difficult for test automation teams. If you are a developer or system architect, and do not like one of the testers, then this article is for you. You will find in it a secret knowledge, inspired by which, you will learn to make the interface of any application practically unsuitable for testing.

Well, if you are a kind soul and respectful of other people's work, you can consider this article as a set of antipatterns.

So let's go.

Collection of curses

Identification

Your very first task is to make the identification of interface elements too difficult or completely impossible.

Rule of thumb: no id.

Never assign any ID to the interface elements. With their help, automated testing tools are the easiest to find items. In addition, even when changing the interface layout, IDs are saved and allow you to find items. But without ID testing is sure to fail.

Dynamic id

If you can't get rid of IDs, then at least make them dynamic. Generate a new value each time the view is displayed to the user. And then all tests that use fixed ID values ​​will be automatically broken immediately after recording.

Dynamic application title

It is a great idea to add time to the main title of the application window. For example:

Platinum CRM - ACME - December 19, 02:46:23 pm

This technique can complicate not only the definition of interface elements, but also the process of recording a test. Imagine that the objects inside the automated testing tool are grouped by the window title — then each object will turn into a separate group.

lead time

When updating data, the duration of opening a dialog or page load may be unpredictable. This will force automation engineers to use many sync expressions in tests.

Wait! There are other ways to make the runtime completely random.

Ineffective data processing implementation

It is very simple. When implementing software, do not think about the amount of data, check the code with the help of small databases and in a single environment. I guarantee that under real load your program will respond slowly.

Hostile deployment

Deploy the server part of your solution in a virtual machine hosted on a server with a bunch of other VMs. There is a high probability that these neighboring VMs will take away CPU / memory / disk resources when you need them most.

Supporting APIs

Never implement access interfaces like UI Automation and ARIA in your application, otherwise testers will have an effective way to automate interaction with the application. You just do not have the right to give them such power.

Update interface layout frequently

Change the layout every week. Together with the above tips, it just kills testers. They may even start fantasizing about manual testing, because in this case they will not see the results of their work lying in ruins.

Don't give them a chance

Application status

Your application should not show its current state and what it does. Do not disclose anything that can be used to understand what is happening or to check the correctness of the application behavior. No status bars, no navigation chains. Let's not be able to understand that the application is now busy with something.

Keyboard navigation

The application should not support alternative navigation or interaction, such as keyboard shortcuts. Want to navigate the menu? Mouse and mouse only. Want to move to another cell? Only the mouse, the arrows on the keyboard should not work. In short, you understand the essence.

Logs

Do not write any logs. They can give information about the problems and contain tips to correct them.

Buttons with icons

Use buttons with icons and under no circumstances make signatures or text prompts for the buttons. Combined with the lack of an ID, this will make identification almost impossible or very unreliable.

Finally

Remember! To turn the interface testing into a nightmare, you need to follow the basic principles:

• Make unreliable identification of objects.
• Unpredictable application behavior.
• Modify the interface so that it breaks down the tests and turns them into garbage.
• The application must be a black box for automated testing tools.
• Effectively stop any attempts to bypass, such as keyboard shortcuts or log analysis.

Finally, if testers are asked to do something contrary to these tips, just ignore.

Good luck!