Джеймс Уиттакер - Как тестируют в Google

— Выразительный: выражать свои мысли.

— Конфиденциальный: ограничивать сообщения выбранной аудиторией.

Комментарии:

— Выразительный: выражать свое мнение с помощью комментариев.

— Расширяемый: передавать данные комментариев для использования другими службами и приложениями.

— Конфиденциальный: ограничивать сообщения выбранной аудиторией.

Фотографии:

— Социальный: делиться фотографиями с контактами и друзьями.

— Простой: легко загружать новые фотографии.

— Простой: легко импортировать фотографии из других источников.

— Расширяемый: интегрироваться с другими фотослужбами.

— Конфиденциальный: ограничивать доступ к фотографиям только для выбранной аудитории.

На рис. 3.6 приведены результаты ACC-анализа в форме электронной таблицы.

Рис. 3.6. Электронная таблица ACC для Google+

А на рис. 3.7 эти же данные представлены в другой форме.

Рис. 3.7. Таблица ACC для Google+

Риски повсюду. Дома, на дорогах, на работе. Все, что мы делаем, включает в себя элемент риска, и разработка ПО ­— не исключение. Чтобы обезопасить свою жизнь, мы покупаем безопасные автомобили и водим осторожно. На совещаниях мы следим за своими словами и стараемся попасть на проекты, которые сможем выполнить, — все это для того, чтобы уменьшить риск остаться без работы.

А что сделать, чтобы уменьшить риск выпуска некачественного программного продукта? Как предотвратить опасность возникновения сбоев в выпускаемых нами программах, как уберечь нашу компанию от вероятного ущерба ее репутации? Разу­меется, отличный способ минимизировать риски — не выпускать программу. Нет программы — нет риска. Но секрет вот в чем: мы получаем прибыль от выпуска программного обеспечения, если хорошо просчитываем риски.

Именно «просчитываем», не «вычисляем» — мы не гонимся за математической точностью. Мы ходим по тротуарам, а не гуляем по проезжей части, потому что так безопаснее, а вовсе не потому, что чьи-то расчеты показали, будто так мы снизим риск попасть под машину на 59%. Мы покупаем машины с подушками безопасности не потому, что помним точные статистические данные повышения выживаемости, а просто это всем известно: подушка безопасности снизит риск разбить голову о руль. Все. Работа по снижению рисков может быть максимально эффективной и безо всяких трудоемких математических расчетов. Такая работа называется анализом рисков .

В осознании и просчитывании рисков, которые следует учитывать при тестировании, главным помощником был и остается здравый смысл. Переключим здравый смысл в режим «включено» и ответим на следующие важные вопросы:

— О каких событиях нам следует беспокоиться?

— Насколько такие события вероятны?

— Каким может быть от них ущерб для нашей компании?

— Каким может быть от них ущерб для будущих пользователей?

— Есть ли в программе защита от возникновения нежелательных событий?

— Какова вероятность того, что такая защита не сработает?

— Во сколько нам обойдется такой сбой защиты?

— Насколько сложно будет восстановиться после такого сбоя?

— Нежелательное событие может случиться вновь или эта проблема может быть одноразовой?

Нет резона использовать математический расчет при анализе рисков просто потому, что количество вероятных переменных настолько велико, что на их точный расчет уйдет больше сил, чем на саму минимизацию рисков. В Google мы сводим все риски к двум факторам: частота сбоев и степень воздействия . Для каждой возможности в разрабатываемом продукте тестировщики присваивают этим двум факторам простые значения. Именно простые, а не идеально точные. Нам ведь нужно просто определить, какие возможности следует тестировать и в каком порядке. Для этого достаточно понять, какая возможность несет в себе больший риск, а какая меньший. В этом нам здорово помогает GTA (рис. 3.8).

GTA использует четыре оценки частоты появления сбоев:

— Очень редко: трудно представить ситуацию, при которой возникнет проблема, но если такое случится, то ее решение будет простым.

Пример:страница загрузки браузера Google Chrome. [37] http://www.google.com/chrome В основном содержимое этой страницы статично, автоматика там срабатывает только при определении клиентской ОС. Если произойдет сбой в базовом коде HTML или в сценарии на странице, то его быстро обнаружит мониторинг кода.

— Редко: есть случаи, когда может произойти сбой. Однако из-за невысокой сложности процесса или редкого использования такое случается нечасто.

Пример:кнопка «Вперед» в Chrome. Эта кнопка используется, но гораздо реже, чем ее напарница кнопка «Назад». Так сложилось, что ее работа редко приводит к сбоям, а если такое все-таки случится, то проблема будет быстро перехвачена еще на этапе тестирования раннего выпуска нашими первыми пользователями.

— Иногда: такой сбой легко представить, хотя он и достаточно сложен технически, а возможность продукта, как мы считаем, будет популярна у пользователей.

Пример:Возможности Chrome Sync. Chrome синхронизирует закладки, темы, заполнение форм, историю просмотра страниц и другие данные пользователя между компьютерами. Есть много типов данных и платформ ОС, поэтому слияние изменений — задача непростая. Если произойдет сбой синхронизации данных, пользователь, вероятнее всего, это заметит. Синхронизация выполняется только в том случае, когда происходят изменения в синхронизируемых данных — например, пользователь добавил новую закладку.

Рис. 3.8. Оценка риска по частоте и воздействию в GTA для Google+

— Часто: если в возможности, которая входит в часто используемую фичу, регулярно происходят сбои.

Пример:отображение веб-страниц. Основная задача браузера — отобразить HTML, CSS и код JavaScript любого происхождения и качества. Даже если исходный загружаемый код будет технически неправильным, пользователь решит, что проблема в браузере. Риск сильно возрастает, если мы рассматриваем сайт с высоким уровнем трафика. Проблемы отображения не всегда могут быть обнаружены пользователем: визуально элемент может съехать, но тем не менее остается рабочим. Или он может исчезнуть совсем, но тогда как пользователь узнает, что он вообще был?

Итак, тестировщик выбирает одно из этих значений для каждой возможности. Мы специально сделали четыре варианта оценки, чтобы тестировщик не вздумал постоянно выбирать средний вариант. Здесь нужно серьезно подумать.