Как тестируют в Google
Шрифт:
GTA использует четыре оценки частоты появления сбоев:
— Очень редко: трудно представить ситуацию, при которой возникнет проблема, но если такое случится, то ее решение будет простым.
Пример: страница загрузки браузера Google Chrome. [37] В основном содержимое этой страницы статично, автоматика там срабатывает только при определении клиентской ОС. Если произойдет сбой в базовом коде HTML или в сценарии на странице, то его быстро обнаружит мониторинг кода.
37
http://www.google.com/chrome
—
Пример: кнопка «Вперед» в Chrome. Эта кнопка используется, но гораздо реже, чем ее напарница кнопка «Назад». Так сложилось, что ее работа редко приводит к сбоям, а если такое все-таки случится, то проблема будет быстро перехвачена еще на этапе тестирования раннего выпуска нашими первыми пользователями.
— Иногда: такой сбой легко представить, хотя он и достаточно сложен технически, а возможность продукта, как мы считаем, будет популярна у пользователей.
Пример: Возможности Chrome Sync. Chrome синхронизирует закладки, темы, заполнение форм, историю просмотра страниц и другие данные пользователя между компьютерами. Есть много типов данных и платформ ОС, поэтому слияние изменений — задача непростая. Если произойдет сбой синхронизации данных, пользователь, вероятнее всего, это заметит. Синхронизация выполняется только в том случае, когда происходят изменения в синхронизируемых данных — например, пользователь добавил новую закладку.
Рис. 3.8. Оценка риска по частоте и воздействию в GTA для Google+
— Часто: если в возможности, которая входит в часто используемую фичу, регулярно происходят сбои.
Пример: отображение веб-страниц. Основная задача браузера — отобразить HTML, CSS и код JavaScript любого происхождения и качества. Даже если исходный загружаемый код будет технически неправильным, пользователь решит, что проблема в браузере. Риск сильно возрастает, если мы рассматриваем сайт с высоким уровнем трафика. Проблемы отображения не всегда могут быть обнаружены пользователем: визуально элемент может съехать, но тем не менее остается рабочим. Или он может исчезнуть совсем, но тогда как пользователь узнает, что он вообще был?
Итак, тестировщик выбирает одно из этих значений для каждой возможности. Мы специально сделали четыре варианта оценки, чтобы тестировщик не вздумал постоянно выбирать средний вариант. Здесь нужно серьезно подумать.
Для оценки воздействия мы используем такой же упрощенный метод, с таким же количеством вариантов (снова возьмем браузер Chrome для примера).
Воздействие может быть:
— Минимальным: сбой, который пользователь может не заметить.
Пример: есть такой дополнительный сервис Chrome Labs. Его функциональность необязательна для работы, и сбой при загрузке страницы chrome://labs затронет лишь нескольких пользователей. Эта страница содержит дополнительные, экспериментальные фичи Chrome, о которых большинство людей даже не знают. Сами фичи снабжены пометкой «Используйте на свой страх и риск». Проще говоря, компания не несет ответственности за сбои, но зато
— Небольшим: сбой, который может вызвать раздражение у пользователя. Если случается — механизмы повтора и восстановления легкодоступны.
Пример: нажмем на кнопку «Обновить». Если она не обновляет страницу, то можно заново ввести URL-адрес или открыть новую вкладку и попробовать ввести его там, а можно просто перезапустить браузер. Самые худшее в этой ситуации — раздражение пользователя.
— Существенным: сбой заблокирует выполнение пользовательских сценариев.
Пример: расширения Chrome. Если пользователь установил расширения в свой браузер, а в новой версии Chrome возник сбой при загрузке этих расширений, это провал.
— Максимальным: сбой нанесет удар по репутации продукта и заставит пользователей отказаться от работы с ним.
Пример: механизм автообновления Chrome. Если эта возможность отвалится, то браузер лишится важных обновлений безопасности или вовсе прекратит работать.
Иногда сбои приводят к разным последствиям у пользователя и компании. Допустим, перестал работать рекламный баннер. Проблема ли это для пользователя? Нет, он даже может не заметить. Проблема ли для Google? Да, конечно. Поэтому, анализируя риски, указывайте, кто пострадает.
Данные, которые присвоил рискам тестировщик, можно наложить на готовую таблицу «атрибут/компонент» для Google Sites. Таким образом мы получим тепловую карту рисков (рис. 3.9).
Рис. 3.9. Тепловая карта рисков для таблицы «атрибут/компонент» (ранняя версия Google+)
Ячейки окрашиваются в красные, желтые или зеленые цвета в зависимости от уровня риска компонентов. Очень просто вычислить примерный уровень риска для каждого значения — мы просто усредняем риски его возможностей. Эта карта была сделана в GTA, но с той же задачей справится и обыкновенная электронная таблица.
Такая диаграмма показывает возможности продукта, которые можно тестировать, вместе с присвоенными значениями рисков их сбоев. Трудно проставить эти значения объективно, тем более что у тестировщиков весьма специфическая точка зрения на продукт. Чтобы подстраховаться, мы опрашиваем и других заинтересованных в проекте лиц. Вот список тех людей, которые могут помочь с определением рисков, и несколько советов, как работать с их мнениями.
— Разработчики. Большинство разработчиков присвоят максимальное значение риска функции, которую писали они. Естественно, они хотят, чтобы их код был протестирован! Каждый кулик хвалит свое болото, но наш опыт подсказывает, что «кулик» часто переоценивает те функции, за которые он отвечает.
— Руководитель проекта. Удивительно, но руководители проектов тоже люди, и их оценка тоже может быть субъективной. Для них наиболее важными считаются те функции, которые позволят продукту выделиться на рынке и стать хитом.
— Специалисты по продажам. Эти парни зарабатывают на привлечении клиентов, поэтому их оценка возможностей смещена к тем, которые помогают продукту хорошо смотреться в демоверсии.
— Директора и вице-президенты. Топ-менеджеров обычно интересуют те возможности продукта, которые качественно отличают его от главных конкурентов.