Читаем Как тестируют в Google полностью

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

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

— Совместимость с сайтами. Команда тестирования браузера 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. Все тесты версионизированы, доступны и располагаются рядом с тестируемым кодом.

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

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

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

Перейти на страницу:

Похожие книги

«Ага!» и его секреты
«Ага!» и его секреты

Вы бы не хотели, скажем, изобрести что-то или открыть новый физический закон, а то и сочинить поэму или написать концерт для фортепьяно с оркестром?Не плохо бы, верно? Только как это сделать? Говорят, Шиллер уверял, будто сочинять стихи ему помогает запах гнилых яблок. И потому, принимаясь за работу, всегда клал их в ящик письменного стола. А физик Гельмгольц поступал иначе. Разложив все мысленно по полочкам, он дожидался вечера и медленно поднимался на гору лесной дорогой. Во время такой прогулки приходило нужное решение.Словом, сколько умов, столько способов заставить мозг работать творчески. А нет ли каких-то строго научных правил? Одинаковы ли они для математиков, биологов, инженеров, поэтов, художников? Да и существуют ли такие приемы, или каждый должен полагаться на свои природные способности и капризы вдохновения?Это тем более важно знать, что теперь появились «электронные ньютоны» — машины, специальность которых делать открытия. Но их еще нужно учить.Решающее слово здесь принадлежит биологам: именно они должны давать рецепты инженерам. А биологи и сами знают о том, как мы думаем, далеко не все. Им предстоит еще активнее исследовать лабораторию нашего мышления.О том, как ведутся эти исследования, как постепенно «умнеют» машины, как они учатся и как их учат, — словом, о новой науке эвристике рассказывает эта книга.

Елена Викторовна Сапарина

Зарубежная компьютерная, околокомпьютерная литература