Интервью с Шелтоном Маром, директором по тестированию проектов Search и Geo

Интервью с Шелтоном Маром, директором по тестированию проектов Search и Geo

Шелтон Мар — директор по тестированию; эта должность является аналогом вице-президента в других компаниях. Он один из самых давних тестировщиков Google, человек, который пришел раньше Патрика Коупленда, в те времена, когда направление продуктивности разработки еще называлось просто службой тестирования. Шелтон вырос из тест-менеджера маленьких групп в директора, отвечающего за весь поиск, карты и инфраструктуру. Сейчас он руководит тестированием направления продуктов, которое Google называет Local and Commerce: все продукты, относящиеся к геолокации, включая Google Earth и Maps.

Мы встретились с Шелтоном, чтобы узнать о прошлом Google и о том, что было сделано для тестирования Google Search.

— Шелтон, ты долго работаешь в Google и, наверное, помнишь службу тестирования, о которой Патрик упоминает в предисловии. Расскажи, как выглядело тестирование в далекий докоуплендский период?

Шелтон: Тогда, конечно, все было иначе, но одна вещь так и не изменилась — компания Google всегда могла работать в очень быстром темпе. В те дни нам везло, так как интернет был проще, приложения меньше, а группы умных людей, просто работающих в полную силу, было достаточно. Было много авралов, но нескольких героев хватало, чтобы их преодолеть. В продуктах образовывались зависимости системного уровня, а сквозное тестирование проводилось и вручную, и автоматически. Чем больше мы росли, тем больше проблем вырастало из этих зависимостей.

Не хочу сказать ничего плохого о таком тестировании, оно является необходимой частью проверки правильности работы интегрированной системы, но чрезмерные зависимости на поздних циклах тестирования сильно усложняют отладку.

Мы пытались решить эту проблему, когда появился Пат.

— В бэкенд-системах, где труднее определить сквозной сценарий, ситуация была еще хуже?

Шелтон: Именно! Мы часто не могли выпускать бэкенд-системы так быстро, как хотели, потому что у нас возникали трудности с проверкой качества. От бэкенд­-систем зависит много вертикалей продуктов, поэтому они должны работать правильно. Например, из-за ошибки в BigTable пострадает множество приложений. Обновление такой системы создает «эффект домино» из-за проблем, которые невозможно обнаружить только сквозными тестами.

— То есть ты заменил затратные сквозные проверки усиленными проверками серверной инфраструктуры бэкендов? Расскажи о своих шагах.

Шелтон: Сначала мы изменили состав команды. Мы переопределили роль разработчика в тестировании и сосредоточились на найме технически сильных специалистов. Когда нужные люди были собраны, мы взялись за создание лучшего решения для бэкенд-тестирования. Мы сосредоточились на автоматизации уровня компонентов. Представьте команду изобретательных инженеров с навыками разработки и тестирования, дружно создающих бэкенд-инфраструктуру, и вы поймете, как шли дела.

— Какой фактор был ключевым для вашего успеха?

Шелтон: Для нас было важно получить поддержку разработчиков. Наши разработчики в тестировании очень тесно работали со своими партнерами из разработки (я специально использую слово «партнер», потому что это была совместная работа, а вовсе не заслуга только тестирования). Ребята вместе создавали новые методы тестирования на уровне разработки, и вся наша работа становилась лучше благодаря такому партнерству. Когда какие-то задачи не решались на уровне компонентов, мы решали их уровнем ниже. Динамика группы изменилась, и теперь вся команда проекта (и разработка, и тестирование) отвечала за качество на уровне компонентов, а инженеры по тестированию сосредоточились на процессе, фреймворках, инструментах и интеграции.

— Ты принимал довольно рискованные решения — например, склонить высокопрофессиональных разработчиков к тестированию. Что это дало? Не сожалеешь ли ты об этом? Как это повлияло на культуру тестиро­-вания?

Шелтон: Вероятно, это стало самым важным нашим решением для Google. Мы осознали, какие вещи мы должны изменить в Google как можно раньше:

— преобразовать тестирование так, чтобы вся команда (и разработка, и тестирование) отвечала за качество продукта;

— тестирование должно стать неотъемлемой частью проектной команды. Значит, нам были нужны сильные инженеры, отлично ориентирующиеся в технологиях;

— тестирование должно использовать современные компьютерные технологии и методы.

Чтобы добиться этого, нам нужны были умные и сильные инженеры-программисты, которые понимают в тестировании (или хотя бы могут научиться). Как только мы взглянули на задачу с этой стороны, мы поняли, что можем привлечь в нашу команду лучших инженеров, чтобы расправиться с нашими головоломками тестирования. Тот факт, что мы собрали большую команду таких ребят, свидетельствует, что им действительно интересно.

— Во время своей работы в Google ты работал над многими проектами, включая ключевой для компании проект поисковой системы. Что было самым трудным в его тестировании?

Шелтон: Решить, на чем сосредоточить тестирование! Когда инженеры начали смотреть на тестирование Search, они стали говорить о том, что Google выдает в результатах поиска. Конечно, эта тема достойна исследования, но качество поиска подразумевает намного больше. Чтобы пользователь получал однозначные, надежные и быстрые ответы, мы должны проверить всю сложную распределенную программную систему, которая возвращает результаты. Тестировщик должен понимать алгоритмы индексирования и поиска. Тестировщик должен понимать всю подноготную системы, как она устроена, чтобы уметь проверять ее действия там, где они происходят, тогда, когда они происходят.

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

— С чего ты обычно начинаешь работу над новым проектом? Что делаешь в первую очередь? С точки зрения формирования команды? С точки зрения технической инфраструктуры? С точки зрения процесса тестирования?

Шелтон: Обычно мой первый вопрос к команде: «Что самое важное для тестируемой системы?». Для поиска важно быстродействие, для новостей — актуальность, для карт — покрытие. Каждое приложение стоит на своих китах. Тип системы помогает нам определить ее важные аспекты: целостность данных важна для хранилища, возможность масштабирования — для сетевых программ, возможность совместного использования — для систем управления проектами.

Определили важные части тестируемого продукта? Направляйте на их проработку основные силы. Несложными компонентами (типа доработки пользовательского интерфейса и прочей мишуры) можно заняться после. Сосредоточьтесь на базовых атрибутах продукта, которые трудно изменить, и не тратьте много времени на вещи, которые изменяются легко. Например, если тестировщик рано начал заводить баги, пойманные в шрифтах, я решу, что он неправильно расставил приоритеты.

— Между ручным и автоматизированным тестированием всегда существовали трения. Похоже, Google от высокой доли ручного тестирования переходит к высокой доле автоматизированного тестирования. Что ты думаешь по этому поводу? Какая пропорция правильна? Как ты понимаешь, что перестарался в том или ином направлении?

Шелтон: Я считаю, следует автоматизировать как можно больше. Мы используем концепцию непрерывной сборки, при которой ручное тестирование только мешает. Проверка на уровне компонентов и интеграционные тесты делают то, с чем ручное тестирование не справится. С другой стороны, автоматизация недостаточно гибка к изменениям и требует сопровождения. Технологии стремительно изменяются, и автоматизацию тоже нужно дорабатывать, чтобы успевать за ними.

Должен сказать, что ручное тестирование тоже в чем-то уникально. В области мобильных приложений, например. Изобилие оборудования, экранов, форм-факторов и драйверов порождает разнообразие в отображении и визуализации. Нам приходится тестировать эту область вручную. Но мы все равно стараемся автоматизировать и этот процесс, насколько это возможно. Пусть машина выполнит 90% работы, а человеческие ресурсы мы подключим только на последних 10% цикла проверки, которые мы называем «последней милей». Автоматизация может сделать снимки экранов устройств, а человек быстро проверит различия в изображениях, найденные алгоритмом. Человеческий разум слишком ценен, чтобы тратить его на то, с чем справится компьютер. Оставьте однообразные задачи машинам, человек нам еще пригодится.

— Опиши баг, который ускользнул от вас и заставил краснеть после выпуска.

Шелтон: Об этом обязательно нужно спрашивать? Скажите мне, хоть кто-нибудь выпускал идеальный продукт? К сожалению, не я! Самые болезненные для меня баги всплыли после недостаточно тщательного тестирования изменений в конфигурации дата-центра. Однажды новая версия была выпущена вообще без проверки, и качество результатов поиска ухудшилось. Зато мы узнали, насколько эти изменения важны для качества. С тех пор мы включили их в обязательную проверку. У нас есть набор автоматизированных тестов, которые должны быть выполнены до того, как изменения в конфигурации или данных пойдут в эксплуатацию.

— Как вы определили, какие тесты конфигураций нужно автоматизировать?

Шелтон: Проявили наблюдательность! Каждый раз, когда мы находили конфигурацию, отрицательно влиявшую на результаты поиска, мы писали тесты для нее и всех ее вариаций, которые могли бы показать такие же плохие результаты. Вскоре в нашем тестовом пакете сформировался целый набор проблемных конфигураций. Потом мы сгенерировали набор данных, на которых мы могли тестировать проблемные конфигурации. Этот тип багов стал встречаться реже благодаря нашим действиям. Вот хороший пример того, как автоматизация придает нам уверенности при выпуске изменений.

Данный текст является ознакомительным фрагментом.