A few words about automation

Last updated: June 26, 2017

Intro
Environment
Technology stack
UI tests

Intro:

For some time, I hear a lot about automation. And more and more often hear the statement: we should automate everything. In my opinion, you can automate a lot, but not everything. However, so far, the human factor is needed. Maybe in the near future, there will be advanced artificial intelligence that will allow people to take more creative tasks at work than they are today. And here comes the question of what is a more creative task?

Automation can be talked about in two ways. Automate tasks through bots or appropriate scripts that allow you to perform the right tasks automatically. The second approach is to run automated tests, which is related to the first point because it involves eliminating human interference in the process.

Automation, like every field, can bring a lot of good, save time and money, but it can also put a lot of time and money into it, and you don’t get any meaningful benefits. Let’s be honest automation is not cheap. However, in an appropriate way, it will make testing more effective.

Environment:

Many times I encountered a situation where when moving to a new environment, existing automated tests did not work or could not be started. This was due to two reasons. Firstly, a code has not been maintained for a long time, I mean half a year or often even a year. No one is able to say anything about the code after this period of time. And second, test code was written in a very chaotic way, without using any pattern to create automated tests. What does this really mean? Often it means that nobody has no idea how tests work and why they give such and not other results. A lot of time and energy are needed to maintain automated tests created without the use of a design pattern. It usually involves rewriting the entire architecture of test again. A very bad option is also to recording test and playing them once in some period of time. In my opinion, this is not a solution. Right until the next run of this type of recorded test scripts will be useless.

Technology stack:

Several times I also met with the situation when the automation technology stack was different from the technological development stack. Such a solution required preparation of additional infrastructure, which involved costs, an additional environment for maintenance. This also causes trouble for the developer, especially when the product code is created iteratively. At this point, it is also worth mentioning CI – continuous integration. This is one of the basics of automation. This allows, above all, a quick feedback on the fact that a particular feature does not work. Sooner we find out that something is not working we’ll fix the problem faster. Otherwise, it may just not be enough time for a “quick fix”. It also saves us a lot of nerves on release day when everyone is praying that all tests will turn green. But the reports sometimes say something different than it actually is. Keep in mind that the automation product is the report, and each of them should be as well reviewed. It’s important to provide one source of information about the reports. I mean here that people tend to check one source and the others are omitted. Besides, I also met with the coincidence that we have a problem only when the tests fail, and only then we take care of the repair. This is not quite true, tests may pass and functionality still does not work and no one knows why. In that case, tests are badly written and they need to be thoroughly reviewed.

UI tests:

If automation test engineers only write UI tests, we should consider very well whether we do automation well. It also depends on the type of product we have to deal with, but there are some problems with it. First of all UI tests are most expensive to build and maintain. UI testing is never as testing the service layer and database layer. Automation can be made much more interesting and effective, so as not to lose the essence of automation. It may be better to write scripts, tooling, even a bot to inform you about the progress of the various activities that will save a few hours during each deployment and it make it less painful.

Ok, but test automation is suitable for checking repetitive tasks, then it is most useful. If we want to check feel, look and a good tests of the new feature then the best idea is to customer or people who have not previously had nothing to do with it. Then we get a fresh feedback.

If all tests pass 100% we probably do not test as much as we should. Properly matching boundary conditions in such a way that some of them pass and some certainly should not give us the result of 100% is on the pass.

A few additional words about automation. Automation testing is irreplaceable, but you have to be careful to do it with reason. The customer does not pay for the tests, but for the product, good quality and timely delivery at a reasonable price.

Reference:

My site is free of ads and trackers. Was this post helpful to you? Why not