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

Тест-сертификация начиналась как соревнование. Будут ли разработчики серьезно относиться к тестированию, если мы сделаем эту работу престижной? Что, если награждать разработчиков, которые следуют тестовым практикам? А что, если мы скажем, что они теперь сертифицированные инженеры? А может, еще ввести систему наградных бейджей (рис. 2.12), которыми можно пощеголять перед коллегами?

Рис. 2.12. Бейджи тест-сертификации показываются на вики-страницах проектов

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

Краткое описание уровней Тест-сертификации

Уровень 1

— Создать пакеты тестового покрытия.

— Установить систему непрерывной сборки.

— Ранжировать тесты на малые, средние и большие.

— Определить недетерминированные тесты.

— Создать набор смоук-тестов.

Уровень 2

— Не выпускать, пока не пройдут все тесты.

— Обязательно выполнять смоук-тесты до отправки кода.

— Инкрементальное покрытие всеми тестами не меньше 50%.

— Инкрементальное покрытие малыми тестами не меньше 10%.

— Хотя бы одна фича покрыта интеграционным тестом.

Уровень 3

— Создавать тесты для всех нетривиальных изменений

— Общее покрытие малыми тестами не меньше 50%.

— Важные новые фичи покрыты интеграционными тестами.

Уровень 4

— Смоук-тесты запускаются автоматически перед отправкой нового кода.

— Смоук-тесты проходят за время меньше 30 минут.

— Нет недетерминированных тестов.

— Общее тестовое покрытие не меньше 40%.

— Тестовое покрытие только малыми тестами не меньше 25%.

— Все важные фичи покрыты интеграционными тестами.

Уровень 5

— Добавить тест к исправлению всех нетривиальных багов.

— Активно использовать доступные средства анализа.

— Общее тестовое покрытие не меньше 60%.

— Тестовое покрытие только малыми тестами не меньше 40%.

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

Продать нашу идею оказалось не так сложно, как казалось. Команды разработки только выигрывали от этого:

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

— Они получали помощь экспертов и учились лучше писать малые тесты.

— Они видели, какие команды лучше проводят тестирование, и понимали, у кого стоило учиться.

— Они могли похвастаться перед другими командами своим уровнем тест-сертификации.

Вся компания могла следить, как команды разработки зарабатывают уровни.

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

Интервью с основателями программы тест-сертификации

Марк Стрибек — руководитель разработки Gmail. Нил Норвиц — разработчик, занимающийся инструментами ускорения разработки. Трэйси Бялик и Расс Руфер — разработчики в тестировании, одни из лучших инженеров Google. Эти четверо помогали запустить программу тест-сертификации.

Расскажите, с чего началась тест-сертификация? Какие проблемы коман­да пыталась решить при запуске? Совпадают ли они с теми, которые вы решаете сегодня?