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

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

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

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

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

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

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

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

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

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

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

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