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

Данные, которые присвоил рискам тестировщик, можно наложить на готовую таблицу «атрибут/компонент» для Google Sites. Таким образом мы получим тепловую карту рисков (рис. 3.9).

Рис. 3.9. Тепловая карта рисков для таблицы «атрибут/компонент» (ранняя версия Google+)

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

Такая диаграмма показывает возможности продукта, которые можно тестировать, вместе с присвоенными значениями рисков их сбоев. Трудно проставить эти значения объективно, тем более что у тестировщиков весьма специфическая точка зрения на продукт. Чтобы подстраховаться, мы опрашиваем и других заинтересованных в проекте лиц. Вот список тех людей, которые могут помочь с определением рисков, и несколько советов, как работать с их мнениями.

— Разработчики.Большинство разработчиков присвоят максимальное значение риска функции, которую писали они. Естественно, они хотят, чтобы их код был протестирован! Каждый кулик хвалит свое болото, но наш опыт подсказывает, что «кулик» часто переоценивает те функции, за которые он отвечает.

— Руководитель проекта.Удивительно, но руководители проектов тоже люди, и их оценка тоже может быть субъективной. Для них наиболее важными считаются те функции, которые позволят продукту выделиться на рынке и стать хитом.

— Специалисты по продажам.Эти парни зарабатывают на привлечении клиентов, поэтому их оценка возможностей смещена к тем, которые помогают продукту хорошо смотреться в демоверсии.

— Директора и вице-президенты.Топ-менеджеров обычно интересуют те возможности продукта, которые качественно отличают его от главных конкурентов.

Итак, у всех мнений есть погрешность. Чтобы бороться с этим, мы опрашиваем всех заинтересованных в проекте людей по отдельности и просим оценить риски по описанным выше двум факторам. Их не так легко уговорить на эту работу, но мы, кажется, нашли успешную стратегию. Вместо того чтобы вдаваться в объяснения процесса и упрашивать участников нам помочь, мы просто делаем все сами и показываем им уже готовую тепловую карту. Как только они видят наше мнение, они мгновенно выплескивают свое. Разработчики активно принимают участие, если понимают, что мы используем карту для расстановки приоритетов в тестировании. Так же ведут себя и руководители проектов, и менеджеры по продажам. Все они заинтересованы в его качестве.

Есть в этом подходе определенная сила. Когда мы определяем риски самостоятельно, мы несомненно приходим к варианту, с которым другие участники проекта не будут согласны. Так и есть, подготавливая для них наш вариант анализа рисков, мы даем им почву для споров. В этом идея. Мы не спрашиваем их о каких-то абстрактных понятиях, мы даем им конкретные выводы, которые можно оспорить . Люди не всегда могут сказать, каким должен быть правильный ответ, но легко скажут, каким он быть не должен . Такой хитрый подход приносит нам много правдивых данных для вычисления рисков.

Когда риски будут согласованы, можно приступать к их последовательному снижению.

Редко удается полностью устранить риски. Мы водим машину, хоть это и опасно, но ведь нужно добираться до работы? Вообще возможность несчастного случая не означает, что он обязательно произойдет, да и, скорее всего, ничего страшного не случится. Почему? Потому что своими действиями мы снижаем возможный риск. Например, не садимся за руль в нетрезвом состоянии и не водим в условиях недостаточной видимости. Таким образом мы снижаем риски .

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

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

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