Интервью с Хуном Даном, тест-менеджером Android
Интервью с Хуном Даном, тест-менеджером Android
До того как Хун Дан был приглашен возглавить команду тестирования Android, он успел успешно поработать инженером в Apple и TiVo.[67]
Cтратегическую важность Android для Google трудно отрицать. Этот проект стал таким же хитом, как Search или Ads. Android получил особое внимание руководства и привлек первоклассных специалистов. Его кодовая база растет на глазах, и одна сборка может насчитывать сотни изменений в день. На базе этой операционной системы запускаются тысячи приложений, вокруг нее формируется сообщество разработчиков. Количество устройств, работающих на платформе Android, постоянно растет; она стоит на новых телефонах и планшетах множества производителей. В зоне ответственности Хуна и его команды все: от тестирования совместимости устройств и управления питанием до проверки работы приложений.
Мы встретились с Хуном, чтобы узнать, как организовано тестирование Android.
— Расскажи нам о том, как начиналось тестирование. Наверное, на первых порах, до появления смартфонов и многочисленных приложений, было проще?
Хун: К сожалению, нет. Когда я взял на себя руководство тестированием Android, команда только сформировалась и многие инженеры никогда не тестировали до этого операционные системы, не говоря уже о мобильных устройствах. Моей первой задачей было скоординировать работу команды и построить инфраструктуру тестирования. Я думаю, что начальная фаза проекта тестирования — самая трудная часть работы. Когда у тебя есть крепко сбитая команда и налаженная инфраструктура, то можно справиться с продуктом любой сложности. Тяжелее всего в планировании, зато потом легко в тестировании!
— Давай остановимся здесь, ведь множество менеджеров по тестированию бьются на ранних стадиях своих проектов прямо сейчас. Расскажи, что вы делали на ранней стадии проекта Android?
Хун: Серьезных задач было много. Самая первая — вникнуть в продукт. Я требую от тестировщиков досконального знания продукта. Первым делом нужно тщательно освоить то, с чем работаешь. Каждый участник моей команды должен знать структуру продукта, и точка. Когда ваши знания достигнут нужного уровня, самые сложные проблемы тестирования окажутся на поверхности и вам, отталкиваясь от них, будет легко формировать команду. Нанимайте или привлекайте людей, которые справятся с самыми сложными задачами проекта. Структура Android очень разветвленная: от аппаратного уровня до ОС, фреймворка, модели приложений и магазина. В этом проекте много динамических частей, требующих особой квалификации тестирования. Поэтому первое, что я сделал, — это выявил их и собрал такую команду, которая бы с ними справилась.
Когда команда была сформирована, я отдал приказ: «Приносите пользу!» Точнее, приносите пользу постоянно. Все, от разработчика до руководителя, должны содействовать тестированию, находиться в общем потоке. Делаете немного меньше — и вы уже мешаете. На раннем этапе общая задача — способствовать успешному запуску продукта. Я не буду спорить: многое из того, что мы делали, было за рамками компетенции тестировщиков, но вся наша работа шла проекту на пользу, и мы выпустили качественный продукт. Мне удалось расставить правильных людей по своим местам, и мы синхронизировали рабочий процесс. Стала возможна ежедневная сборка, конфликты были исключены, и даже сообщения о багах моя команда отправляла в едином стиле. Все дело в правильно подобранной команде.
— Звучит впечатляюще. И как команда справлялась?
Хун: На самом деле я потерял около 80% старой команды. Зато оставшиеся стали техническими лидами. Они подавали пример и работали с новичками, которых мы привлекали в команду. Нет универсальных людей, которые вписываются во все проекты. В Google достаточно работы, и если кому-то не подошел Android, то, возможно, подойдет другой проект. В Google такое разнообразие и создает здоровую среду тестирования.
— Какие были приятные моменты тестирования?
Хун: Приятно, что нам удалось сфокусироваться на пользе. Все, что мы делали, имело цель. Мы ставили под сомнение все: каждый тестовый пример, каждый блок автоматизации. И многое из того, что было сделано раньше, не проходило этой проверки. Любую часть автоматизации, у которой не было ясной цели, мы тут же выбрасывали. Все крутилось вокруг пользы. Если бы мне предложили дать совет начинающим менеджерам по тестированию, я бы сказал: все, что вы делаете, должно приносить максимальную пользу и приносить ее неоднократно.
— Это непросто, хотя по твоим словам этого и не скажешь! Расскажи нам более подробно об организации тестирования, о которой ты обмолвился. Ты коснулся процесса сообщения о багах, но, конечно, это не все. Как ты организуешь саму работу?
Хун: Я воспринимаю структуру Android как своеобразную «колоннаду». Я знаю, что при тестировании Chrome OS вы используете другую терминологию, но мне нравится идея тестовых колонн. Каждая группа тестировщиков отождествляется с одной из таких колонн, на которых держится весь продукт. Для Android мы организовали четыре колонны: системную (ядро, носители информации и т.д.), колонну фреймворков, колонну приложений и колонну магазина приложений. Спросите любого из моих тестировщиков, что они тестируют, и вам укажут одну из этих колонн.
— Логично, что колонны соответствуют разным навыкам тестировщиков. Одни хорошо работают с низкоуровневыми аспектами, другие лучше справляются с высокоуровневыми, а вместе они поддерживают всю систему. Хорошая схема. А как насчет автоматизации? Как она вписывается в вашу задачу?
Хун: Я научился скептически относиться к автоматизации. Тестировщики могут загореться идеей автоматизации продукта и потратить месяцы на ее создание, а потом продукт или платформа меняется, и все, что они сделали, идет прахом. Нет более бессмысленной траты ресурсов. На мой взгляд, автотесты должны быстро создаваться, быстро выполняться и решать узкую задачу. Если цель автоматизированного теста непонятна сразу, значит он слишком сложен. Сделайте автоматизацию простой, ограничьте ее масштаб, а самое главное — следите за тем, чтобы она приносила пользу. Например, у нас есть пакет автоматизированных тестов, который проверяет сборку на возможность перехода из канареечного канала в Droid-канал.
— Минуточку! Что за Droid-канал?
Хун: О, извини. Как я уже упоминал в начале разговора, в проекте Android некоторые вещи делаются иначе. И называются тоже по-другому — мы используем не те каналы, к которым вы привыкли в Chrome. У нас есть канареечный канал, Droid-канал (аналог канала внутренних пользователей, но для команды Android), экспериментальный канал, Google-канал и уличный канал (сборка, которую мы передаем для внешнего использования). Идея та же, просто другое название.
— Итак, у вас есть пакет автоматизированных тестов для выявления багов, препятствующих переходу канареечной сборки в канал для разработчиков. Этими тестами занимаются выделенные разработчики в тестировании?
Хун: Ни в коем случае. У меня нет ни одного специализированного тестировщика. Все занимаются ручным тестированием, буквально все. Исследовательское тестирование — лучший способ хорошо изучить продукт. Я не хочу, чтобы мои разработчики в тестировании только и делали, что писали фреймворки. Я хочу, чтобы они были вовлечены в продукт и знали, как его использовать. Каждый тестировщик должен смотреть на продукт глазами пользователя, должен быть экспертом, разбирающимся во всех тонкостях продукта. Автоматизации мы оставляем тестирование стабильности, управления питанием, производительности, нагрузки, ну и еще быстрые проверки. Не нужен человек, чтобы обнаружить утечку памяти из-за использования камеры или чтобы проверить одну и ту же фичу на всех платформах. Действия, которые требуют многократного повторения или машинной точности, недоступной для людей, — вот где нужна автоматизация.
— Так значит, у вас больше тестировщиков, чем разработчиков в тестировании?
Хун: Нет, наоборот, разработчиков в тестировании почти вдвое больше. В моей команде каждый разработчик в тестировании может играть роль инженера по тестированию, когда это нужно, и наоборот. Я не обращаю особого внимания на должность человека, главное, чтобы он приносил пользу.
— Что ж, поговорим о ручном тестировании, потому что ты явно относишься к нему серьезно (и это восхищает!).
Хун: Я верю в пользу целенаправленного ручного тестирования. Действовать наугад неэффективно. Мы внимательно присматриваемся к ежедневной сборке, которую тестируем, и анализируем ее содержимое. Что изменилось? Сколько изменений добавилось или трансформировалось? Какая функциональность добавилась, а какая изменилась? Кто из разработчиков отправлял изменения? Насколько обширны изменения по сравнению со вчерашней сборкой? Это помогает сфокусироваться, и вместо рысканья по всему продукту мы сосредоточены на проверке изменений изо дня в день, что и делает нашу работу намного более производительной.
Понятно, что координация в команде очень важна. Так как я настаиваю, что каждый участник должен заниматься исследовательским тестированием, нужно свести к минимуму перекрытия. На планерках мы уточняем, что нужно тестировать, и определяем, кто чем занимается. Я считаю ручное тестирование успешным, если оно целенаправленно и скоординировано. Если эти условия соблюдены, значит время на тестирование потрачено с пользой.
— Вы создаете документацию для ручного тестирования или занимаетесь исследовательским тестированием?
Хун: Мы занимаемся исследовательским тестированием и создаем документацию. Ручные тест-кейсы документируются в двух случаях. Первый — если один и тот же сценарий использования повторяется в каждой сборке или входит во все серии тестов. Мы записываем их и заносим в базу тестов GTCM, чтобы любой внутренний или внешний тестировщик мог их использовать. Второй случай — документирование рекомендаций по тестированию для отдельных фич. Каждая фича обладает собственными уникальными свойствами. Тестировщики записывают их как рекомендации для коллег, которые могут работать с этой фичей в следующей сборке. Итак, у нас есть документация двух видов: описание общих сценариев и рекомендации по конкретным фичам.
— Расскажи нам о своих требованиях к разработчикам. Ты требуешь от них спецификаций? Заставляешь применять TDD? Как насчет юнит-тестов?
Хун: Наверное, где-то есть сказочный мир, в котором каждой строке кода предшествует тест, а ему — спецификация. Не знаю, может, такой мир и существует. Но в стремительном современном мире, в котором я живу, приходится работать с тем, что имеешь. Есть спецификация? Отлично! Большое спасибо, пригодится! Давайте будем реалистами: нам нужно искать пути, как работать в существующей системе.
Если вы требуете спецификацию, это не значит, что вы ее получите. Если вы настаиваете на юнит-тестах, это еще не значит, что они принесут пользу. Ни написание спецификации, ни создание юнит-теста не поможет вам найти проблему, с которой столкнется реальный пользователь (кроме обнаружения очевидного регрессионного бага). Это законы моего мира — мира тестировщиков. Вы работаете с тем, что дано, и выжимаете из этого максимальную пользу для продукта и команды.
По моему опыту, у всех инженеров благие намерения. Никто не хочет создавать продукт с багами. Но инновации нельзя точно спланировать. Графики и конкурентное давление существуют независимо от моих жалоб на качество. Я могу жаловаться, а могу заниматься полезным делом. Предпочитаю второй вариант.
Я живу в мире, где каждый день выходят сотни изменений. Да, я сказал каждый день. Талантливым, прогрессивным разработчикам нужно столько же талантливых, прогрессивных тестировщиков. Для требований и капризов нет времени — только польза.
— Хун, мы рады, что ты на нашей стороне! А теперь блиц-опрос. Если бы тебе дали лишний день для тестирования выпуска Android, что бы ты сделал?
Хун: Если бы у меня был лишний день, я бы сделал еще одну сборку! Нет такого понятия — лишний день!
— Туше! Тебе есть о чем жалеть? Есть баг, который пробрался через канал выпуска к пользователю?
Хун: Прежде всего, такое может произойти с каждым тестировщиком на планете. Ни одна компания не выпускает продукт, полностью лишенный багов. Такова природа вещей. Но для меня все такие случаи были болезненными.
— Нет, ты так легко не отвертишься! Назови хотя бы один!
Хун: Ладно, был у нас баг с активными обоями (Active Wallpaper) несколько выпусков назад. Иногда при запуске обоев все просто падало. Решение было простым, а мы выдали его так быстро, что пользователь почти ничего не заметил. Но это нас не оправдывает. Мы написали тесты для этого случая, поверьте мне, мы их написали!
Данный текст является ознакомительным фрагментом.