Ahead of Heisenbug: Grid Dynamics on Testing

How to notice that testing is important for the company? If the company sponsors a conference, and its employee makes a report there, then it’s important. In the case of Grid Dynamics and the Heisenbag conference, this is exactly the case, and before the conference we decided to ask two employees of the company:

• Evgeny Khorokhorin , CEO of Grid Dynamics in Russia - about the company as a whole
• Ilya korobochka Korobitsyn , leading QA engineer, who will speak at the conference - directly about his work

Evgeny Khorokhorin

- Not everyone knows Grid Dynamics - tell us briefly what the company does.

- We are engaged in the construction of high-tech scalable solutions in the field of e-commerce, finance and other business areas. Our main areas are building multi-channel platforms in electronic commerce, developing search and personalization, building continuous integration processes and cloud solutions.

Among our customers are companies such as Google, American Eagle, eBay, Microsoft, VMware, PayPal, Yahoo !, Macy's.

- In which cities are offices located, and how large are they? Your head office is in Silicon Valley - do Russian employees have to adapt to working hours in it?

- The company was founded in 2006, and now we have more than seven hundred people in six cities around the world. We have offices in Ukraine (Kharkov and Lviv) and Poland (Krakow), and the largest in number is in St. Petersburg, more than 250 people now work there. There is also another office in Russia - Saratov (170 people).

The work schedule is built taking into account a solid time difference with the head office and customers in the USA (-10 hours). The employees have the most flexible schedule. The main thing for us is the result. The office is available around the clock. Nevertheless, it is necessary to attend all working meetings (meetings), not to forget about business calls and to complete your tasks on time.

- And what exactly with testing - can you tell in which cities you have more people associated with it, and how many of them?

- The largest number of QA engineers in St. Petersburg is 54 people. In second place in terms of Kharkov - 42 people. The top three are closed by Saratov and Menlo Park in the USA, where the number of QA engineers is about the same: 24 and 23 people, respectively. Of course, we do not plan to stop there - our team is actively growing in each location.

Ilya Korobitsyn

- What exactly do you do in Grid Dynamics?

- Firstly, the usual test automation: writing tests for services (most often REST) ​​in Java or UI tests in JavaScript, there is nothing unusual here. Secondly, some less ordinary projects come across. Thirdly, I help my colleagues with all sorts of small tasks, such as tips for solving some problems (“how to write this in one SQL query”, “how to organize Maven modules”, “how best to write this in JS”), I spend a code review. And finally, I’m doing all sorts of internal tasks, conducting interviews and developing tests that we give for screening candidates.

- The words about “less ordinary projects” are intriguing. Can I have an example?

- Well, for example, recently our customer bought another company, and the integration process was going on. It was necessary to transfer information about about 100,000 clients from one CRM system (Client Relationship Management, all sorts of personal data such as birthdays, wife's and beloved dog's names) to another, moreover, it was not just a one-to-one copy of the data, but there were also some transformations, filtering invalid data, and more. I wrote tests that checked that nothing was lost or spoiled during the transfer.

- Do we understand correctly that you find yourself on the border of several worlds at once: testing and development, Java and JavaScript? What is it like living there? :)

- Yes, I am engaged in testing, but I and the developer are no less. When writing tests, for example, of the component level, we integrate with Spring and Hibernate from the main application, we have to understand all this no worse than developers. Plus, for the notorious “unusual” tasks, you often have to write something new from scratch, since there are no ready-made solutions that would be suitable right now.

Anyway, I think that you need to have a good understanding of all the tools you have to work with, and also constantly learn something new - knowledge, even if they are not useful right away, will still be useful. The broader the horizons, the easier it is to see familiar “patterns” (not in the sense of GoF) in unfamiliar areas; this greatly helps to quickly solve even not very familiar tasks.

- In the case of DevOps, the developer gets more and more administrator tasks - does it turn out that with testing automation the tester more and more often turns out to be "a developer to no lesser extent"? What is it all going to?

- Testing is not only about quality assurance, but also about reducing development and support costs. There are tasks where automation is disadvantageous (it is difficult to develop and maintain tests), these conditional 5-10% are still checked manually, and this is reasonable. The rest of the automation fits perfectly with the current vision of the development process: you can quickly run the application through the pipeline, and the developer receives a feedback with some confidence in their changes, this helps to move forward faster. A separate tester will always be useful in that he looks at the task from the other side and he does not interfere with the mental model of the exact architecture of the application, which imposes restrictions and does not allow considering some cases.

- Earlier in another report, you called for a “look inside” of the JsonWire protocol. And how much, in your opinion, is it important to “climb inside” for the testing automation tool at all - does it sharply increase qualifications, or just “nice to have”?

- Abstractions are wonderful, and without them we would not be able to write complex programs. Now it’s even scary to imagine how many of these layers are between silicon and some high-level framework. There is such a funny page , but not everything is covered there.

Unfortunately, abstractions tend to “leak”, and most often this happens when something breaks. On the one hand, I would like not to know and not think about the lower layers, but on the other hand, I have to. That's it. Looking inside can help to understand what restrictions are imposed by the layers lying below, and what could go wrong there. Which, again, will help to quickly deal with some kind of “WAT” problem when everything looks like this:



- In the last, you hear more and more often about Kotlin - but does it make itself felt in test automation? What JVM languages ​​are used for tests in Grid Dynamics?

- So far, not really, but it seems to me that his time will come. From the JVM-family we have Groovy and even a little Scala (for Gatling-tests), I think, and Kotlin there is a place.

- Is there any general idea in connection with testing that I would like to convey to the community?

- I would like to convey the following: for various tasks it is worth using the appropriate tools, this will help save both time and energy. That’s why a broad outlook and the ability to understand the structure of things are useful: even if you can’t apply the tool itself, you can learn something useful from how it works. That is why we have tests in Java, JS, Groovy, depending on what suits a specific project.

Of course, do not go to extremes: if some task is small and one-time, then it may be faster to do everything with your hands and forget.

- To the question of tools: are there any that you lack in your work, or do you feel that now all your needs are already covered?

- In modern front-end development, most of the frameworks have come to assemble an interface from individual components. There is a feeling that Page Objects for UI tests could be generated automatically from these components, but so far they have not been able to find a suitable tool, and they themselves couldn’t write.

- Tell us briefly what you will talk about in Heisenbug?

- My reportIt will be interesting primarily to those who will write UI tests for Angular applications, and to those who wrote Selenium tests in Java or Python, but never did it in JavaScript. We will look at why Angular developers decided to make a special Protractor framework to help testers, and what WTF moments you might encounter if you rush to write tests using it without really understanding JS (since the language is simple). And in the end there will be, in my opinion, the most interesting: we will look inside Protractor to understand how he does his magic, and try to transfer it to Java tests.