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

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

---

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

Более открытый, облачный подход к тестированию сэкономит компаниям средства, даст разработчикам тестовых инфраструктур больше прозрачности и, что самое важное, позволит разработчикам тестов сосредоточиться на тестовом покрытии своих проектов, а не на инфраструктуре. Циклы выпуска ускорятся, и качество продуктов вырастет.

В завершение

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

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

75 В Google есть программа подготовки инженеров по эксплуатационной надежности (SRE, Service Reliability Engineer), которая называется Mission Control. Разработчик, прошедший шестимесячную программу в роли SRE, получал приличную премию и кожаную куртку с эмблемой Google Mission Control.

76 Пост в тестовом блоге Google по поводу Native Driver: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html

Приложение А. Тест-план для Chrome OS

Статус: черновик

Контакт: [email protected]

Автор: [email protected]

Обзор тем

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

— Автоматизация тестирования оборудования. Учитывая разнообразие оборудования и непрерывную сборку ОС, важно прогонять тесты для каждой сборки по всей матрице оборудования. Так мы быстро выявим регрессии и сможем диагностировать место возникновения проблемы, будь то код приложения, железо или конфигурация среды. Например, тест может падать только на оборудовании HP в браузере сборки Х при определенных настройках беспроводной связи.

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

— Открытые инструменты и тесты. Chromium OS — платформа с открытым кодом. К тому же есть определенные требования от производителей оборудования. Поэтому команда тестирования должна убедиться, что все инструменты и тесты могут быть открыты наружу и использоваться за пределами Google.

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

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

— Тестируемость и сотрудничество. Тестируемость всегда была камнем преткновения, особенно для команд Google apps, внешних разработчиков, да и внутри компании. Тестировщики скооперируются с командами Android и Webdriver, чтобы повысить тестируемость и полноценно поддерживать браузер Chrome в Chrome OS. Это увеличит производительность автоматизации тестирования в командах Google apps. Так Chrome будет постепенно становиться идеальной платформой для тестирования любых приложений со сторонними веб-страницами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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