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

Уиттакер Джеймс

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

Сначала в команде разработки нового продукта появляется ведущий инженер и еще несколько других

технических ролей. В Google неформальное звание «ведущий инженер» получает специалист, который отвечает за выбор технического направления работ, координирует проект и становится его главным техническим представителем для других команд. Он знает ответы на все вопросы о проекте или может перенаправить их правильному человеку. Ведущим инженером продукта обычно становится разработчик или любой другой инженер, который выступает в роли разработчика.

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

Проектная документация

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

Очень хорошо, если разработчики в тестировании присоединяются к проекту на раннем этапе. Тогда они сделают важную работу, которая заметно повлияет на результаты. Если они правильно разыграют карты, то упростят жизнь участников проекта, ускорив ход работы. У разработчиков в тестировании есть очень важное преимущество в команде: по сравнению с другими инженерами они обладают самым широким представлением о продукте. Хороший разработчик в тестировании добавляет свою ценность к работе узкоспециализированных разработчиков и влияет на весь проект в целом, а не просто пишет код. Не разработчики, а именно разработчики в тестировании обычно выявляют общие схемы для повторного использования кода и взаимодействия компонентов. Оставшаяся часть этого раздела как раз и рассказывает о том, какую ценную работу могут выполнять разработчики в тестировании на ранней стадии проекта.

На заметку

Цель разработчика в тестировании на ранней стадии — упростить жизнь других участников проекта, ускорив выполнение работы.

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

— Разработчик в тестировании должен знать структуру тестируемой системы, и чтение

проектной документации в этом помогает. Так что рецензирование полезно как разработчику в тестировании, так и разработчику.

— Чем раньше внесено предложение, тем больше вероятность, что оно попадет в документ, а потом и в код. Так разработчика в тестировании сможет сильнее повлиять на проект.

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

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

Проектную документацию нужно рецензировать целенаправленно и вдумчиво, а не бегло просматривать, как утреннюю газету. Хороший разработчик в тестировании, оценивая документ, преследует четкие цели. Вот что советуем мы:

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

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

— Согласованность. Убедитесь в том, что текст соответствует диаграммам. Проследите, чтобы документ не противоречил утверждениям, сделанным в других документах.

— Архитектура. Проанализируйте архитектуру, предложенную в документе. Можно ли ее реализовать с доступными ресурсами? Какая инфраструктура будет использоваться? Прочитайте описание этой инфраструктуры и изучите ее подводные камни. Можем ли мы поддерживать предложенную инфраструктуру в нашей системе? Архитектура не слишком сложная? Можно ее упростить? Не слишком ли она проста? Что еще нужно учесть при работе с этой архитектурой?

— Интерфейсы и протоколы. Четко ли в документе определены будущие протоколы? Полностью ли описаны интерфейсы и протоколы, которые будет предоставлять продукт? Соответствуют ли эти интерфейсы и протоколы своим целям? Соответствуют ли они стандартам продуктов Google? Можно ли рекомендовать разработчику пойти дальше и начать писать protobuf-файлы (эту концепцию мы опишем дальше)?

— Тестирование. Насколько тестопригодна система, описанная в документе? Нужно ли будет встраивать в код новые зацепки для тестирования? Если да, проследите за тем, чтобы это добавили в документацию. Можно ли скорректировать структуру системы для упрощения тестирования или использования готовой тестовой инфраструктуры? Оцените, что нужно сделать для тестирования системы, и договоритесь с разработчиками, чтобы эту информацию добавили.

На заметку

Рецензировать проектные документы нужно вдумчиво и целенаправленно, а не бегло. Рецензирование преследует четкие цели.

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