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

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

На заметку

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

Статус временно выделяемых на проект тестировщиков упрощает их перемещение по проектам. Они не только сохраняют свежий взгляд и остаются в курсе дел, но и быстро распространяют удачные идеи по компании. Прием или инструмент тестирования, который хорошо сработал в продукте направления Geo, скорее всего, пойдет в работу снова, когда этот тестировщик перейдет на Chrome. Нет более быстрого способа распространения инноваций, чем перемещение самих новаторов.

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

Ползти, идти, бежать

Одна из ключевых причин, почему Google успешен даже с маленьким количеством тестировщиков, в том, что мы редко пытаемся сразу поставить большой набор фич. Как раз наоборот. Мы строим минимально жизнеспособный продукт и выпускаем его в тот момент, когда он может стать полезным как можно большему количеству людей, получаем обратную связь и дальше развиваем продукт итеративно. Так мы действовали с Gmail, у которого ярлык «бета-версии» сохранялся четыре года. Мы предупреждали пользователей, что продукт все еще дорабатывается. Ярлык «бета-версии» мы убрали, только когда достигли поставленной цели в 99,99% нормальной работоспособности почты. По той же схеме мы работали с Android при выпуске G1 — продукта, получившего хорошие отзывы. Он был улучшен и обогащен новыми фичами, когда выходил для линейки телефонов Nexus. Важно помнить, что ранняя версия, за которую платят пользователи, должна быть достаточно функциональной и полезной для них. То, что версия является ранней, еще не означает, что она должна быть слабым продуктом.

На заметку

Google часто выпускает «минимально полезный продукт» как исходную версию и собирает обратную связь от внутренних и внешних пользователей. А потом быстро выдает обновления, тщательно анализируя качество на каждом этапе. Прежде чем попасть к пользователям, продукты проходят через разные каналы: канареечный, разработки, тестирования, бета- и выпуска.

Это не такое уж жульничество, как может показаться на первый взгляд. Чтобы дойти до состояния канала бета-версии, продукту надо пройти через ряд других каналов и доказать свою ценность. Для Chrome — продукта, над которым я работал первые два года в Google, — мы использовали разные каналы в зависимости от нашей уверенности в качестве продукта и от объема отзывов, который нам был нужен. Последовательность примерно такая.

— Канареечный канал: используется для ежедневных сборок, которые, на наш взгляд, еще не готовы для выпуска. Помните канареек, с которыми спускались в шахты для обнаружения токсичного газа? Если ежедневная сборка оказывается нежизнеспособной (канарейка умирает, если есть хоть небольшая примесь газа в воздухе), это свидетельствует о том, что процесс разболтался и работу надо пересмотреть. Канареечные версии подходят только для самых преданных пользователей, которые экспериментируют с продуктом. Они не для тех, кто использует приложение для реальной работы. Как правило, сборки из канареечного канала используют только инженеры (разработчики и тестировщики) и менеджеры, работающие над продуктом.

На заметку

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