Джеймс Уиттакер - Как тестируют в Google

Весь этот прогресс имел вирусную природу, мы шли снизу, по горизонтали, от сотрудника к сотруднику. Какие-то команды приходилось уговаривать, другие уже приходили к нам сами.

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

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

К моменту написания этой книги к нам продолжают присоединяться наставники, в программу вступают новые команды, и тест-сертификация прочно укрепилась в компании.

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

Трэйси: Самым важным изменением стало увеличение числа уровней и пересмотр требований. Сначала у нас было четыре уровня. Перейти с нулевого уровня на первый было легче легкого, мы сделали это намеренно. А вот переход с первого уровня на второй вызывал у большинства трудности, особенно у команд с нетестируемым кодом, доставшимся по наследству. Такие команды быстро перегорали и подумывали бросить программу. Поэтому мы добавили новый уровень между первым и вторым для облегчения перехода. Мы хотели назвать его «Уровень 1,5», но потом решили просто вставить новый уровень и перенумеровать весь список.

Некоторые требования были слишком общими — предписываемое ими соотношение малых/средних/больших тестов не подходило всем командам. Добавив новый уровень, мы обновили эти критерии: удалили отношения размеров тестов, но включили показатели инкрементального покрытия.

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

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

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

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

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

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

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