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

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

Команды разработчиков испытывали сильное давление. Google начал покупать компании со своими веб-приложениями (YouTube, Google Docs и прочие), которые только усиливали нагрузку на нашу внутреннюю инфраструктуру. Проблемы, с которыми я сталкивался в тестировании, не уступали проблемам, с которыми сталкивались разработчики при написании кода. Я пытался решить проблему тестирования, которую просто невозможно было решить отдельно от разработки. Рассматривать тестирование и разработку как обособленные дисциплины или даже как разнородные задачи было в корне неверно, и мы не могли решить ни одну из проблем. Улучшение команды тестирования стало бы всего лишь временным успехом.

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

Наша концепция «Тест-сертификации» делала успехи (вы прочитаете про нее дальше в книге). Мы общались с командами разработчиков и помогали улучшить чистоту кода и внедрить юнит-тестирование на ранней стадии. Мы разрабатывали инструменты и обучали команды основам непрерывной интеграции, чтобы наши продукты всегда были готовы к тестированию. Бесчисленные мелкие усовершенствования и приемы, многие из которых описаны в книге, развеяли скептицизм. Тем не менее чего-то не хватало. Разработка все еще была разработкой, а тестирование так и оставалось тестированием. Все ингредиенты для изменения культуры присутствовали, но нам был нужен катализатор, который смог бы запустить объединение дисциплин.

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

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

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