Читаем Как тестируют в Google полностью

Хун: Нет, наоборот, разработчиков в тестировании почти вдвое больше. В моей команде каждый разработчик в тестировании может играть роль инженера по тестированию, когда это нужно, и наоборот. Я не обращаю особого внимания на должность человека, главное, чтобы он приносил пользу.

— Что ж, поговорим о ручном тестировании, потому что ты явно относишься к нему серьезно (и это восхищает!).

Хун: Я верю в пользу целенаправленного ручного тестирования. Действовать наугад неэффективно. Мы внимательно присматриваемся к ежедневной сборке, которую тестируем, и анализируем ее содержимое. Что изменилось? Сколько изменений добавилось или трансформировалось? Какая функциональность добавилась, а какая изменилась? Кто из разработчиков отправлял изменения? Насколько обширны изменения по сравнению со вчерашней сборкой? Это помогает сфокусироваться, и вместо рысканья по всему продукту мы сосредоточены на проверке изменений изо дня в день, что и делает нашу работу намного более производительной.

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

— Вы создаете документацию для ручного тестирования или занимаетесь исследовательским тестированием?

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

— Расскажи нам о своих требованиях к разработчикам. Ты требуешь от них спецификаций? Заставляешь применять TDD? Как насчет юнит-тестов?

Хун: Наверное, где-то есть сказочный мир, в котором каждой строке кода предшествует тест, а ему — спецификация. Не знаю, может, такой мир и существует. Но в стремительном современном мире, в котором я живу, приходится работать с тем, что имеешь. Есть спецификация? Отлично! Большое спасибо, пригодится! Давайте будем реалистами: нам нужно искать пути, как работать в существующей системе.

Если вы требуете спецификацию, это не значит, что вы ее получите. Если вы настаиваете на юнит-тестах, это еще не значит, что они принесут пользу. Ни написание спецификации, ни создание юнит-теста не поможет вам найти проблему, с которой столкнется реальный пользователь (кроме обнаружения очевидного регрессионного бага). Это законы моего мира — мира тестировщиков. Вы работаете с тем, что дано, и выжимаете из этого максимальную пользу для продукта и команды.

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

Я живу в мире, где каждый день выходят сотни изменений. Да, я сказал каждый день. Талантливым, прогрессивным разработчикам нужно столько же талантливых, прогрессивных тестировщиков. Для требований и капризов нет времени — только польза.

— Хун, мы рады, что ты на нашей стороне! А теперь блиц-опрос. Если бы тебе дали лишний день для тестирования выпуска Android, что бы ты сделал?

Хун: Если бы у меня был лишний день, я бы сделал еще одну сборку! Нет такого понятия — лишний день!

— Туше! Тебе есть о чем жалеть? Есть баг, который пробрался через канал выпуска к пользователю?

Хун: Прежде всего, такое может произойти с каждым тестировщиком на планете. Ни одна компания не выпускает продукт, полностью лишенный багов. Такова природа вещей. Но для меня все такие случаи были болезненными.

— Нет, ты так легко не отвертишься! Назови хотя бы один!