Уиттакер . - Как тестируют в Google
— Выразительный: создавать новые круги на основе контекста пользователя.
— Простой: удобно добавлять, обновлять и удалять контакты из кругов.
— Простой: удобно создавать и изменять круги.
— Расширяемый: передавать данные о кругах службам и приложениям.
Оповещения:
— Простой: показывать оповещения кратко.
— Расширяемый: отправлять оповещения другим службам и приложениям.
Видеочат:
— Социальный: приглашать свои круги в видеочат.
— Социальный: открыть свой видеочат публике.
— Социальный: оповещать других пользователей в своих лентах о видеочатах.
— Простой: создавать видеочат и принимать в нем участие в несколько кликов.
— Простой: отключить в один клик видео- и аудиоданные.
— Простой: приглашать дополнительных пользователей в существующий видеочат.
— Выразительный: посмотреть, как видеочат будет выглядеть для других.
— Расширяемый: общаться в текстовом чате во время видеочата.
— Расширяемый: включать видеоролики с YouTube в видеочат.
— Расширяемый: настраивать устройства в Настройках.
— Расширяемый: участвовать в видеочатах без веб-камеры, используя аудиоканал.
— Конфиденциальный: ограничивать доступ в видеочат только для приглашенных гостей.
— Конфиденциальный: оповещать только приглашенных гостей о видеочате.
Записи:
— Выразительный: выражать свои мысли.
— Конфиденциальный: ограничивать сообщения выбранной аудиторией.
Комментарии:
— Выразительный: выражать свое мнение с помощью комментариев.
— Расширяемый: передавать данные комментариев для использования другими службами и приложениями.
— Конфиденциальный: ограничивать сообщения выбранной аудиторией.
Фотографии:
— Социальный: делиться фотографиями с контактами и друзьями.
— Простой: легко загружать новые фотографии.
— Простой: легко импортировать фотографии из других источников.
— Расширяемый: интегрироваться с другими фотослужбами.
— Конфиденциальный: ограничивать доступ к фотографиям только для выбранной аудитории.
На рис. 3.6 приведены результаты ACC-анализа в форме электронной таблицы.
Рис. 3.6. Электронная таблица ACC для Google+
А на рис. 3.7 эти же данные представлены в другой форме.
Рис. 3.7. Таблица ACC для Google+
Риск
Риски повсюду. Дома, на дорогах, на работе. Все, что мы делаем, включает в себя элемент риска, и разработка ПО — не исключение. Чтобы обезопасить свою жизнь, мы покупаем безопасные автомобили и водим осторожно. На совещаниях мы следим за своими словами и стараемся попасть на проекты, которые сможем выполнить, — все это для того, чтобы уменьшить риск остаться без работы.
А что сделать, чтобы уменьшить риск выпуска некачественного программного продукта? Как предотвратить опасность возникновения сбоев в выпускаемых нами программах, как уберечь нашу компанию от вероятного ущерба ее репутации? Разумеется, отличный способ минимизировать риски — не выпускать программу. Нет программы — нет риска. Но секрет вот в чем: мы получаем прибыль от выпуска программного обеспечения, если хорошо просчитываем риски.
Именно «просчитываем», не «вычисляем» — мы не гонимся за математической точностью. Мы ходим по тротуарам, а не гуляем по проезжей части, потому что так безопаснее, а вовсе не потому, что чьи-то расчеты показали, будто так мы снизим риск попасть под машину на 59%. Мы покупаем машины с подушками безопасности не потому, что помним точные статистические данные повышения выживаемости, а просто это всем известно: подушка безопасности снизит риск разбить голову о руль. Все. Работа по снижению рисков может быть максимально эффективной и безо всяких трудоемких математических расчетов. Такая работа называется анализом рисков.
Анализ рисков
В осознании и просчитывании рисков, которые следует учитывать при тестировании, главным помощником был и остается здравый смысл. Переключим здравый смысл в режим «включено» и ответим на следующие важные вопросы:
— О каких событиях нам следует беспокоиться?
— Насколько такие события вероятны?
— Каким может быть от них ущерб для нашей компании?
— Каким может быть от них ущерб для будущих пользователей?
— Есть ли в программе защита от возникновения нежелательных событий?
— Какова вероятность того, что такая защита не сработает?
— Во сколько нам обойдется такой сбой защиты?
— Насколько сложно будет восстановиться после такого сбоя?
— Нежелательное событие может случиться вновь или эта проблема может быть одноразовой?
Нет резона использовать математический расчет при анализе рисков просто потому, что количество вероятных переменных настолько велико, что на их точный расчет уйдет больше сил, чем на саму минимизацию рисков. В Google мы сводим все риски к двум факторам: частота сбоев и степень воздействия. Для каждой возможности в разрабатываемом продукте тестировщики присваивают этим двум факторам простые значения. Именно простые, а не идеально точные. Нам ведь нужно просто определить, какие возможности следует тестировать и в каком порядке. Для этого достаточно понять, какая возможность несет в себе больший риск, а какая меньший. В этом нам здорово помогает GTA (рис. 3.8).
GTA использует четыре оценки частоты появления сбоев:
— Очень редко: трудно представить ситуацию, при которой возникнет проблема, но если такое случится, то ее решение будет простым.
Пример: страница загрузки браузера Google Chrome37. В основном содержимое этой страницы статично, автоматика там срабатывает только при определении клиентской ОС. Если произойдет сбой в базовом коде HTML или в сценарии на странице, то его быстро обнаружит мониторинг кода.
— Редко: есть случаи, когда может произойти сбой. Однако из-за невысокой сложности процесса или редкого использования такое случается нечасто.
Пример: кнопка «Вперед» в Chrome. Эта кнопка используется, но гораздо реже, чем ее напарница кнопка «Назад». Так сложилось, что ее работа редко приводит к сбоям, а если такое все-таки случится, то проблема будет быстро перехвачена еще на этапе тестирования раннего выпуска нашими первыми пользователями.
— Иногда: такой сбой легко представить, хотя он и достаточно сложен технически, а возможность продукта, как мы считаем, будет популярна у пользователей.
Пример: Возможности Chrome Sync. Chrome синхронизирует закладки, темы, заполнение форм, историю просмотра страниц и другие данные пользователя между компьютерами. Есть много типов данных и платформ ОС, поэтому слияние изменений — задача непростая. Если произойдет сбой синхронизации данных, пользователь, вероятнее всего, это заметит. Синхронизация выполняется только в том случае, когда происходят изменения в синхронизируемых данных — например, пользователь добавил новую закладку.
Рис. 3.8. Оценка риска по частоте и воздействию в GTA для Google+
— Часто: если в возможности, которая входит в часто используемую фичу, регулярно происходят сбои.
Пример: отображение веб-страниц. Основная задача браузера — отобразить HTML, CSS и код JavaScript любого происхождения и качества. Даже если исходный загружаемый код будет технически неправильным, пользователь решит, что проблема в браузере. Риск сильно возрастает, если мы рассматриваем сайт с высоким уровнем трафика. Проблемы отображения не всегда могут быть обнаружены пользователем: визуально элемент может съехать, но тем не менее остается рабочим. Или он может исчезнуть совсем, но тогда как пользователь узнает, что он вообще был?
Итак, тестировщик выбирает одно из этих значений для каждой возможности. Мы специально сделали четыре варианта оценки, чтобы тестировщик не вздумал постоянно выбирать средний вариант. Здесь нужно серьезно подумать.
Для оценки воздействия мы используем такой же упрощенный метод, с таким же количеством вариантов (снова возьмем браузер Chrome для примера).
Воздействие может быть:
— Минимальным: сбой, который пользователь может не заметить.
Пример: есть такой дополнительный сервис Chrome Labs. Его функциональность необязательна для работы, и сбой при загрузке страницы chrome://labs затронет лишь нескольких пользователей. Эта страница содержит дополнительные, экспериментальные фичи Chrome, о которых большинство людей даже не знают. Сами фичи снабжены пометкой «Используйте на свой страх и риск». Проще говоря, компания не несет ответственности за сбои, но зато и угроз для работы браузера нет.
