Читать онлайн «Как тестируют в Google». Страница 21

Марк: Пришлось искать команды, которые были бы достаточно заинтересованными и не имели особых проблем со старым кодом. В них должен был быть хотя бы один человек, который хотел заниматься тестированием и ориентировался в теме. Это были три основных препятствия, и мы последовательно преодолевали их, команда за командой.

— Как тест-сертификация стала популярной? Рост был вирусный или линейный?

Расс: Сначала мы прогнали пилотную версию на командах, которые дружили с тестированием, и на тех, кто помогал организовать программу. Мы тщательно выбирали свою аудиторию — привлекали команды с самыми высокими шансами на успех.

Когда мы объявили глобальный запуск тестовой сертификации в середине 2007 года, в Google уже было 15 пилотных команд, находящихся на разных уровнях. Перед запуском мы обклеили стены всех наших зданий в Маунтин-Вью плакатами «Что скрывает тест-сертификация». На плакатах были фотографии команд и внутренние названия проектов (Rubix, Bounty, Mondrian, Red Tape и т.д.). Мы сделали провокационные надписи типа «Будущее начинается сегодня» и «Это важно, не отставай» со ссылкой на программу. Мы получили огромное количество посещений от любопытствующих, которые хотели раскрыть тайну или подтвердить свои догадки. Мы задействовали «туалетное тестирование», чтобы прорекламировать программу и рассказать людям, где они могут узнать больше о проекте.

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

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

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

Через несколько месяцев, когда в нашей программе уже участвовало порядка 50 команд, несколько смелых представителей от разработки записались в наставники. Это стало началом партнерства между инженерами из команд разработки продуктов и специалистами направления продуктивности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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