Джеймс Уиттакер - Как тестируют в Google
— Менеджеры в Google имеют много подчиненных, но и сами обязаны вносить технический вклад в проект. Как ты совмещаешь эти занятия? Можешь ли рассказать нам о своей инженерной работе?
Анкит: Обилие подчиненных и время, которое тратится на координацию работы команд, сильно отвлекает. Чтобы сохранить техническую квалификацию и остаться инженером, я сделал две вещи.
Во-первых, я свел команды разработчиков и разработчиков в тестировании вместе. Работы там достаточно для всех, и я смог стащить кусочек для себя. Я занимался проектом с фазы проектирования и работал в нем достаточно, чтобы самостоятельно писать тесты.
Во-вторых, и это ключевая штука, если вы собираетесь заниматься технической работой, нужно абстрагироваться от всех отвлекающих факторов руководства. Сначала я просто выделял пару дней в неделю для самостоятельной работы. Взглянуть на тестирование глазами разработчика мне помогла работа по интеграции Google Feedback в Gmail. Каждый раз, когда я сталкивался с ненадежным тестом или неудобной частью тестовой инфраструктуры, я понимал, как наша работа выглядит для разработчиков. И все же, находясь в центральном офисе Google, полностью абстрагироваться от управленческой работы я не мог, поэтому я перебрался к команде Gmail в Цюрихе. Находясь в девяти часовых поясах от постоянного места работы, там, где я не являюсь начальником, я сумел влиться в инженерную команду и сделать очень много полезного!
— Можешь порекомендовать, как правильно комплектовать команду? Сколько должно быть разработчиков и тестировщиков? Как насчет соотношения разработчиков в тестировании и инженеров по тестированию?
Анкит: Главное правило найма — никаких компромиссов. Нанять неподходящего человека всегда хуже, чем подождать идеального кандидата. Нанимайте только лучших, и точка. Google не освещает соотношения инженеров в команде, но скажу, что раньше на нашем проекте тестировщиков было больше нормы. Решив первоочередные проблемы, мы увеличили долю участия разработчиков и вернулись к средним по Google показателям. Для Gmail хорошо сработал следующий вариант: 20% тестировщиков занимались исследовательским тестированием. Любой продукт, в котором взаимодействие с пользователем на первом месте, должен проходить исследовательское тестирование. Еще 30% составляли инженеры по тестированию, которые были сильнее сконцентрированы на продукте, они работали рука об руку с разработчиками в тестировании и обеспечивали максимальный результат их работы. Оставшиеся 50% составляли разработчики в тестировании, работающие над автоматизацией, добавлением инструментов для поддержания кодовой базы в рабочем состоянии и улучшением производительности разработчиков. Не знаю, буду ли применять такую разбивку ролей в следующем проекте Google, но для Gmail она сработала хорошо.
— Мы знаем, что тебе поручено тестирование Google+. Какие ценные уроки тестирования Gmail помогут тебе в работе с новым продуктом?
Анкит: Не стоит тратить все силы на проработку клиентской части. Gmail имеет, пожалуй, самую большую серверную часть, в которой было немало вкусных задач для тестирования. Кроме этого, были и другие полезные уроки:
— Пишите тесты на том же языке, на котором написано приложение.
— Человек, написавший функцию, должен быть ответственным за выполнение тестов для нее. Проигнорированные тесты выйдут вам боком.
— Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
— Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.
— Мы все-таки в Google, а здесь важна скорость, ее ждут от нас пользователи. Убедитесь, что продукт работает быстро. Выделите это, если вам нужно доказать это остальным.
— Сотрудничество с разработчиками совершенно необходимо. Если его не будет, тестирование станет простым сглаживанием дефектов, а это не самая лучшая работа.
Инновации — часть ДНК Google. Команда тестирования должна иметь ген инноваций в крови, каждый участник должен изобретать новейшие решения проблем.
— Есть ловушки, в которые попадают инженерные команды?
Анкит: Да. Они думают, будто знают, чего хотят пользователи, и могут серьезно изменять продукт или новые фичи, не проводя экспериментов. Зачем вам хорошая тестовая инфраструктура для фичи, которую выкинут за ненадобностью? Дайте нескольким пользователям новую версию, получите обратную связь, а уж потом вкладывайтесь в грандиозную автоматизацию тестов.
Пока вы будете долго строить идеальное решение, рынок оставит вас позади. Работайте короткими итерациями, двигайтесь небольшими шагами, но двигайтесь!
Наконец, нужно найти идеальный момент для тестирования. Напишете тесты слишком рано — архитектура изменится, и вся работа коту под хвост. Затянете — вам придется переносить выпуск из-за нехватки качественного тестирования. TDD вам в помощь!
— А что же про конкретных людей? Ты заметил какие-нибудь типичные ошибки молодых инженеров по тестированию и разработчиков в тестировании?
Анкит: Ошибка новичков — отчаянно бросаться в работу. Они неистово пишут тесты, не обдумывая их назначение и место в общем процессе тестирования. Они не всегда понимают, что нужно брать ответственность за тесты, которые они приручили. То есть написали. Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков. Разработчики в тестировании должны помнить, что тестировать код — задача разработчика, а их задача — ввести тестирование в рабочий процесс разработчика. Мы создаем условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации.
Ошибка инженеров в тестировании в том, что они начинают вести себя как разработчики в тестировании. Мы же хотим, чтобы инженер по тестированию действовал глобально, контролировал весь продукт. Он должен смотреть на тесты с точки зрения пользователя, помогал обеспечивать эффективное использование всей тестовой инфраструктуры. Инструменты и средства диагностики, которые используют тестировщики, должны влиять на весь продукт.
— Какие еще успехи в области тестирования принесли пользу Gmail?
Анкит: Автоматизация JavaScript. Мы встроили сервлет автоматизации прямо в Gmail, и разработчики смогли писать сквозные тесты на том же языке, на котором была написана клиентская часть. Разработчики легко освоились с написанием тестов, потому что в них использовались те же методы и библиотеки — не пришлось тратить время на изучение. Стало просто писать тесты и определять, не нарушает ли новая возможность работу Gmail, и тем самым защищать старые фичи. Каждая функция Gmail теперь выпускается по меньшей мере с одним тестом, написанным с помощью этого сервлета. Кстати, сейчас я использую такую технологию в своей новой работе над Social. У нас уже более 20 тысяч автоматизированных тестов!
Еще одно достижение — нагрузочное тестирование. В Google без него никак, потому что все наши приложения интенсивно используются, а дата-центры сильно загружены. По сути, мы должны смоделировать типичную нагрузку с нашим обычным трафиком. Мы потратили месяцы на анализ реального использования приложений, чтобы построить модель поведения пользователей. Затем мы сделали модель более реальной, проведя тестирование нагрузки на таких же компьютерах, на каких работают дата-центры. Параллельно были запущены две серии тестов: экспериментальная и контрольная. Мы наблюдали за ними, чтобы найти различия. Мы обнаружили много регрессий и передали их в руки разработчиков.
Наконец, наша ориентация на предотвращение багов (вместо их выявления) принесла плоды. Мы на ранней стадии включили автоматизированные тесты в процесс, предшествующий выпуску, и предотвратили попадание в сборку некачественного кода. Благодаря этому команда тестирования продолжает опережать ожидания и работает над сборками такого высокого качества, что нашим исследовательским тестировщикам есть над чем потрудиться.
— Итак, ты набил руку и теперь переходишь в социальные сервисы. На что ты будешь обращать внимание при найме участников в эту команду тестирования?
Анкит: Я хочу найти людей, которые не боятся сложностей. Тех, кто, сталкиваясь с большой проблемой, сможет разбить ее на конкретные шаги и, конечно, справится со всеми! Мне нужны люди, которые от жестких сроков не впадают в панику, а начинают действовать более эффективно. В моей команде должны быть люди, которые держат баланс между инновациями и качеством, чьи идеи выходят за рамки поиска багов. Кроме всего, я хочу видеть энтузиазм. Мне нужны люди, которые искренне хотят быть тестировщиками.
