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

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

— Какие еще успехи в области тестирования принесли пользу Gmail?

Анкит: Автоматизация JavaScript. Мы встроили сервлет автоматизации прямо в Gmail, и разработчики смогли писать сквозные тесты на том же языке, на котором была написана клиентская часть. Разработчики легко освоились с написанием тестов, потому что в них использовались те же методы и библиотеки — не пришлось тратить время на изучение. Стало просто писать тесты и определять, не нарушает ли новая возможность работу Gmail, и тем самым защищать старые фичи. Каждая функция Gmail теперь выпускается по меньшей мере с одним тестом, написанным с помощью этого сервлета. Кстати, сейчас я использую такую технологию в своей новой работе над Social. У нас уже более 20 тысяч автоматизированных тестов!

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

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

— Итак, ты набил руку и теперь переходишь в социальные сервисы. На что ты будешь обращать внимание при найме участников в эту команду тестирования?

Анкит: Я хочу найти людей, которые не боятся сложностей. Тех, кто, сталкиваясь с большой проблемой, сможет разбить ее на конкретные шаги и, конечно, справится со всеми! Мне нужны люди, которые от жестких сроков не впадают в панику, а начинают действовать более эффективно. В моей команде должны быть люди, которые держат баланс между инновациями и качеством, чьи идеи выходят за рамки поиска багов. Кроме всего, я хочу видеть энтузиазм. Мне нужны люди, которые искренне хотят быть тестировщиками.

— Мы подходим к последнему вопросу. Почему ты выбрал тестирование?

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

Интервью с Хуном Даном, тест-менеджером Android

До того как Хун Дан был приглашен возглавить команду тестирования Android, он успел успешно поработать инженером в Apple и TiVo67.

Cтратегическую важность Android для Google трудно отрицать. Этот проект стал таким же хитом, как Search или Ads. Android получил особое внимание руководства и привлек первоклассных специалистов. Его кодовая база растет на глазах, и одна сборка может насчитывать сотни изменений в день. На базе этой операционной системы запускаются тысячи приложений, вокруг нее формируется сообщество разработчиков. Количество устройств, работающих на платформе Android, постоянно растет; она стоит на новых телефонах и планшетах множества производителей. В зоне ответственности Хуна и его команды все: от тестирования совместимости устройств и управления питанием до проверки работы приложений.

Мы встретились с Хуном, чтобы узнать, как организовано тестирование Android.

— Расскажи нам о том, как начиналось тестирование. Наверное, на первых порах, до появления смартфонов и многочисленных приложений, было проще?

Хун: К сожалению, нет. Когда я взял на себя руководство тестированием Android, команда только сформировалась и многие инженеры никогда не тестировали до этого операционные системы, не говоря уже о мобильных устройствах. Моей первой задачей было скоординировать работу команды и построить инфраструктуру тестирования. Я думаю, что начальная фаза проекта тестирования — самая трудная часть работы. Когда у тебя есть крепко сбитая команда и налаженная инфраструктура, то можно справиться с продуктом любой сложности. Тяжелее всего в планировании, зато потом легко в тестировании!

— Давай остановимся здесь, ведь множество менеджеров по тестированию бьются на ранних стадиях своих проектов прямо сейчас. Расскажи, что вы делали на ранней стадии проекта Android?

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

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

— Звучит впечатляюще. И как команда справлялась?

Хун: На самом деле я потерял около 80% старой команды. Зато оставшиеся стали техническими лидами. Они подавали пример и работали с новичками, которых мы привлекали в команду. Нет универсальных людей, которые вписываются во все проекты. В Google достаточно работы, и если кому-то не подошел Android, то, возможно, подойдет другой проект. В Google такое разнообразие и создает здоровую среду тестирования.

— Какие были приятные моменты тестирования?

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

— Это непросто, хотя по твоим словам этого и не скажешь! Расскажи нам более подробно об организации тестирования, о которой ты обмолвился. Ты коснулся процесса сообщения о багах, но, конечно, это не все. Как ты организуешь саму работу?

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