Уиттакер . - Как тестируют в Google
Общий доступ к тестовым данным, тест-кейсам и инфраструктуре компенсирует отход от секретности и эксклюзивности. Закрытые проприетарные тестовые инфраструктуры на самом деле означают всего лишь дорогостоящие, медленно работающие продукты, которые, скорее всего, нельзя повторно использовать даже в рамках одной компании. Тестировщики будущего будут стараться использовать совместно как можно больше кода, тестов и информации о багах, полученных от сообщества. Появятся новые формы краудсорс-тестирования и создания тестов, и добрая воля пользователей перевесит надуманные преимущества от приватности всего.
Более открытый, облачный подход к тестированию сэкономит компаниям средства, даст разработчикам тестовых инфраструктур больше прозрачности и, что самое важное, позволит разработчикам тестов сосредоточиться на тестовом покрытии своих проектов, а не на инфраструктуре. Циклы выпуска ускорятся, и качество продуктов вырастет.
В завершение
Тестированию, которое мы знаем и любим, приходит конец. Кого-то эта новость огорчит. Тем, чья карьера зависит от текущей схемы работы, придется намного сложнее. Так или иначе, разработка программного обеспечения фундаментально изменилась с приходом гибких методов, непрерывной сборки, раннего вовлечения пользователей, краудсорсинг-тестирования и онлайн-распространения приложений. Держаться за стандарты десятилетней давности — значит обрекать себя на отставание.
Этот переход уже происходит в 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. Можно распределить их среди тестировщиков с разным оборудованием.
