"It was believed that the code will replace the UML-diagrams, and it will not be necessary to test": an interview with Alexey Barantsev
Alexey Barantsev is probably one of the most famous people in Russian testing: he is known both from software-testing.ru , and from selenium2.ru , and from participation in Selenium WebDriver, and not only. At the same time, he is also one of the most experienced: he has been in testing since 1994. And when it became known that he would speak at our conference Heisenbug with the report “Zamorochki in Selenium WebDriver”, we wanted to ask such a speaker. We started with questions about how testing in the 90s differed from today's, and then turned to modern realities.
- Among the readers of the interview may be people who have not even been born when you have already started testing. Tell us, how did everything differ from our days?
- If we talk about some fundamentals of testing (theory, key techniques), then there are no special changes. But while testing automation, of course, is constantly changing. New development technologies appear and disappear, and together with them, technologies and tools designed for software testing arise or disappear. How can we compare the testing of what was then and what is now? Anyway, what to compare, what is better - before was SOAP, now REST. Then we tested web services written using SOAP, and now those that are written using REST. What's the difference?
- Well, some technologies didn’t just “appear and disappear”, but became so, without which it is now difficult to imagine the industry: “How did we even live without Git?”
- We lived normally without Git. There was CVS, we lived beautifully with it, then there was Subversion, then Git. All this is not so interesting, but what has really changed very much is speed. The speed of development, and with it the speed of testing. It's not even about short iterations, Agile, the approach to the organization of working time. Changed exactly the speed of product development.
When we first started working, in the mid-90s, we had projects for a period of six months, a year, two years. Development and testing. Then these projects began to decline to three months, two. In fact, in two months the same thing was developed that earlier in a year. And now what is happening: people come to the hakaton, in a day they develop a working product, test it and launch it. It is clear that this is still a prototype, but nevertheless, in a day. It was impossible to think for yourself.
Why it happens? Of course, tools are evolving. But it’s not even a matter of tools; some people still write code in vi or emacs. More importantly, a lot of ready-made code has already been written, there are good libraries that have been thoroughly tested. Somewhere you still need to write a lot of your code, develop unique algorithms, and everything is still there for a long time. But in other situations, you can take ready-made components, quickly from them, as from the designer, to collect the finished product. And, accordingly, it is also easier to test it, because we are already assembling from reliable, proven components. This has changed a lot.
- And what has changed in people's worldviews - how do we look at testing / development and what do we expect from them?
- In the 90s, both developers and testers had more faith in standards. Actually, Agile did not arise from scratch, but precisely because of the disappointments in all these standards.
First, there was a thought that standards will save us from poor-quality code: we will write everything in accordance with standards, and everything will be well integrated, work. Maybe it is even true, the standards are simply developed very slowly, and everything very quickly runs ahead and becomes obsolete before standards are adopted.
Secondly, there was confidence that it would be possible to formally draw diagrams using UML diagrams, describe the software requirements and automatically generate the source code, and all this would work, and there would be no need to test. It was supposed that the developers would soon stop writing code, instead they would draw UML diagrams and describe the conditions in some high-level language. Did not take off, did not work. Although in the party where I rotated, very large bets were made on it.
Now, probably, some new wave has started: artificial intelligence is sprouting from all places everywhere, and again this idea arises that soon developers will not write code. Instead, they will train some systems of artificial intelligence, and everything will work by itself. Accordingly, testers will not have to do anything. Developers will teach artificial intelligence, and he will do everything. Let's see how it will be. Maybe it will turn out like last time.
- We turn to our time. You are engaged in a site software-testing.ru. For those who are not actively following him: what is happening there?
- We publish a lot of content, now the main part is translated content. Because, frankly, in Russia it is very difficult to find authors writing about testing. I don’t know why it happened: there was a certain moment when many people wrote in Russian, and then either they ran out of fuel or else for some reason there were few blogs and articles in runet. And in the English-language part of the Internet, all this still blooms, there are written a lot of articles.
Communication has gradually moved to chat rooms, that is, people do not write texts, but communicate. This is not to say that we are following this trend very carefully. We participate in chat rooms, but we are not trying to lead this current. We are still acting in the old manner, trying to give people exactly the content, and they will find a place for communication.
- From the texts, people now also go to video blogging - is there something in testing?
- In testing this trend is almost imperceptible. There are literally one or two videoblogger, isolated cases.
- There is an expression "Do you want to understand something for real - try to explain it to others." And when you systematically edit other people's texts, do you start to better understand the topic, including corners, where you yourself wouldn’t have looked? Is it helpful for a tester to be an editor too?
- Editorial work is quite different from reading. The task of the editor is not to understand what is written in the text, but rather not to miss the flaws. Honestly, it does not contribute to a holistic view. When we choose a material, I look at it as a reader more: it is interesting to read it or not. At this moment I am not yet an editor. But when we look at the translated text and prepare for publication, then in this case as an editor. So that during editing, during preparation for publication, I understand something - this does not happen. So different modes: one mode - the editor, the other - the reader.
- Immodest question. On software-testing.ru there is banner advertising, but in ordinary journalism it is difficult to monetize with its help - is it better in the case of testing, or do you also not compensate for the labor costs and the site exists for the love of art?
- No advertising revenue does not compensate for the work on the site. It exists in order to create an image, an image, to maintain our presence in the network. And we earn a training center.
- The next question is about training. You have been training others for many years in testing, and how does this affect how you look at testing yourself?
- The principle that you mentioned a bit earlier works here: as long as you explain something to someone, you understand something yourself. It really helps to better understand, understand. When you first talk about a topic, it seems that everything is clear. And then you watch your lectures, you understand that you can better tell, rework, some new things appear. After that, I sometimes write some additional articles: first you prepare the material for the course, and then you realize that you need to add something else to make it clearer. And, of course, it is even more interesting to receive some feedback. People also tell something interesting. You are asked some sudden question, and only then you realize that you do not understand. And I never thought that I should think about it. This is valuable.
- When you teach many people, you begin to notice some typical mistakes for many people. Can you formulate some common “typical tester error”?
- A typical mistake in general of any person is that most people in IT are trying to learn everything from their own experience, to go through all the rakes. From my point of view, it is more logical to move in another way: to study something, and only then proceed to perform the work.
In this regard, I am an atypical person. When I buy some household appliances, the first thing I sit down and read the instructions. Therefore, it is quite difficult for me to transfer my own psychological experience to other people. I understand that yes, most people do not act like that, first they walk around the rake, and then they begin to figure out how to avoid it. I think it’s wrong, and they think it’s right.
- Now I want to ask about Selenium. How do you get into the community of developers of Selenium Driver and the whole ecosystem around it? Are there any steps and levels? For example, "make ten pull-rekvestov and go to the next step."
- There is no standard procedure, no regulations, no specific selection criteria. Everything is completely individual. When it is clear that a person is already involved, then he is gradually given more rights. This process of entry occurs in all different ways. Someone starts to correct bugs and sends pull requests. And someone starts responding to users in the mailing list: we have a person in charge of working with users who do not have a single commit in the code at all, but he actually keeps a mailing list on himself. Someone writes documentation -
this is a task that also involves working with source code, but, of course, most people perceive participation in the project with pull requests.
With pull requests, there is an organizational problem related to the fact that we do not have enough hands, so pull requests can lie for a very long time, and no one considers them. Therefore, you need to be persistent to get noticed. It is necessary not just to send a pull-request, you need to punch it. Those who break through this filter can then gradually enter the project.
- And who should I write to get through?
- Yes, write to everyone. In the IRC chat ask for a rating pull request. In general, there are non-technical filters through which a person gradually penetrates. And if you made a pull request and wait until you are invited to the project, then no, they will not.
- Intuitively, I would like to assume that if a tool that is very popular among testers is being developed, then it itself has been tested much more thoroughly than the average IT project. An example of Selenium confirms this or not?
- I do not know about the "average project", but Selenium is really tested quite carefully. There are a lot of tests, tests constantly work, constantly find bugs, including regression bugs, including regression bugs in browsers. I regularly write bug reports to browser developers.
It seems to me that the test situation is fairly good, although I cannot say that tests are written completely systematically everywhere: after all, they, too, have grown organically over these twenty years. If you start writing them from scratch, take the specification and design it carefully, then probably it would be better to write many tests differently. But so far there was no thought to sit down and rewrite completely some part of the tests, organically grown tests cope with their task.
- Often there are disputes "which browser is better," and since you send them bug reports, it is interesting to compare with the non-standard side: which browsers have a team that responds better to bug reports, and which ones are worse?
- I would not want to offend anyone, so I will not criticize anyone, but I can not praise. The Firefox developers respond best. They are the most involved, the most active in terms of working with bug reports. That, perhaps, just corresponds to their open-source spirit.
And the most annoying is not the response of teams to bug reports. This is what companies that develop closed-source browsers (Microsoft, Apple) have a closed bug tracker. That is, when meeting a bug, you cannot see if someone has already sent such a bug report, is it a known bug.
- A few years ago you said that the task of Selenium is to become a web standard. He became, and then what? What is the next big milestone?
- Grab the world in the face of automation tools. That is, you need to ensure that all this new standard is supported.
- That is, to become a built-in module for all other new UI automation tools?
- Yes. That is, they can use another ten other modules, but they should all be able to work through a standard protocol.
Inside Selenium there is the next important task, which will be solved first by some prototype implementations, and then within the framework of the standard. The HTTP protocol is essentially one-way, that is, one side sends requests, the other handles them, and there is almost no feedback. And this is not very good, and here the competitors are very actively pointing to this, putting pressure on this sore spot, because I would like, roughly speaking, to have callbacks. When some events occur in the browser, I would like to receive some alerts about this. This is not in the Selenium tool. But we really want to add it. So, probably, cardinal changes will take place, change of the protocol is possible. Without this, it will be difficult. Need a two-way protocol.
- You and Simon Stewart are key contributors to Selenium, right?
- This is so, if we talk about the Java part.
- As far as I know, you have never met. How did that happen? Do Selenium developers have any corporate events?
- “Corporative” we have in the form of meetings at conferences, but separately - not. And in the case of conferences, Simon even came to Moscow for last year’s Heisenbug, but I wasn’t in Moscow at that moment, so they didn’t cross.
But, to be honest, we now live in such a world that nothing terrible, we still constantly communicate.
- The general question at last. What do you think, what will be the future of test automation in general and UI in particular?
- I do not like to make predictions, because they almost never come true. Testing is following development with some lag, weaving. Therefore, the developers dictate fashion: they all went to JS in unison - in testing, too, everyone rushed to JS. And we will need to comply with the changes. And what will the developers have - who knows.
Alexey will speak at the Moscow Heisenbug, held December 6-7 - and besides him, there will be dozens of other speakers. On the Heisenbug website, you can see the full program and purchase a ticket.