Книга «Как тестируют в Google» — бесплатная электронная версия
Привет, Хаброжители!
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием.
Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.
Отрывок. Снижение рисков
Редко удается полностью устранить риски. Мы водим машину, хоть это и опасно, но ведь нужно добираться до работы? Вообще возможность несчастного случая не означает, что он обязательно произойдет, да и, скорее всего, ничего страшного не случится. Почему? Потому что своими действиями мы снижаем возможный риск. Например, не садимся за руль в нетрезвом состоянии и не водим в условиях недостаточной видимости. Таким образом мы снижаем риски.
В разработке программного продукта самое простое — избегать рискованных областей: чем меньше кода, тем меньше риск. Но кроме использования «топора и секиры», мы можем сделать еще много чего, чтобы снизить риски:
- Мы можем проработать пользовательские истории вокруг наиболее рискованных возможностей, определить самые безопасные пути и показать их разработчикам, чтобы те ввели в приложение больше ограничений.
- Мы можем написать регрессионные тест-кейсы, чтобы убедиться, что мы отловим повторные сбои.
- Мы можем написать и запустить тесты, подтверждающие необходимость добавить механизм восстановления и отката.
- Мы можем добавить средства контроля и сторожевой код для оперативного обнаружения сбоев.
- Мы можем добавить инструменты, которые будут отслеживать изменения в поведении продукта в его разных версиях. Мы получим сигнал, если возникнет регрессионный баг.
В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.
Опасения по поводу рисков со временем спадают, а большой объем успешно проведенного тестирования — это хороший признак того, что риски на приемлемом уровне. Здесь мы выигрываем от того, что связываем тест-кейсы с отдельными возможностями продукта, а затем и с атрибутами и компонентами в таблице рисков. Для этого дела идеально подходит «ACC — анализ», и вот почему мы создали этот инструмент именно таким.
Тест-план за десять минут по рецепту Джеймса Уиттакера
Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, — тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз — «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.
Стоит ли такая работа усилий — это уже совсем другая история. Я вижу десятки тест-планов, которые пишут мои команды, и каждый раз это мертворожденные документы — они создаются, рецензируются, обновляются один или два раза (если повезет), а потом уверенно откладываются в долгий ящик, как только проект начинает идти не так, как это было предусмотрено. Возникает вопрос: если план не стоит того, чтобы его обновлять, стоило ли
его создавать?
Иногда тест-план нежизнеспособен потому, что содержит слишком много или, наоборот, слишком мало подробностей. Или он способствовал началу работы, а вот процессу — уже нет. И снова вопрос знатокам: стоило ли создавать документ с ограниченной или постоянно уменьшающейся ценностью?
Некоторые тест-планы содержат настолько очевидную информацию, что ее и документировать-то не стоило. Мы просто зря тратим время. Давайте посмотрим правде в глаза: у нас проблема с тест-планами.
Чтобы справиться с этим, я придумал для своей команды простое задание: написать тест-план за десять минут. Если уж он и имеет какую-то ценность, то давайте доберемся до нее как можно скорее.
Когда у вас есть всего десять минут для решения задачи, каждая секунда становится значимой. В этом моя основная идея: ограничение во времени заставляет отсекать при планировании всю шелуху и концентрироваться только на важных моментах. Делайте только то, что абсолютно необходимо, оставьте подробности исполнителям тестов. Я хотел покончить с порочной
практикой написания нежизнеспособных тест-планов, и это упражнение показалось мне верным.
Однако я ничего этого я не говорил участникам эксперимента. Я просто сказал: «Вот приложение, составьте тест-план не более чем за десять минут». Имейте в виду, что эти люди получали зарплату за то, что они выполняли мои задачи. И все же я предполагал, что они испытывали ко мне определенное уважение, а следовательно, знали, что я не поручу им невыполнимую задачу.
Они могли потратить некоторое время на знакомство с приложением, но, так как речь шла о приложениях, которые они используют каждую неделю (Google Docs, App Engine, Talk Video и т. д.), я дал им совсем немного времени на это.
Во всех случаях команды изобретали методы, схожие с методами ACC-анализа. Они оформляли решения в форме таблиц и списков, не используя большие объемы текста. То есть предложениям — да, абзацам текста — нет. Они не тратили время на форматирование текста, не вдавались в излишние объяснения. У всех тест-планов было одно общее — команды документировали возможности. Они признали, что это было лучшим решением, куда потратить весьма ограниченное время.
О’кей, ни одна команда не завершила тест-план вовремя. Тем не менее они успели за десять минут пройтись по атрибутам и компонентам и начали вычленять возможности исследуемого продукта. К концу дополнительных двадцати минут большинство моих подопытных записали довольно большой набор возможностей, который мог бы служить отличной отправной точкой
при создании тест-кейсов и пользовательских историй.
Мне кажется, что эксперимент удался. Я выделил им десять минут, хотя ориентировался на час. В итоге за полчаса было выполнено 80% работы. Разве этого недостаточно? Мы точно знаем, что не будем тестировать все, ну и зачем нам все документировать? Мы отлично знаем, что в ходе тестирования многие вещи (графики, требования, архитектура) будут изменяться. Настаивать на скрупулезной точности планирования, когда завершенность вовсе не требуется, не имеет смысла.
Восемьдесят процентов работы выполнено за тридцать минут или даже меньше. Вот это я называю десятиминутным тест-планом!
Напоследок о рисках
Google Test Analytics берет за основу описанные выше критерии оценки рисков («очень редко», «редко», «иногда», «часто»). Мы специально не хотим превращать анализ рисков в сложную задачу, иначе она не будет выполнена. Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимания на точное значение рисков. Простое знание, какая возможность рискованнее другой, позволит тест-менеджеру более эффективно распределять работу тестировщиков. А такие люди, как Патрик Коупленд, смогут легко решать, сколько тестировщиков нужно назначить в каждую команду разработки. Понимание рисков приносит пользу на уровне всей компании.
Анализ рисков — это самостоятельная научная область, уважаемая во многих отраслях. Мы используем упрощенную версию методологии, но это не мешает нам интересоваться новыми исследованиями, чтобы улучшить свой подход к тестированию. Если вы хотите узнать больше об анализе рисков, то начните со статьи «Управление рисками» в Википедии.
GTA помогает обозначить риски, а тестирование помогает их снизить. Тестировщик служит посредником в этом процессе. Он может выполнить внутренние тесты по некоторым наиболее рискованным направлениям или поставить задачу разработчикам и разработчикам в тестировании, чтобы они добавили регрессионные тесты. В его арсенале есть и другие инструменты: исследовательское тестирование, привлечение внутренних и бета-пользователей и силы внешнего сообщества.
В ответственности тестировщика знать все подверженные рискам области. Он должен стараться снизить риски любыми способами, которые ему подвластны. Вот несколько рекомендаций, которые мы считаем полезными в борьбе с рисками.
- Для самых рискованных возможностей и пар «атрибут/компонент», отмеченных красным, напишите набор пользовательских историй, сценариев использования или руководство по тестированию. В Google ответственность за наиболее рискованные возможности лежит на тестировщике. Он может координировать свою работу с коллегами, использовать разные инструменты, но личная ответственность все равно на нем.
- Внимательно изучите все то, что делалось по тестированию разработчиками и разработчиками в тестировании до вас. Как результаты повлияли на риски, выявленные с помощью GTA? Хорошо ли это тестирование было организовано с точки зрения управления рисками? Стоит ли добавить новые тесты? Тестировщику может понадобиться дописать эти тесты самому или обратиться к разработчикам. В конечном счете важно, чтобы тесты были написаны, а не кто именно их напишет.
- Проанализируйте баги, обнаруженные у каждой пары атрибут/компонент высокого риска, и убедитесь в том, что соответствующие регрессионные тесты написаны для каждого из них. Баги имеют свойство возвращаться при изменении кода.
- Будьте внимательнее к областям высокого риска — поинтересуйтесь механизмами восстановления и отката. Учтите возможное негативное влияние на пользователя, когда он столкнется с наихудшим сценарием. Обсудите такие ситуации с другими инженерами, проверьте реалистичность этих сценариев. К тестировщику, который часто кричит: «Волк!», вскоре перестанут прислушиваться. Громкие предупреждения о вероятных опасностях допустимы только в отношении сценариев с высоким риском, которые к тому же признаны реалистичными и уже были покрыты тестами.
- Вовлекайте в работу как можно больше людей, заинтересованных в успешности проекта. Внутренних пользователей следует тормошить на тему обратной связи, иначе они будут просто использовать систему, игнорируя те или иные ошибки. Просите их проводить конкретные эксперименты, задавайте им вопросы типа «А как это работает на вашей машине?» или «Как бы вы использовали такую фичу?». Сотрудники Google много участвуют в тестировании, и их нужно активно направлять именно тестировать, а не просто пользоваться продуктами.
- Если ни один из механизмов не работает, а подверженный риску компонент так и недотестирован, да еще и постоянно падает, постарайтесь добиться удаления элемента. Поздравляем! Вам выпал шанс объяснить руководству концепцию анализа рисков и подчеркнуть важность тестировщиков на проекте.
Пользовательские сценарии
Пользовательские истории описывают реальные или смоделированные способы, которыми пользователи используют приложение. Они описывают, чего хотят пользователи, смотрят на продукт их глазами, не учитывая архитектуру приложения и детали реализации.
Истории могут быть связаны с возможностями, но лишь поверхностно, поскольку все-таки подчинены действиям пользователя. Пользователю что-то нужно, а история описывает, как он использует приложение, чтобы это получить. Истории намеренно описаны в общем виде, без конкретных шагов, без жестко заданных входных данных. Только то, что будет делать пользователь, и как это воспроизвести во время тестирования приложения.
Создавая пользовательскую историю, мы смотрим на продукт только через пользовательский интерфейс, мы не включаем в описание технические подробности. Тогда тестировщик будет каждый раз проходить этот путь по-разному, как и разные пользователи по-разному решают одну и ту же задачу в нашем приложении — вот в чем главная идея!
Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.
Мы стараемся, чтобы тестировщики, исполняя такие сценарии, менялись. Чем больше разных способов прохождения — тем лучше.
Мы не будем слишком придираться к возможностям с низкими рисками. Мы можем решить, что писать тест-кейсы для этих областей — слишком затратное занятие. Вместо этого мы можем ограничиться исследовательским тестированием или оставить на откуп краудсорс-тестированию. Чтобы управлять работой тестировщиков из внешнего сообщества, мы часто пользуемся концепцией туров — это высокоуровневые инструкции для исследовательского тестирования. Проще говоря, такой подход дает вашему запросу нужную конкретику. Например, попросив сообщество: «Проведите FedEx-тур для такого-то набора возможностей», — мы получим намного лучший результат, чем просто отдав приложение и понадеявшись на лучшее. Мы сразу определяем фичи, которые нужно протестировать, и даем инструкции, как это делать.
Краудсорсинг
Краудсорсинг— это новое явление в тестировании. Если тестировщиков не хватает, а их ресурсы ограничены, то краудсорс-тестирование спешит на помощь! Пользователей с разными наборами устройств и программных конфигураций намного больше, чем тестировщиков. О таком количестве тестовых окружений нам остается только мечтать. Наверняка ведь найдутся желающие помочь нам?
Представим, что есть группа опытных пользователей, которые разбираются в тестировании и согласились нам помочь за разумную плату. Все, что им нужно, — это доступ к среде, где они могут работать с приложением, и отлаженный механизм предоставления обратной связи и баг-репортов. Для таких проектов, как наш опенсорсный Chromium, тестирование при помощи большой группы людей подходит идеально. Однако для проектов, открытых только внутри компании, это более проблематично. Нужно отбирать тестировщиков, пользующихся особым доверием.
Еще одна ключевая ценность краудсорсинга (кроме множества конфигураций) — это более широкий взгляд на приложение. Вместо того чтобы один тестировщик имитировал действия тысячи пользователей, у нас есть тысяча пользователей, работающих как тестировщики. Есть ли лучший способ найти сценарии, приводящие приложение к сбою, чем сразу выдать эти сценарии пользователям и получить обратную связь? Разнообразие и масштаб — вот в чем ценность краудсорсинга.
Людей, желающих протестировать программный продукт, в избытке, и доступны они круглосуточно. Допустим, дано: топ-1000 сайтов, задача: протестировать их в последней версии Chrome, тогда решение: 1 тестировщик = 1000 итераций или 20 тестировщиков = 50 итераций. Математика на стороне краудсорсинга.
Главный недостаток тестирования сообществом в том, что им нужно время, чтобы разобраться с приложением и понять, с какой стороны лучше подойти к тестированию. Большая часть этого времени теряется впустую изза количества людей, но мы придумали, как с этим справляться. Для Chrome, например, мы написали туры, и внешние тестировщики следовали им при исследовательском тестировании и при выполнении пользовательских сценариев (примеры есть в приложении Б «Туры тестов для Chrome»). Туры сразу направляли тестировщиков к нужным частям приложения и давали необходимые инструкции. Фокус в том, чтобы сделать разные наборы туров и распределить их между участниками. Так мы избежали варианта «принеси то, не знаю что» и получили именно то, о чем просили.
Краудсорс-тестирование — это следующий этап развития стандартных каналов Google: канареечного канала, канала разработки, тестового канала и канала внутреннего продукта. Это наш способ привлечения ранних пользователей и людей, которым просто нравится искать баги и сообщать о них. Мы уже попробовали набирать тестировщиков внутри компании среди наших коллег, которые любят работать со свежим продуктом, подключать к командам людей из компаний поставщиков, пользоваться услугами коммерческих компаний краудсорсинга (например, uTest). Мы даже запустили программу поощрения лучших искателей багов.
Итак, сила ACC-анализа в том, что мы получаем список возможностей продукта, который можно упорядочить по риску и закрепить за разными исполнителями. Тестировщики, работающие над одним проектом, могут получить разные наборы возможностей для проверки. Внутренние пользователи, «двадцатипроцентные» участники, тестировщики-подрядчики, тестировщики из сообщества, разработчики, разработчики в тестировании — все получат свои списки возможностей, и, к радости тестировщика, важные области будут покрыты с меньшим перекрытием, чем если бы мы просто раздали приложение для тестирования всем желающим.
Работа тестировщика, в отличие от работы разработчика в тестировании, с впуском продукта не заканчивается.
Как тестируют в google
Спрятать опции
Установить закладку
+ Настройки
Размер шрифта:
14 | 16 | 18 | 20 | 22 | 24
Ширина текста:
50% | 60% | 70% | 80% | 90% | 100%
Цвет текста:
Установить
Цвет фона:
Установить
Сбросить настройки
Предисловие к русскому изданию
Вступление от Альберто Савоя
Вступление от Патрика Коупленда
Предисловие
Об иллюстрациях
Пара слов о книге
Благодарности
Глава 1. Первое знакомство с организацией тестирования в Google
Качество ≠ Тестирование
Организационная структура
Ползти, идти, бежать
Виды тестов
Глава 2. Разработчик в тестировании
Жизнь разработчика в тестировании
Как организованы процессы разработки и тестирования
Кто такие разработчики в тестировании на самом деле?
Ранняя стадия проекта
Структура команды
Проектная документация
Интерфейсы и протоколы
Планирование автоматизации
Тестируемость
Как появились очереди на отправку и непрерывная сборка
Джефф Карролло
Пример работы разработчика в тестировании
Выполнение тестов
Определения размеров тестов
Как мы используем размеры тестов в общей инфраструктуре
Преимущества разных размеров тестов
Требования к выполнению тестов
Тестирование на скоростях и в масштабах Google
Пуджа Гупта, Марк Айви и Джон Пеникс
Тест-сертификация
Как мы собеседуем на позицию разработчиков в тестировании
Глава 3. Кто такой инженер по тестированию
Тестирование, обращенное к пользователю
Инженер по тестированию
Планирование тестирования
Снижение рисков
Напоследок о рисках
Пользовательские сценарии
Джейсон Арбон
Краудсорсинг
Джеймс Уиттакер
Пишем тест-кейсы
Интересные факты из жизни багов
Немного подробнее о Buganizer
Жизненный путь бага
Джеймс Уиттакер
Как мы нанимаем инженеров по тестированию
Как отличить тестировщика от разработчика в тестировании
Джейсон Арбон
Собеседование с инженерами по тестированию
Управление тестированием в Google
Управление «пиратским кораблем» для чайников
Джеймс Арбон
Тестирование в режиме сопровождения
Пример режима сопровождения: Google Desktop
Джейсон Арбон
Эксперимент с Quality Bots
Сингулярность: [54] легенда о происхождении ботов
Джейсон Арбон
Bots: детство, отрочество и масштабирование на весь интернет
Теджас Шах
Эксперимент BITE
Google Test Analytics
Бесплатное тестирование
Инновации и эксперименты в тестировании
Джеймс Арбон
Внешние тестировщики
Интервью с инженером по тестированию Google Docs Линдси Уэбстер
Интервью с инженером по тестированию YouTube Эппл Чоу
Глава 4. Тест-менеджер
Кто такой тест-менеджер
Жонглирование людьми и дирижирование проектами
Интервью с Анкитом Мехтой, тест-менеджером Gmail
Интервью с Хуном Даном, тест-менеджером Android
Интервью с Джоэлом Хиноски, тест-менеджером Chrome
Директор по тестированию
Интервью с Шелтоном Маром, директором по тестированию проектов Search и Geo
Интервью с директором разработки инженерных инструментов Ашишем Кумаром
Интервью с Суджаем Сани, директором по тестированию в индийском Google
Интервью с тест-менеджером Брэдом Грином
Интервью с Джеймсом Уиттакером
Глава 5. Как мы улучшали тестирование в Google
Роковые ошибки в процессе тестирования Google
Будущее разработчика в тестировании
Куда движется роль инженера по тестированию
Что станет с тест-директором и тест-менеджером
Будущее инфраструктуры тестирования
В завершение
Приложение А. Тест-план для Chrome OS
Анализ рисков
Непрерывное тестирование каждой сборки
Ежедневное тестирование лучших сборок
Тестирование перед выпуском
Ручное и автоматизированное тестирование
Разработка и качество тестов
Каналы выпуска
Обратная связь
Репозитории тест-кейсов
Панели мониторинга тестов
Виртуализация
Производительность
Нагрузочное тестирование, продолжительное тестирование и тестирование стабильности
Как тестируют в Google
Было интересно прочитать эту книгу с точки зрения профессионального интереса. Все же хочется знать, а как же там? Как там тестируют? Как там работает менеджмент? Что стоит в приоритете и какое направление задано? Книга интересная и познавательная. Но я бы сказала, что она скорее подойдет менеджерам проектов для понимания организации работы. Возможно для лидов по той же причине. Тут не будет указания куда лучше смотреть тестировщику, как набираться опыта или на что обращать больше внимания. Надо это просто принять и читать с другой целью. Советую ее всем, кто интересуется организацией процессов и думает куда нужно стремиться и что искать в компаниях!
28 февраля 2019 г. 14:43
Книга в большей степени напоминает мемуары, но читать интересно. Она могла бы быть обязательной к прочтению тестировщикам из Гугла, но думаю для остальных компаний будет полезным допчтением тимлидам и менеджерам. Читала книгу с позиции специалиста по тестированию и для себя отмечу наиболее заинтересовавшие вещи: — примеры собеседований с разборами — планирование тестирования (ACC-анализ) — приложения тест-планов и тест-туров для Chrome
alt=»EsslingerLifelessly» width=»100%» height=»100%» /> EsslingerLifelessly EsslingerLifelessly написал рецензию
2 января 2018 г. 11:59
Книга выходного дня.
Книга прежде всего менеджерская и маркетинговая.
Менеджерская потому что рассматриваются именно организационные подходы к процессу тестирования на примере авторского опыта в проекте Google Chrome. В основном обсуждаются особенности организации web-тестирования.Приводится иерархия задействованных специалистов и их роли, комментируются особенности корпоративных подходов к разработке и планированию тестирования.
Мало внимания уделяется инфраструктуре корпоративного программного окружения, задействованного в тестировании и разработке.
А маркетинговая эта книга потому что, на мой взгляд, нескромно рекламирует и идеализирует корпорацию и её продукты.
alt=»ELiashkovich» width=»100%» height=»100%» /> ELiashkovich
15 октября 2017 г. 21:05
Когда-то в Google работало лишь три тестировщика, а само тестирование считалось чем-то необязательным. Поначалу это не сказывалось на продуктивности небольшой компании, однако с увеличением масштабов пошло и увеличение количества багов. Джеймс Уиттакер и Патрик Коупленд — парни, которые первыми распознали угрозу такой ситуации для имиджа Google и фактически с нуля выстроили самую совершенную тестовую инфраструктуру планеты.
Вот об этом, если коротко, в книге и рассказывается. Введение и первая глава объясняют, зачем вообще тестирование нужно и кто им должен заниматься. Отдельно несколько раз проговаривается тезис о том, что тестировать продукт должна вся команда, в первую очередь — сами разработчики.
Потом авторы рассказывают нам о том, что такого специалиста как «тестировщик» в Google,…
14 июня 2016 г. 16:36
Это не книга по тестированию для тестировщиков. Это пособие по организации работа отдела тестирования с упором на автоматизацию, рекомендации по набору людей в такие команды и еще 1000 мелочей, которые играют роль для тимлидов и менеджеров проектов. Если ваше дело — писать автотесты, тест-кейсы и тест-планы, ничего нового вы не узнаете (как протестировать поле ввода с кнопкой? Ребята, к вам серьезно регулярно приходили собеседоваться чуваки, которые не слышали про граничные значения?! Вы шутите что ли. ). Ну, кроме того, что Гугл не мог не выпендрится и не переименовать общие обозначения на свои. Привет очередная путаница в классификации. А, ну и да, количества поглаживаний друзьям, коллегам, отцам-основателям, начальству и всему Гуглу тут больше чем на пяти церемониях Оскара…
alt=»LynxJunior» width=»100%» height=»100%» /> LynxJunior
19 апреля 2016 г. 18:39
Так как же в Google тестируют ПО? Единственное, что можно сказать после этой книги: увлечённо! И если это действительно так, то можно только порадоваться за сотрудников (да и пользователей) Google. Вот только явные баги всё так же доходят до конечных юзеров, Chrome всё так же ненасытен в отношении оперативной памяти, а проекты у них всё так же закрываются.
Книга будет полезна с менеджерской точки зрения: узнать, как распределяются обязанности в одной из самых успешных компаний мира, как в ней строятся отношения между командами и отдельными сотрудниками. Что в принципе входит в обязанности разработчиков в тестировании (это они так автоматизаторов называют?), инженеров в тестировании, тест-менеджеров и директоров по тестированию. Кстати, мне кажется, что именно интервью удались лучше…
alt=»russischergeist» width=»100%» height=»100%» /> russischergeist
13 сентября 2014 г. 19:21
Последние 7 лет своей профессиональной деятельности я посвятил тестированию программного обеспечения. Как известно, имеется не так много книг на русском языке посвященной данной тематике. Увидев эту книгу, мне стало интересно выяснить, отличаются ли методы тестирования компании Google от общеизвестной практики инжиниринга ПО. Теперь я смог ответить на этот вопрос.
Читая эту книгу, я сначала получал ответы на совсем другие вопросы. Например, Почему некоторые «продвинутые» специалисты в разработке ПО зарабатывают миллионы, а другие — нет? Какие такие особенные обязанности имеет специалист по тестированию ПО, если он зарабатывает, например 300 000 долларов в год?
В одном блоге я прочитал вот такую поучительную историю, резюмирующую мои представления об организации программного инжиниринга в…
Как тестируют в google
Дж. Уиттакер, Дж. Арбон, Дж. Каролло
Как тестируют в Google
Всем тестировщикам из Google, Microsoft и всех остальных компаний, которые заставили меня мыслить нестандартно.
Моей жене Хизер и моим детям Луке, Матео, Данте и Одессе, которые думали, что я все это время работал в Starbucks.
Маме, папе, Лорен и Алексу.
Предисловие к русскому изданию
Я пришла в тестирование в 2006 году маленьким тестировщиком на большой аутсорсный проект. Сначала я научилась тестировать, заводить баги и общаться с разработчиками и менеджерами. Со временем я стала писать тесты, научилась планировать и управлять тестированием. У меня появилась своя команда.
И чем дальше, тем больше мне становилось понятно, что тестировщики только находят проблемы, но не могут их исправить. Они не могут сделать так, чтобы проблема больше не повторилась. И я чувствовала, что тестирование может приносить больше пользы.
Я начала ездить на конференции, читала книги и статьи по тестированию, общалась с коллегами по индустрии. Везде учили, как лучше тестировать, как находить больше ошибок, как быстрее находить ошибки. Тестировщики не хотели выходить за рамки своей профессии. Им как будто нравилось чувствовать собственную важность от того, что они нашли много багов.
Ответы на свои вопросы я нашла в статьях и докладах Джеймса Уиттакера. Его основная идея в том, что тестирование должно перестать просто предоставлять информацию и начать влиять на качество. Главная задача тестирования, говорил Уиттакер, — это уменьшение количества ошибок в процессах разработки. Тогда улучшится качество выпускаемого продукта.
Создать процесс, в котором сложно допустить ошибку, — вот настоящая цель тестирования. Мы не можем полностью избавиться от ошибок, но можем построить работу так, что сделать сразу правильно будет легче, чем ошибиться.
В Google пошли именно в эту сторону, отказавшись от тестирования, которое просто сообщало об ошибках. «Служба тестирования» трансформировалась в «Направление продуктивности разработки», которое помогает разработчикам и менеджерам делать меньше ошибок и получать обратную связь как можно раньше. Тестировщики в Google влияют на качество, потому что встраивают его на всех этапах разработки программных продуктов.
Книга «Как тестируют в Google» рассказывает, как тестировщики в Google пришли к пониманию, что нужно меняться, как строили новые процессы, каких результатов достигли и как видят дальнейшее развитие тестирования. Очень здорово, что компания Google настолько открыта и делится своим опытом. Но все же, я думаю, что именно приход Уиттакера в Google послужил катализатором процесса написания этой книги. Слишком уж много у него энергии и желания делиться знаниями с внешним миром.
Я начала переписываться с Уиттакером в 2009 году, а в марте 2010-го познакомилась с ним лично на конференции Swiss Testing Day. Он оказался очень простым в общении. С ним можно было обсудить тренды мирового тестирования и посмеяться над тестировщиками-консерваторами. Джеймс очень остроумный и харизматичный оратор. В 2011-м я слушала его мастер-класс «Как тестируют в Google» на конференции EuroSTAR. Он легко парировал реплики из зала вроде «в авиационном софте не получится сделать так, как в Google» простой фразой «так вы даже не пробовали».
Эта книга повторяет легкий и остроумный стиль общения Джеймса. Вы почувствуете характер Уиттакера, читая ее. Мы очень старались сохранить в переводе эту легкость и живость. Я хотела, чтобы текст получился таким, как будто его написал кто-то очень знакомый: наш коллега, который говорит на том же языке, что и мы. В итоге книга получилась не похожей на большинство технических книг на русском языке, переведенных сухо и формально.
Если вы начинающий тестировщик — прочитайте книгу сейчас, а потом еще раз через год. Если вы опытный тестировщик — дайте ее почитать вашим разработчикам и менеджерам. Если они не загорятся идеей сделать тестирование «как в Google», задумайтесь, стоит ли с ними работать. Если вы менеджер или разработчик — прочитайте и сравните с тем, как работает тестирование в вашей компании.
Пожалуйста, будьте осторожны. Не нужно следовать советам ребят из Google вслепую: то, как у них реализованы процессы, лишь частный случай. Вычлените из книги главное: тестирование как выделенная проверка не работает, тестировать должен каждый участник проекта, качество нужно встраивать на все уровни разработки. Если применить эти принципы в вашей компании, скорее всего, вы получите совершенно другую реализацию.