Как заметить, что для компании важно тестирование? Если компания спонсирует соответствующую конференцию, а её сотрудник выступает там с докладом — значит, важно. В случае с Grid Dynamics и конференцией Гейзенбаг всё обстоит именно так, и перед конференцией мы решили задать вопросы двум сотрудникам компании:

• Евгению Хорохорину, генеральному директору Grid Dynamics в России — о компании в целом
• Илье korobochka Коробицыну, ведущему QA инженеру, который и выступит на конференции — непосредственно о его работе

Евгений Хорохорин

— Не все знают Grid Dynamics — расскажите вкратце, чем занимается компания?

— Мы занимается построением высокотехнологичных масштабируемых решений в области электронной коммерции, финансов и других областях бизнеса. Основные наши направления — построение мультиканальных платформ в электронной коммерции, разработка поиска и персонализации, построение процессов непрерывной интеграции и облачных решений.

Среди наших клиентов — такие компании, как Google, American Eagle, eBay, Microsoft, VMware, PayPal, Yahoo!, Macy’s.

— В каких городах расположены офисы, и насколько они большие? Головной офис у вас в Кремниевой долине — приходится ли российским сотрудникам подстраиваться под время работы в нём?

— Компания была основана в 2006 году, и сейчас у нас уже более семисот человек в шести городах мира. У нас есть офисы в Украине (Харьков и Львов) и в Польше (Краков), а самый большой по численности — в Санкт-Петербурге, там сейчас работают более 250 человек. Также есть еще один офис в России — Саратов (170 человек).

График работы выстраивается с учётом солидной разницы во времени с головным офисом и клиентами в США (-10 часов). У сотрудников максимально гибкий график. Главное для нас — результат. Офис доступен круглосуточно. Тем не менее, необходимо присутствовать на всех рабочих митингах (встречах), не забывать о деловых звонках и выполнять свои задачи в срок.

— А что конкретно с тестированием — можете ли сказать, в каких городах у вас больше людей, связанных с ним, и сколько их именно?

— Самое большое число QA инженеров у нас в Санкт-Петербурге — 54 человека. На втором месте по численности Харьков — 42 человека. Тройку лидеров замыкают Саратов и Менло Парк в США, где численность QA инженеров примерно одинаковая: 24 и 23 человека соответственно. Мы, конечно же, не планируем на этом останавливаться — наша команда в каждой локации активно растёт.

Илья Коробицын

— Чем именно вы занимаетесь в Grid Dynamics?

— Во-первых, обычная тестовая автоматизация: написание тестов к сервисам (чаще всего REST) на Java или UI-тестов на JavaScript, тут ничего необычного. Во-вторых, попадаются чуть менее обычные проекты. В-третьих, помогаю коллегам со всякими мелкими задачами, вроде советов по решению каких-то проблем («а как написать вот это одним SQL запросом», «как тут организовать Maven модули», «как лучше вот это написать на JS»), провожу код-ревью. И, наконец, занимаюсь всякими внутренними задачами, провожу собеседования и разрабатываю тесты, которые мы даём для прескрининга кандидатов.

— Слова про «менее обычные проекты» интригуют. Можно пример?

— Ну, например, недавно наш заказчик купил другую компанию, и происходил процесс интеграции. Нужно было перенести информацию о примерно 100 000 клиентов из одной CRM-системы (Client Relationship Management, всякие личные данные вроде дней рождения, имён жены и любимой собаки) в другую, причём это была не просто копия данных один к одному, а ещё происходили некоторые трансформации, фильтрация невалидных данных и прочее. Я написал тесты, которые проверяли, что в процессе переноса ничего не потерялось и не попортилось.

— Правильно ли понимаем, что вы оказываетесь на границе сразу нескольких миров: тестирования и разработки, Java и JavaScript? Каково там живётся? :)

— Да, занимаюсь тестированием, но я и разработчик не в меньшей степени. При написании тестов, например, компонентного уровня, мы интегрируемся со Spring и Hibernate из основного приложения, разбираться во всём этом приходится не хуже разработчиков. Плюс для пресловутых «необычных» задач часто приходится писать что-то новое с нуля, так как нет готовых решений, которые бы подходили конкретно сейчас.

Да и вообще я считаю, что надо хорошо разбираться во всех инструментах, с которыми приходится работать, а также постоянно изучать что-то новое — знания, даже если они не пригодятся вот прямо сразу, всё равно будут полезны. Чем шире кругозор, тем легче видеть знакомые «паттерны» (не в смысле GoF) в незнакомых областях, это сильно помогает быстро решать даже не очень знакомые задачи.

— В случае с DevOps разработчику достаётся всё больше задач администратора — а оказывается ли так, что с автоматизацией тестирования тестировщик всё чаще и чаще оказывается «разработчиком в не меньшей степени»? К чему всё идёт?

— Тестирование — это не только про обеспечение качества, но и про сокращение расходов на разработку и поддержку. Есть задачи, где автоматизация невыгодна (сложно разрабатывать и поддерживать тесты), эти условные 5-10% по прежнему проверяют вручную, и это разумно. В остальном автоматизация отлично вписывается в нынешнее видение процесса разработки: можно быстро прогнать приложение через пайплайн, и разработчик получает фидбек с некой уверенностью в своих изменениях, это помогает быстрее двигаться вперёд. Отдельный тестировщик всегда будет полезен тем, что смотрит на задачу с другой стороны и ему не мешает ментальная модель точной архитектуры приложения, которая накладывает ограничения и не даёт рассмотреть некоторые случаи.

— Ранее в другом докладе вы призывали «заглядывать внутрь» протокола JsonWire. А насколько, по-вашему, важно вообще «лезть внутрь» для автоматизатора тестирования — это резко повышает квалификацию, или просто «nice to have»?

— Абстракции — это прекрасно, и без них мы бы не смогли писать сложные программы. Сейчас даже страшно представить, сколько этих слоёв находится между кремнием и каким-нибудь высокоуровневым фреймворком. Есть вот такая забавная страничка, но там покрыто далеко не всё.

К сожалению, абстракции имеют тенденцию «протекать», и чаще всего это происходит, когда что-то ломается. С одной стороны, хотелось бы про нижние слои не знать и не думать, а с другой — приходится. Вот такие дела. Заглядывание внутрь может помочь понять, какие ограничения накладываются слоями, лежащими снизу, и что там может пойти не так. Что, опять же, поможет быстро разобраться с какой-нибудь «WAT»-проблемой, когда всё выглядит так:



— В последнее всё чаще слышно про Kotlin — а в автоматизации тестирования он даёт о себе знать? Какие JVM-языки используют для тестов в Grid Dynamics?

— Пока что не особо, но мне кажется, что его час настанет. Из JVM-семейства у нас есть Groovy и даже немного Scala (для Gatling-тестов), думаю, и Kotlin найдётся место.

— Есть ли в связи с тестированием какая-то общая мысль, которую хотелось бы донести до сообщества?

— Донести хотелось бы следующее: для разных задач стоит использовать подходящие инструменты, это поможет сэкономить и силы, и время. Именно этим полезен широкий кругозор и способность разбираться в устройстве вещей: даже если не получится применить сам инструмент, можно узнать что-то полезное из того, как он работает. Именно поэтому у нас есть тесты на Java, JS, Groovy, смотря что подходит конкретному проекту.

Разумеется, не стоит впадать в крайности: если какая-то задача небольшая и одноразовая, то может быть быстрее сделать всё руками и забыть.

— К вопросу об инструментах: а есть ли какие-то, которых вам в работе не хватает, или ощущаете, что сейчас все потребности уже покрыты?

— В современной фронтенд-разработке большая часть фреймворков пришла к тому, чтобы собирать интерфейс из отдельных компонентов. Не покидает ощущение, что Page Objects для UI-тестов можно было бы генерировать автоматически из этих компонентов, но подходящего инструмента пока найти не удалось, а написать самому не дошли руки.

— Расскажите вкратце, о чём будете говорить на Гейзенбаге?

— Мой доклад будет интересен в первую очередь тем, кто будет писать UI-тесты для Angular приложений, и тем, кто писал Selenium-тесты на Java или Python, но никогда этого не делал на JavaScript. Мы рассмотрим, почему разработчики Angular решили сделать специальный фреймворк (Protractor) в помощь тестировщикам, и с какими WTF-моментами можно столкнуться, если броситься писать с его помощью тесты, не особо разбираясь в JS (благо язык простой). И в конце будет, на мой взгляд, самое интересное: мы заглянем внутрь Protractor, чтоб понять, как он делает свою магию, и попробуем её перенести в Java-тесты.

https://habrahabr.ru/post/330104/