Обзор тем
— Риски. В 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. Можно распределить их среди тестировщиков с разным оборудованием.
Ручное и автоматизированное тестирование
Ручное тестирование необходимо. Оно особенно важно на ранней стадии проекта, когда пользовательский интерфейс и другие фичи уже быстро развиваются, а работа по улучшению тестируемости и автоматизации только началась. 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), так что у нас будет единый интерфейс для выполнения, распределения тестов и отчетности.
Хотим отметить, что основная команда разработки инструментов тестирования работает над поддержкой Autotest в Windows и Mac.
Производители железа
Производители железа играют важную роль в проверке качества сборок Chrome OS. Команды тестирования и разработки создают релевантные ручные и автоматизированные тест-кейсы, при помощи которых производители проверяют сборки и оборудование на своей стороне. Кроме них команда тестирования сотрудничает с самыми популярными производителями и включает разные варианты железа в повседневное тестирование. Так мы сможем как можно раньше выявлять любые проблемы или регрессии, связанные с ним.
Лаборатория проверки оборудования
В лаборатории собрано много нетбуков и других устройств, на которых можно регулировать сетевые настройки (для проводного и беспроводного соединений), управлять питанием и т.д. Это инфраструктура для тестирования отдельных сервисов (например, беспроводной связи). Лабораторные машины в основном управляются инфраструктурой HIVE.
Фермы для сквозных автотестов
Команда тестирования создаст ферму нетбуков для прогона тестов и настроит передачу данных о состоянии матрицы аппаратных и программных средств. Фермы распределяются по офисам в Маунтин-Вью, Киркленде и Хайдарабаде для возможности локального доступа к лаборатории и организации практически круглосуточного выполнения тестов и отладки.
Тестирование AppManager в браузере
Основной браузер Chrome OS — это Linux-версия Chrome с пользовательским интерфейсом и фичами, специализированными для Chrome OS. Бо́льшая часть механизмов отображения страниц и функциональности такая же, однако есть значительные различия между базовым браузером и его разновидностью в Chrome OS. Например, закрепляемые вкладки, менеджер загрузки, запуск приложений, платформенные элементы управления, беспроводная связь и т.д.
— Chrome OS — главная платформа для основного тестирования браузера Chrome (ручного и автоматизированного).
— Команда разработки браузера определяет сборку, которую нужно интегрировать, на основании качества сборки и текущих фич Chrome OS.
— Для каждой «релиз-кандидат» версии OS команда браузера проводит стандартный набор тестов совместимости сайтов/приложений (топ-300 сайтов) с Chrome OS.
— Тесты совместимости сайтов/приложений частично автоматизируются с помощью WebDriver и интегрируются в автозапуски при сборках или в обычные лабораторные запуски, чтобы рано получать информацию о серьезных регрессиях, специфических для Chrome OS.
— Команда внешних тестировщиков создает и выполняет пакет ручных тестов для фич Chrome OS, связанных с браузером и менеджером приложений.
— Как только API будет реализован, внешние тестировщики автоматизируют пакет ручных тестов Chrome OS.
— Chrome OS Chromebot должен иметь версии для Linux и Chrome OS и запускаться на всей функциональности Chrome OS, а не только веб-приложений.
— Ручное исследовательское тестирование и туры помогут выявить пользовательские проблемы, связанные с функциональностью, удобством, простотой использования и т.д.
Тестируемость браузера
Именно через браузер пользователь оперирует основными элементами интерфейса и использует фичи Chrome OS. Бо́льшая часть компонентов BrowserUX либо не подходит для тестирования, либо может тестироваться только через низкоуровневые интерфейсы IPC AutomationProxy за пределами браузера. Для Chrome OS мы унифицируем тестирование веб-приложений, пользовательского интерфейса Chrome и функциональности. Мы стараемся избавиться от низкоуровневых системных тестов. Мы хотим, чтобы Chrome стал самым удобным браузером для тестирования веб-приложений, чтобы внешние команды веб-разработки начинали тестирование своих проектов именно с него. Вот что мы делаем для этого:
— Портирование Selenium и WebDriver в Chrome OS. Это основные тестовые фреймворки для современных веб-приложений. Команды браузера Chrome и Chrome OS, скорее всего, возьмут на себя специфические для Chrome аспекты WebDriver. Это станет шагом к созданию надежного, удобно тестируемого интерфейса для разработчиков приложений и внешних тестировщиков.
— Доступ к пользовательскому интерфейсу и функциональности Chrome через JavaScript DOM. Это позволит тестам WebDriver работать с пользовательским интерфейсом и функциональными аспектами Chrome. Функциональность доступна через те же методы, что и отключение, и спящий режим, и через которые с ChromeViews работают специалисты по доступности для людей с ограниченными возможностями (например, raman@).
— Высокоуровневые сценарии. Сотрудничество с командой WebDriver для расширения основного API WebDriver сначала в «чистый» JavaScript, а потом в высокоуровневые скрипты записи и воспроизведения с параметрами (например, «Google Search: <критерий>»). Так мы ускорим внутреннюю и внешнюю разработку тестов, которые, работая с WebDriver, все еще требуют большой работы по поиску элементов и сложны в поддержке из-за быстрого изменения пользовательского интерфейса.
Оборудование
Chrome OS должен соответствовать требованиям многих производителей оборудования. Нужно тестировать на основных платформах производителей железа, чтобы обеспечить интеграцию между физическим оборудованием и Chrome OS. Мы создаем тесты, которые проверяют:
— управление питанием: циклы питания от сети и батареи, сбои, управление питанием аппаратных компонентов и т.д.;
— сбои оборудования: что Chrome OS сможет обнаружить и как произведет восстановление?
График
4-й квартал 2009 года:
— Определить ручные приемочные тесты, выполнять их для непрерывных сборок.
— Определить основные тесты проверки качества и выполнять их для каждого крупного релиза.
— Запустить аппаратную лабораторию.
— Провести анализ рисков.
— Автоматизировать выполнение сквозных сценариев для непрерывных сборок на нетбуках в лаборатории.
— Настроить поддержку Hive для визуализации данных на виртуальных и физических машинах.
— Портировать WebDriver и Selenium на Chrome OS.
— Автоматизировать некоторые тесты для популярных веб-приложений.
— Выбрать тестовую оснастку для разработчиков и тестировщиков.
— Запустить интеграцию Google Feedback в Chrome OS.
— Сформировать основную команду тестирования: люди и процессы.
— Автоматизировать тесты для аудио и видео.
— Полностью спланировать тестирование с учетом рисков.
— Спланировать ручное тестирование пользовательского интерфейса.
1-й квартал 2010 года:
— Настроить панели мониторинга данных о качестве.
— Автоматизировать тесты автообновления.
— Настроить поддержку автоматизированного тестирования производительности в лаборатории.
— Настроить лаборатории в Хайдарабаде, Киркленде и Маунтин-Вью, к этому времени в них должно уже проводиться тестирование.
— Chromebot для Linux и Chrome OS.
— Обеспечить поддержку тестируемости для основных функций и пользовательского интерфейса Chrome OS.
— Создать набор функциональных регрессионных автоматизированных тестов для Chrome OS.
— Включить Chrome OS в регрессионные тесты веб-приложений для ферм Selenium.
— Создать прототип поддержки записи и воспроизведения для браузера и тестирования пользовательского интерфейса.
— Автоматизировать тест-кейсы ChromeSync E2E.
— Настроить тестирование стабильности и внедрения сбоев.
— Настроить тестирование сетевых компонентов.
— Проводить регулярное исследовательское ручное тестирование и туры (чтобы задобрить Джеймса).
2-й квартал 2010 года:
— Риски уже должны быть снижены из-за тестирования и автоматизации.
3-й квартал 2010 года:
— Риски должны быть снижены еще больше из-за тестирования и автоматизации.
4-й квартал 2010 года:
— Все риски минимизированы, работа автоматизирована, новых проблем нет, пользовательский интерфейс и функциональность остаются неизменными. Команда тестирования завершает работу.
Ключевые моменты тестирования
— Ведущий инженер по тестированию для платформы Chrome OS.
— Ведущий инженер по тестированию для браузера Chrome.
— Ведущий инженер автоматизации браузера.
— Панель мониторинга статусов тестирования и метрик.
— Определение и выполнение ручных приемочных тестов.
— Определение и выполнение ручных регрессионных тестов командами внешних тестировщиков.
— Совместимость приложений, базовый пользовательский интерфейс и функциональность браузера (ручные тесты).
— Аудио и видео.
— Стабильность и внедрение сбоев.
— Тестирование доступности для пользователей с ограниченными возможностями.
— Аппаратные лаборатории: Киркленд, Хайдарабад и Маунтин-Вью.
— Автоматизация ферм.
— Приемка оборудования.
— Общее руководство и финансирование.
Необходимые документы и ресурсы
— Анализ рисков.
— Аппаратные лаборатории.
— Автоматизация ферм E2E.
— Инфраструктура управления виртуальными и физическими машинами.
— Инструменты для отображения служебной информации.
— Ручные приемочные тесты.
— Информационная панель с результатами тестирования.
— Тесты проверки железа для производителей.
— Сводная панель с информацией об использовании и работоспособности оборудования.
— План ручного функционального тестирования Chrome OS.