Four out of five QA applicants want to learn how to work with automated tests. Not all companies can fulfill such desires of manual testers during working hours. Wrike held an automation school for employees and realized this desire for many. I participated in this school as a QA student.
I learned how to work with Selenium and now I support a certain number of autotests on my own with little or no outside help. And, based on the results of our joint experience and my personal conclusions, I will try to derive the very formula of the most ideal school of automation.
Wrike Experience in School Organization
When the need for an automation school became clear, its organization fell to Stas Davydov, the technical leader of automation. Who better than him can explain why they came up with this initiative, did they achieve results and do they regret the time spent? Let's give him a word:
- In 2016, we wrote a new framework for autotests and made it so that it became easy to write tests: normal steps appeared, the structure became much more understandable. We had an idea: we need to involve everyone who wishes to write new tests, and to make it easier to understand, we created a series of lectures. We collectively came up with a plan of topics, each of the future lecturers took one for himself and prepared a report on it.
What were the difficulties for the students?
- Basically, of course, architecture. There were many questions about the structure of our tests. There was a lot of feedback on this topic and we had to do additional lectures to explain it in more detail.
Did the school pay off?
— Yes, definitely. Thanks to her, a bunch of people were attracted to writing tests, and, on average in the hospital, everyone began to better understand what autotests are, how they are written and how they are launched. The load on automators has also decreased: we now receive many times fewer requests for help with parsing tests, since testers and developers have begun to cope with this themselves in almost all situations. Well, a few internal advantages for the department: we gained experience in presentations and lectures, thanks to which some automators have already managed to make presentations at conferences, and also received a powerful set of videos and presentations for onboarding beginners.
From myself, I would add that communication between our departments has been simplified to a downright ridiculously easy level. For example, now I practically do not need to think about which cases and with what level of atomicity to give for automation. As a result, concern for the test coverage, which is constantly growing, is being fully taken care of by all interested parties. Nobody demands the impossible from others.
In general, the impact on the work of teams is definitely positive. Perhaps colleagues reading this article are also thinking about doing something similar? Then the advice will be simple: it's worth it if autotests are a priority for you. Next, let's talk about a more difficult question: how to organize everything as correctly as possible, so that the costs of all parties are minimal, and the output is maximum.
Organizing Tips
The school was useful, but, as Stas admitted, there were some difficulties, because of which additional lectures had to be arranged. And it was as a trained recent student comparing himself-in-the-ignorance and himself-now that I formulated the following steps to create what I believe is the ideal way to teach testers how to deal with automated tests.
Step 0: Create a Dictionary
Of course, this step is needed not only for QA. However, I want to make it explicit: the automation codebase must be kept in a readable form. Programming languages - not least languages, and from this it will be possible to begin the dive.
Here is a screenshot of the taskview with the names of the elements. Let's imagine that you are testing a taskview as a black box and have never seen Selenium in your life. What does this code do?
(Spoiler - the task is deleted through the rest on behalf of the admin, and then we see that there is a record about this in the stream.)
This step alone brings the QAA and QA languages closer together. It is easier for automators to explain the results of the run, manual testers have to spend less effort on compiling cases: they can be made less detailed. Yet they understand each other. We received a win even before the actual training began.
Step 1. Repeat phrases
Let's continue the parallel with language. When we learn to speak in childhood, we do not go from etymology and semantics. We repeat “mom”, “buy a toy”, but we don’t immediately go into the Proto-Indo-European roots of these words. So it is here: it makes no sense to dive into the very depths of the technical features of the work of autotests without trying to write something working.
Sounds a bit counter-intuitive, but it works.
At the first lesson, it is worth giving a basis on how to write autotests directly. We help set up the development environment (in my case, Intellij IDEA), explain the minimum rules of the language that are necessary to write one more method in an existing class using the existing steps. We write one or two tests with them and give homework, which I would arrange as follows: a branch taken away from the master, but several tests have been deleted in it. Only their descriptions remain. We ask testers to restore these tests (not through show diff, of course).
As a result, the one who listened and did everything will be able to:
- learn how to work with the development environment interface: creating branches, hotkeys, commits and pushes;
- learn the basics of the structure of the language and classes: where to insert injections and where to imports, why annotations are needed and what symbols are generally found there, except for steps;
- understand the difference between action, waiting and checking, where to use what;
- notice the difference between autotests and manual checks: in autotests, you can pull one or another handler instead of performing actions through the interface. For example, send a comment directly to the backend instead of opening a taskview, selecting an input, typing, and pressing the Send button;
- formulate questions to be answered in the next step.
The last point is very important. These answers can easily be given ahead of time, but this is an important teaching principle: answers without formulated questions are not remembered and are not applied when they are finally needed.
It would be ideal if at this time an automator from the QA team assigns him the task of writing a couple of tests on the battlefield and allows him to recommit to his branch.
What not to give:
- more in-depth knowledge of the functionality of the development environment and the programming language itself, which will be needed only when working with branches on your own. It will not be remembered, you will have to explain it twice or thrice, but we value the time of automators, right? Examples: resolving conflicts, adding files to git, creating classes from scratch, working with dependencies;
- everything related to xpath. Seriously. It should be told about him separately, once and very concentrated.
Step 2. Looking at the grammar
Let's remember the taskview screenshot from step #0. We have a step called checkCommentWithTextExists. Our tester already understands what this step does and we can look inside the step and decompose it a bit.
And inside we have the following:
onCommentBlock(userName).comment(expectedText).should(displayed());Where onCommentBlock is
onCommonStreamPanel().commentBlock(userName);Now we are learning to say not “buy a toy”, but “buy a toy from the Children's World store, standing in a blue cabinet on the third shelf from the top.” We need to explain that we point to the element sequentially, from larger elements (stream -> block with comments from a certain person -> that part of this block where the given text sits).
No, it's still not the time to talk about xpath. Just to mention briefly that all these indications are described by them and inheritance goes through them. But you need to talk about all these matchers and waters, they relate specifically to this step and are necessary to understand what is happening. But do not overload: your student will be able to study more complex assertions later. Should, waitUntil, displayed();, exist();, not(); should probably suffice.
The homework is obvious: a branch that has removed the contents of several steps that are necessary for a certain number of tests. Have the testers restore them and make the run green again.
Additionally, if the tester team has not only new features in the works, but also some bug fixes, you can ask him to write tests for these bugs immediately and release them. Most likely, all the elements have already been described, only a couple of steps may be missing. This will be the perfect workout.
Step 3. Full immersion
As complete as possible for a tester who is going to continue to perform their direct duties. Finally, we need to talk about xpath.
First, let's make it clear that all these onCommentBlock and comment are described by them.
Total:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"The order of the story is very important. First we take any existing xpath and show how there is one and only one element in the elements tab. Next, we talk about the structure: when you need to use WebElement, and when you need to create a separate file for a new element. This will give you a better understanding of inheritance.
It must be explicitly stated that a single element is the whole taskview, it contains a child element - the entire stream that contains a child element - a separate comment, etc. Child elements are inside parent elements both on the page and in the structure of the autotest framework.
At this point, the audience should already have a solid understanding of how they are inherited and what can be entered after the onCommentBlock dot. At this point, we explain all the operators: /, //, ., [] and so on. We add knowledge about the use of @class and other necessary things.
Listeners should understand how to translate xpath in this way. To fix - right, homework. We delete the descriptions of the elements, let them restore the work of the tests.
Why exactly this way?
We should not overload a person with complex knowledge, but we should explain everything at once, and this is not an easy dilemma. This way will allow us to first make the listeners ask questions and not understand something and answer them in the next moment. If we talk about the whole architecture, then by the time we analyze the topic of steps or xpath, the most important parts of it will already be forgotten because of their incomprehensibility.
However, some of you will surely be able to share your experience on how you can optimize the process even more. I'd love to read suggestions like this!
Source: habr.com