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


Авторские права

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

Здесь можно скачать бесплатно "Джеймс Уиттакер - Как тестируют в Google" в формате fb2, epub, txt, doc, pdf. Жанр: Программирование, издательство Издательский дом "Питер", год 2014. Так же Вы можете читать книгу онлайн без регистрации и SMS на сайте LibFox.Ru (ЛибФокс) или прочесть описание и ознакомиться с отзывами.
Джеймс Уиттакер - Как тестируют в Google
Рейтинг:
Название:
Как тестируют в Google
Издательство:
Издательский дом "Питер"
Год:
2014
ISBN:
978-5-496-00893-8
Скачать:

99Пожалуйста дождитесь своей очереди, идёт подготовка вашей ссылки для скачивания...

Скачивание начинается... Если скачивание не началось автоматически, пожалуйста нажмите на эту ссылку.

Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.

Как получить книгу?
Оплатили, но не знаете что делать дальше? Инструкция.

Описание книги "Как тестируют в Google"

Описание и краткое содержание "Как тестируют в Google" читать бесплатно онлайн.



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






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

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

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

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

Chrome OS — яркий пример такого подхода. На этом проекте все трое авторов этой книги работали больше года. Но задолго до того, как мы официально присоединились к работе, несколько разработчиков создали прототип. Он состоял в основном из скриптов и заглушек, но зато позволял продемонстрировать идею «чисто браузерного» приложения руководству Google, чтобы официально утвердить проект. На стадии прототипа команда концентрировалась на экспериментах и хотела доказать, что этот концепт вообще жизнеспособен. Тратить время на тестирование — или даже проектировать с оглядкой на тестируемость — было бы неразумным, особенно учитывая, что проект был еще неофициальным, а все демо­сценарии в будущем все равно заменили бы реальным кодом. Когда сценарии выполнили свое предназначение и продукт был утвержден, руководитель разработки обратился к нам за помощью в тестировании.

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

На заметку

Ни один проект не получит ресурсы тестирования просто так. Команды разработки обращаются к тестировщикам за помощью, убеждая их в том, что проект по-настоящему интересен и перспективен. 

Структура команды

Разработчики часто глубоко погружены в код, который пишут, и сосредоточены на одной фиче продукта или даже ее части. Они принимают все решения исходя из локальной пользы, воспринимая продукт очень узко. Хороший разработчик в тестировании должен делать ровно наоборот: смотреть на продукт широко и держать в голове общую картину продукта, со всеми его фичами. Более того, он должен понимать, что разработчики приходят, делают свою работу и уходят, а продукт должен продолжать жить дальше.

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

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

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

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

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

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

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

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

На заметку

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

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


На Facebook В Твиттере В Instagram В Одноклассниках Мы Вконтакте
Подписывайтесь на наши страницы в социальных сетях.
Будьте в курсе последних книжных новинок, комментируйте, обсуждайте. Мы ждём Вас!

Похожие книги на "Как тестируют в Google"

Книги похожие на "Как тестируют в Google" читать онлайн или скачать бесплатно полные версии.


Понравилась книга? Оставьте Ваш комментарий, поделитесь впечатлениями или расскажите друзьям

Все книги автора Джеймс Уиттакер

Джеймс Уиттакер - все книги автора в одном месте на сайте онлайн библиотеки LibFox.

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Отзывы о "Джеймс Уиттакер - Как тестируют в Google"

Отзывы читателей о книге "Как тестируют в Google", комментарии и мнения людей о произведении.

А что Вы думаете о книге? Оставьте Ваш отзыв.