все понимали эти термины одинаково[10]. Здесь важно то, что тестировщики Google говорят на одном языке, описывая, что именно тестируется и в каком объеме. Когда кто-то особо изобретательный говорит о четвертой разновидности тестов, которую они прозвали громадными тестами, любой инженер в компании сразу представит себе общесистемный тест, который выполняется очень долго и проверяет все функциональные аспекты. Ничего больше пояснять не требуется[11].
Мы определяем, в каком объеме проводить тестирование и что именно тестировать, по-разному для каждого конкретного продукта. Google предпочитает выпускать часто и стремится как можно раньше передать продукт пользователям, чтобы быстрее получить обратную связь и внести необходимые изменения. Google тратит много сил на то, чтобы создавать продукты, которыми люди действительно пользуются. Мы выкатываем новые фичи как можно раньше, чтобы они начали приносить пользу. Плюс мы избегаем лишних затрат на фичи, которые не нужны пользователям, потому что вовремя об этом узнаем. Для этого мы подключаем пользователи и внешних разработчиков в процесс как можно раньше. Так мы понимаем, соответствует ли наш продукт их ожиданиям.
Наконец, выбирая между автоматизированным и ручным тестированием, мы отдаем предпочтение первому. Если это можно автоматизировать и проблема не требует человеческого внимания и интуиции, то это нужно автоматизировать. Только проблемы, которые явно требуют оценки человеком (например, красив ли пользовательский интерфейс или не нарушает ли раскрытие данных конфиденциальность), должны доставаться ручному тестированию.
На заметку
Выбирая между автоматизированным и ручным тестированием, мы отдаем предпочтение первому. Если это можно автоматизировать и проблема не требует человеческого внимания и интуиции, то это нужно автоматизировать.
Замечу, что в Google выполняется очень много ручного тестирования, как сценарного, так и исследовательского, но даже оно проходит под зорким присмотром автоматизации. Технологии записи преобразуют ручные тесты в автоматизированные, которые снова прогоняются на последующих сборках, чтобы отловить регрессионные баги и дать тестировщикам возможность переключиться на новые проблемы. Мы автоматизируем отправку баг-репортов и распределение задач ручного тестирования[12]. Например, если автоматизированный тест не проходит, система определяет последнее изменение кода, которое считает наиболее вероятной причиной, отправляет сообщение его авторам и автоматически заводит баг. Максимально приблизить автоматизацию к человеческим возможностям – это техническое задание для следующего поколения инструментов тестирования, создаваемых в Google.
Глава 2. Разработчик в тестировании
Давайте представим идеальный процесс разработки. Все начинается с теста. Вот код, который построил разработчик Джек. А вот – тест, который разработчик Джек придумал
Классификация на малые, средние и большие тесты была выбрана для стандартизации. Многие тестировщики пришли к нам из разных компаний, в которых понятия «смоук-тестирования», BVT (Build Verification Test), интеграционных тестов и т. д. имели разные, часто противоположные значения. Старые термины приносили с собой столько хаоса, что я решил ввести новую терминологию.
Кстати, концепция громадных тестов формализована, и инфраструктура автоматизации Google использует понятия малых, средних тестов (и далее по списку) для определения последовательности автоматизированного выполнения. Эта тема более подробно рассматривается в главе, посвященной разработчикам в тестировании.
Технологии записи Google и ручное тестирование со вспомогательной автоматизацией подробно описаны в главах, посвященных роли инженеров по тестированию.
