Как тестируют в Google - Уиттакер Джеймс, Арбон Джейсон, Каролло Джефф (2014)
-
Год:2014
-
Название:Как тестируют в Google
-
Автор:
-
Жанр:
-
Оригинал:Английский
-
Язык:Русский
-
Перевел:Матвеев Е. В.
-
Издательство:Издательский дом "Питер
-
Страниц:43
-
ISBN:978-5-496-00893-8
-
Рейтинг:
-
Ваша оценка:
. Книга создана для профессионалов в индустрии разработки: программистов, менеджеров, специалистов по тестированию.
Как тестируют в Google - Уиттакер Джеймс, Арбон Джейсон, Каролло Джефф читать онлайн бесплатно полную версию книги
Проектам типа Gmail или Chrome суждено пройти через много версий. Над ними будут трудиться сотни разработчиков. Представим, что разработчик присоединился к команде на третьей версии продукта. Если этот продукт хорошо задокументирован и пригоден к тестированию, если у него есть стабильный работоспособный механизм автоматизации тестов, если есть процессы, по которым легко добавить новый код, – считайте, что те ранние разработчики в тестировании сработали хорошо.
Со всем этим постоянным наращиванием функциональности, выпуском новых версий и патчей, переименованием и переработкой бывает трудно понять, когда работа над продуктом завершается. Но совершенно точно у каждого продукта есть четкая отправная точка. Здесь, в начале, мы формируем свои цели, планируем и пробуем. Мы даже пытаемся документировать то, что, как мы думаем, мы будем делать. Мы стремимся принимать такие решения, которые будут жизнеспособны в долгосрочной перспективе.
Чем больше экспериментов, прикидок и набросков планов мы сделали до начала реализации проекта, тем сильнее наша уверенность в долгой и успешной жизни проекта. Но надо знать меру. С одной стороны, мы не хотим планировать настолько мало, что потом это нам аукнется. С другой стороны, не хочется потратить несколько недель только на то, чтобы в конце понять, что условия изменились или оказались совсем не такими, какими их представляли. Поэтому на ранней фазе разумно вести документацию и структурировать процессы, но объем этой работы определяют сами инженеры из команды проекта.
Сначала в команде разработки нового продукта появляется ведущий инженер и еще несколько других технических ролей. В Google неформальное звание «ведущий инженер» получает специалист, который отвечает за выбор технического направления работ, координирует проект и становится его главным техническим представителем для других команд. Он знает ответы на все вопросы о проекте или может перенаправить их правильному человеку. Ведущим инженером продукта обычно становится разработчик или любой другой инженер, который выступает в роли разработчика.
Ведущий инженер со своей командой начинает с набросков первого проектного документа (об этом мы расскажем в следующем разделе). Постепенно документ растет, а это значит, что пора привлекать инженеров разных специализаций. Многие команды просят разработчика в тестировании еще на старте, несмотря на то что их мало.
Проектная документация
У каждого проекта в Google есть основной проектный документ. Это живой документ, он развивается вместе с проектом. Вначале этот документ описывает цель проекта, предпосылки его создания, предполагаемый список участников и архитектурных решений. На раннем этапе участники команды вместе дополняют этот документ. В больших проектах может понадобиться создать более мелкие проектные документы для основных подсистем. К концу этой стадии набор проектных документов должен стать основой для плана всех будущих работ. Документ могут помочь проанализировать ведущие инженеры других команд из предметной области проекта. Когда все дополнения и замечания собраны, фаза проектирования завершается и официально начинается стадия реализации.