Читать онлайн «Как тестируют в Google». Страница 57

— Так значит, у вас больше тестировщиков, чем разработчиков в тестировании?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хун: Ладно, был у нас баг с активными обоями (Active Wallpaper) несколько выпусков назад. Иногда при запуске обоев все просто падало. Решение было простым, а мы выдали его так быстро, что пользователь почти ничего не заметил. Но это нас не оправдывает. Мы написали тесты для этого случая, поверьте мне, мы их написали!

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

Недавно мы встретились с Джоэлом и обсудили его представления о тестировании и опыт работы с Chrome и Chrome OS.

— Признавайся, на каком компьютере ты работаешь!

Джоэл (достает ноутбук): Chromebook — вот моя детка!

— Сколько еще гаджетов затерялось в твоем рюкзаке?

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

— Итак, ты руководишь тестированием и управляешь полным спектром продуктов: панели инструментов, инсталлеры Chrome и Chrome OS и все, что работает на клиентской операционной системе (и сама операционная система), — твои зоны ответственности. Тебе приходится управляться с множеством команд разработчиков. Как ты сохраняешь баланс?

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

— Ты жонглер или осьминог? А если серьезно, какое место ты занимаешь в этой многоходовой комбинации?

Джоэл: Стараюсь быть практичным. Мне нужно выпустить программу, а для этого придется чем-то пожертвовать. Это всегда торги. Конечно, у нас гибкая система разработки, но все равно приходится делать обязательную финальную проверку качества (мы называем ее «последняя миля»). Мы проводим исследовательское тестирование, но все равно отслеживаем разные версии и платформы. Все относительно.

Не бывает универсальных моделей тестирования, даже внутри одной компании условия различаются. Пример: мои команды Chrome и Chrome OS используют разные процессы, хотя работают в одном здании! Может, одна команда лучше другой? Не думаю. Я помогаю командам обмениваться информацией о рабочих методах, что делает нашу работу по тестированию более производительной. Моя команда тестирования должна быть готова ко всему, знать, какие приемы работают, а если она сталкивается с неработающими методами, то должна легко от них отказываться. Пока я не разобрался со всем этим до конца, я предпочитаю использовать гибридный метод — сочетание тестирования разработчиками, сценарного тестирования, исследовательского тестирования, тестирования на базе оценки рисков и функциональной автоматизации.

— Кажется, на горизонте маячит еще одна книга по организации тестирования в Google.

Джоэл: Да, дайте мне год, и мы сравним объемы продаж или рейтинги на Amazon. Хотя какого черта, мы в Google — мы померяемся релевантностью!

— Ладно, вернемся к тестированию в Chrome и Chrome OS. В этой книге мы обсуждаем общую инфраструктуру тестирования Google для команд веб-приложений. Ты ведь работаешь в клиентском пространстве, твоя работа сильно отличается?

Джоэл: Отличается, и это создает много проблем. Клиентское направление не основное направление в Google. Мы — веб-компания и знаем, как хорошо построить и протестировать веб-приложения. Основная проблема с клиентскими продуктами в том, чтобы преобразовать накопленный опыт и инструментарий для клиентских машин. Это серьезная трудность, ведь инфраструктура Google не может помочь моим проектам.