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

— Что даст команде участие в программе тест-сертификации сегодня? Каковы затраты на участие?

Трэйси: Право похвастаться. Четко описанные шаги. Помощь со стороны. Классный светящийся шар. Но настоящая польза — это улучшение тестирования.

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

— Есть ли на этих уровнях шаги, которые вызывают больше трудностей, чем другие?

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

— Многие проекты в Google живут всего несколько недель или месяцев, а ваша тест-сертификация на плаву почти пять лет и, похоже, ко дну идти не собирается. Что помогает ей так долго жить? Какие испытания ждут ее впереди?

Расс: Система живет, потому что ее поддерживает не несколько человек, она изменила всю культуру компании. Спасибо группе первых энтузиастов, «туалетному тестированию», рассылкам, техническим докладам, изменениям в гайдлайнах по написанию кода и в требованиях вакансий, — теперь от всех инженеров компании ждут регулярного тестирования. Участвует команда в тест-сертификации или нет, она должна хорошо продумать стратегию автоматизированного тестирования — либо самостоятельно, либо с помощью экспертов.

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

— Дайте советы инженерам из других компаний, которые собираются запустить подобные программы у себя.