On the eve of Heisenbag: Grid Dynamics about testing

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

• Evgeny Khorokhorin , General Director of Grid Dynamics in Russia - about the company as a whole
• Ilya Korobochka Korobitsyn , QA Lead 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 building high-tech scalable solutions in the field of e-commerce, finance and other business areas. Our main areas are building multi-channel platforms in e-commerce, developing search and personalization, building processes of continuous integration and cloud solutions.



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



- In which cities are the offices located, and how large are they? Your head office is in Silicon Valley - do Russian employees have to adapt to their work time?



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



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



- And what specifically with testing - can you say in which cities you have more people associated with it, and how many of them are there?



- The largest number of QA engineers in St. Petersburg is 54 people. Kharkov ranks second in numbers - 42 people. The top three are Saratov and Menlo Park in the United States, where the number of QA engineers is about the same: 24 and 23, respectively. Of course, we do not plan to stop here - our team is actively growing in each location.

Ilya Korobitsyn

- What exactly do you do in Grid Dynamics?



- First, the usual test automation: writing tests to services (most often REST) ​​in Java or UI tests in JavaScript, there is nothing unusual here. Secondly, there are a little less usual projects. Thirdly, I help colleagues with all sorts of small tasks, like advice on solving some problems ("how to write this with one SQL query", "how to organize Maven modules here", "how best to write it in JS") I spend the code review. And, finally, I deal with all sorts of internal tasks, conduct interviews and develop tests that we give for pre-screening of candidates.



- Words about “less ordinary projects” are intriguing. Is there 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 approximately 100,000 clients from one CRM system (Client Relationship Management, all sorts of personal data like birthdays, names of wife and beloved dog) to another, moreover, it was not just a copy of the data one to one, but also some transformation, filtering invalid data and so on. I wrote tests that verified that nothing was lost and spoiled during the transfer process.



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



- Yes, I am engaged in testing, but I and the developer are no less. When writing tests, for example, at the component level, we integrate with Spring and Hibernate from the main application, we have to understand all this better 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 for you right now.



And in general, I believe that one must be well versed in all the tools with which one has to work, 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 GoF sense) 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 the test automation, the tester is more and more often the “developer to no less a degree”? What is it all about?



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



- Earlier in another report, you called for “peering inside” of the JsonWire protocol. And how much do you think it is important to “go inside” for a testing automator - does this dramatically improve qualifications, or just “nice to have”?



“Abstractions are great, 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 kind of high-level framework. There is such a fun 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 to know about the lower layers and not think, but on the other - it is necessary. That's it. Looking inward can help you understand the limitations of the layers that lie below and what’s wrong there. Which, again, will help to quickly deal with some "WAT" problem when everything looks like this:







- In the latter, you can hear more and more often about Kotlin - 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 hour will come. From the JVM family, we have Groovy and even a little Scala (for Gatling tests), I think Kotlin will have a place.



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



- I would like to report the following: for different tasks it is worth using suitable tools, this will help save both time and effort. This is where the broad outlook and ability to understand the device of things is useful: even if the tool itself cannot be applied, you can learn something useful from the way it works. That is why we have tests for Java, JS, Groovy, depending on what is appropriate for a particular project.



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



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



- In modern front-end development, most of the frameworks have come to build an interface from individual components. It does not leave the feeling that Page Objects for UI tests could be generated automatically from these components, but we have not yet been able to find a suitable tool, but haven’t gotten to write it myself.



- Tell us briefly what you will talk about on Heisenbag?



- My report will be of interest primarily to those who will write UI tests for Angular applications, and 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 framework (Protractor) to help testers, and what WTF-moments can be encountered if you rush to write tests with it, without really understanding JS (good language is simple). And in the end there will be, in my opinion, the most interesting thing: we will look inside Protractor to understand how he does his magic, and try to transfer it to Java tests.