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

• Название: Как тестируют в Google
• Автор: Джеймс Уиттакер
• Издательство: Издательский дом "Питер"
• Жанр: Программирование
• Год: 2014
• ISBN: 978-5-496-00893-8

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

---

Анализ рисков

Команда тестирования выполнит анализ рисков, чтобы:

— убедиться, что вся команда понимает риски качества продукта;

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

— выработать набор правил для оценки новых рисков на основании новых данных, которые будут поступать в ходе развития продукта.

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

В итоге мы должны знать, какие риски есть в продукте и какие из доступных ресурсов мы можем использовать для их методичного сокращения.

Непрерывное тестирование каждой сборки

Кроме юнит-тестов с использованием Buildbots, для каждой непрерывной сборки должны выполняться следующие тесты:

— смоук-тесты (автоматизация фич и багов с приоритетом P0);

— тесты производительности.

Ежедневное тестирование лучших сборок

Лучшая сборка дня будет проходить через следующее тестирование:

— ручная проверка набора функциональных приемочных тестов (можно ограничиться одним видом оборудования в день);

— автоматизированное функциональное регрессионное тестирование;

— система непрерывного тестирования популярных веб-приложений подхватывает лучшую сборку и прогоняет на ней свои тесты (не только автоматизированные, здесь может проводиться и ручное тестирование).

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

Непрерывно проводится ручное исследовательское тестирование и тестовые туры.

Автоматизируются тесты AutoUpdate.

Тестирование перед выпуском

Тестируется каждый «релиз-кандидат» сборки, для всех каналов.

— Совместимость с сайтами. Команда тестирования браузера Chrome проверяет 100 самых популярных сайтов на Chrome OS.

— Тестирование сценариев. Проверка всех демосценариев Chrome OS, которые часто показывают партнерам и на конференциях (может быть ограничено максимум двумя-тремя сценариями).

— Проверка багов с приоритетом P0. Проверка всех исправленных багов P0. Проверка 80% багов P1, заведенных с момента последнего выпуска.

— Полная серия тестов на нагрузку и стабильность. Проведение нагрузочного тестирования и тестирования стабильности.

— Ручные тест-кейсы Chrome OS. Выполняются все ручные тест-кейсы Chrome OS. Можно распределить их среди тестировщиков с разным оборудованием.

Ручное и автоматизированное тестирование

Ручное тестирование необходимо. Оно особенно важно на ранней стадии проекта, когда пользовательский интерфейс и другие фичи уже быстро развиваются, а работа по улучшению тестируемости и автоматизации только началась. Chrome OS делает ставку на простоту и интуитивную понятность своего интерфейса, поэтому ручное тестирование проводить обязательно. Машины до сих пор не умеют это тестировать.

Автоматизация — залог долгосрочного успеха и результативности тестовой команды и защита от регрессионных багов. Так как автоматизация встроена в браузер, бо́льшая часть ручных тестов (да здравствует продуктивность!) тоже автоматизируется.

Разработка и качество тестов

Команда разработчиков больше других групп по количеству людей и обладает гораздо большим знанием о компонентах и технических подробностях списков изменений. Мы хотим, чтобы разработчики обеспечивали полный набор модульных и узконаправленных системных тестов с помощью Autotest.

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

Каналы выпуска

Мы должны использовать тот же подход, который команда браузера Chrome успешно применяла в своем проекте: разделить пользователей на группы по их терпимости к ошибкам и готовности предоставить обратную связь и запустить для них разные каналы. В итоге мы получим ряд каналов с разными уровнями уверенности в качестве. Работа с аудиторией будет вестись импульсно, по необходимости, а не постоянно, что позволит нам уменьшить наши затраты. Мы сможем экспериментировать с реальным использованием продукта до крупномасштабного запуска и снизим риск всего продукта.

Обратная связь

Отзывы пользователей очень важны для проекта. Нужно вложиться в то, чтобы им было предельно просто отправить нам обратную связь. И не забыть о том, что нам нужно будет обрабатывать данные.

— Расширение GoogleFeedback. Чтобы отправить сообщение, пользователи могут легко выделить и отправить ошибку для любого URL-адреса. Расширение группирует полученные от пользователей данные и выводит их на информационную панель для анализа. Команда тестирования приложит усилия, чтобы GoogleFeedback был интегрирован в Chrome OS, и расширит его отчетность на ChromeUX.

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

Команда тестирования будет настойчиво продвигать настройку такой системы, в том числе и для нестандартных конфигураций.

Репозитории тест-кейсов

— Ручные: все ручные тест-кейсы хранятся в TestScribe. Идет работа над созданием репозитория тест-кейсов для code.google.com.

— Автоматизированные: все автоматизированные тест-кейсы находятся в хранилище кода в формате Autotest. Все тесты версионизированы, доступны и располагаются рядом с тестируемым кодом.

Панели мониторинга тестов

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

Виртуализация

Очень важно, особенно на ранней стадии, вложиться в виртуализацию образов Chrome OS. Это уменьшит зависимость от физического оборудования, поможет проводить регрессионное тестирование с помощью Selenium и WebDriver на целых фермах серверов и облегчит поддержку тестирования и разработки Chrome OS прямо на рабочих машинах инженеров.

Производительность

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

Нагрузочное тестирование, продолжительное тестирование и тестирование стабильности

Команда тестирования создает и выполняет продолжительные тесты на физическом оборудовании в лаборатории. Не забыть про внедрение неисправностей (fault injection).

Фреймворк выполнения тестов Autotest

Команды тестирования и разработки решили использовать Autotest как основной фреймворк для автоматизации тестов. Autotest удачно прошел проверку в сообществе Linux, использовался в нескольких внутренних проектах, и, кроме того, он распространяется с открытым кодом. Autotest поддерживает локальное и распределенное выполнение. Этот фреймворк умеет подключать и другие оснастки функционального тестирования (например, WebDriver), так что у нас будет единый интерфейс для выполнения, распределения тестов и отчетности.