Разделы портала

Онлайн-тренинги

.
Три мысли о тестировании на основе рисков
10.01.2023 00:00

Автор: Джоэп Шууркс (Joep Shuurkes)
Оригинал статьи
Перевод: Ольга Алифанова

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

Если не на основе рисков, то на основе чего?

Примерно месяц назад я написал в Twitter:

Каковы альтернативы тестированию на основе рисков? На основе требований? Считаю это подгруппой тестирования на основе рисков.

Неуправляемое тестирование? Это или плохая идея («надеюсь, мне повезет»), или же мы руководствуемся рисками неизвестного неизвестного.

Другие варианты? Что-то в этом термине меня тревожит.

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

Из ответов на мой твит стало ясно, что термин беспокоит не только меня. Я планировал написать статью на основании этих ответов. Однако один из ответивших, Джеймс Томас, меня опередил. Он написал отличную статью «Отвергаем тестирование на основе рисков». В ней он соглашается с точкой зрения Стю Крока, что на рисках основано абсолютно все. Однако если это так, «тестирование на основе рисков» становится бессмысленным термином:

«Если риск эндемичен, он теряет всю объяснительную ценность».

Вот как Джеймс использует термин «риск» по отношению к своей работе:

«Я хочу говорить о рисках того, кто, кому и когда. Если я занимаюсь тем, что я бы назвал тестированием на основе рисков, я работаю на этом низком уровне».

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

Разные формы тестирования на основе рисков

Недавно меня попросили направить команды на путь тестирования на основе рисков. Я ответил вопросом, какая из четырех нижеперечисленных форм такого тестирования их интересует.

#1. Приоритезация выполнения тест-кейсов на основе рисков

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

#2. Тест-подход к сторис и эпикам на основе рисков

На основании вашего понимания стори или эпика, вы продумываете риски – например, желательные сценарии или сценарии, которых нужно избежать. Затем вы проектируете тесты на основании этих рисков или сценариев.

#3. (Предварительная) очистка сторис и/или эпиков на основе рисков

Вместо того, чтобы ждать до момента, когда тестирование надо вот-вот начинать, как в предыдущем варианте, вы думаете о рисках в ходе (предварительной) очистки. Эти риски затем информируют не только тестирование, но и дизайн, и разработку.

#4. Тест-стратегия для проекта на основе рисков

Это похоже на второй вариант в большем масштабе: берется весь проект, а не стори или эпик. В результате риски будут более высокоуровневыми. Это делает эту форму анализа рисков менее полезной для информирования тест-дизайна. Она может пригодиться для управления тестированием в целом с учетом рисков.

Это больше, чем влияние, умноженное на шанс возникновения

Довольно давно меня учили определять уровень риска путем размышлений над влиянием и шансом возникновения. Влияние – это влияние на пользователя или бизнес. Шанс возникновения можно разделить на шанс провала и частоту использования.

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

  • Влияние
    • Влияние на пользователя и/или заказчика
    • Влияние на компанию
    • Простота/скорость отслеживания, что что-то пошло не так
    • Простота/скорость восстановления после того, как что-то пошло не так
    • Простота/скорость добавления обходного пути
    • Простота/скорость исправления исходной проблемы
  • Шанс провала
    • Уровень сложности процесса
    • Уровень сложности кода
    • Количество зависимостей в коде
    • Количество недавних изменений кода в этой области
    • Объем технического долга
  • Частота использования или возникновения.

Вне всякого сомнения, этот список далек от совершенства. Однако он иллюстрирует, что нельзя обсуждать риск только на уровне влияния и шанса возникновения – вы что-то упустите.

Обсудить в форуме