Как заметить, что для компании важно тестирование? Если компания спонсирует соответствующую конференцию, а её сотрудник выступает там с докладом — значит, важно. В случае с Grid Dynamics и конференцией Гейзенбаг всё обстоит именно так, и перед конференцией мы решили задать вопросы двум сотрудникам компании:
- Евгению Хорохорину, генеральному директору Grid Dynamics в России — о компании в целом
- Илье korobochka Коробицыну, ведущему QA инженеру, который и выступит на конференции — непосредственно о его работе
Евгений Хорохорин
— Мы занимается построением высокотехнологичных масштабируемых решений в области электронной коммерции, финансов и других областях бизнеса. Основные наши направления — построение мультиканальных платформ в электронной коммерции, разработка поиска и персонализации, построение процессов непрерывной интеграции и облачных решений.
Среди наших клиентов — такие компании, как Google, American Eagle, eBay, Microsoft, VMware, PayPal, Yahoo!, Macy’s.
— В каких городах расположены офисы, и насколько они большие? Головной офис у вас в Кремниевой долине — приходится ли российским сотрудникам подстраиваться под время работы в нём?
— Компания была основана в 2006 году, и сейчас у нас уже более семисот человек в шести городах мира. У нас есть офисы в Украине (Харьков и Львов) и в Польше (Краков), а самый большой по численности — в Санкт-Петербурге, там сейчас работают более 250 человек. Также есть еще один офис в России — Саратов (170 человек).
График работы выстраивается с учётом солидной разницы во времени с головным офисом и клиентами в США (-10 часов). У сотрудников максимально гибкий график. Главное для нас — результат. Офис доступен круглосуточно. Тем не менее, необходимо присутствовать на всех рабочих митингах (встречах), не забывать о деловых звонках и выполнять свои задачи в срок.
— А что конкретно с тестированием — можете ли сказать, в каких городах у вас больше людей, связанных с ним, и сколько их именно?
— Самое большое число QA инженеров у нас в Санкт-Петербурге — 54 человека. На втором месте по численности Харьков — 42 человека. Тройку лидеров замыкают Саратов и Менло Парк в США, где численность QA инженеров примерно одинаковая: 24 и 23 человека соответственно. Мы, конечно же, не планируем на этом останавливаться — наша команда в каждой локации активно растёт.
Илья Коробицын
— Во-первых, обычная тестовая автоматизация: написание тестов к сервисам (чаще всего 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-тесты.
Комментарии (0)