Уиттакер . - Как тестируют в Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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