Итак, релиз выпущен «в открытое плавание». Проходит день, другой. Однажды утром вы открываете почту, и находите письмо от клиента, сообщающее о серьёзной ошибке, найденной в процессе эксплуатации новой версии. Что делать? Рвать на себе волосы? Посыпать голову пеплом? Искать виноватого? Нет, нет и ещё раз нет!


Ниже предлагаю вам алгоритм действия в подобной ситуации.


(кликните по картинке для увеличения)

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

Ошибка, найденная клиентом – это сигнал «тревоги». Что-то в процессе, команде не так. Не является самым главным найти виноватого, важно понять причины возникшей ситуации и постараться устранить «проблемы», чтобы ситуация не повторилась снова.

Найти причину пропуска ошибки – это полдела. Нужно выработать стратегию её ликвидацию и поставки исправления клиенту в кратчайшие сроки и с минимальным риском для качества.

Оригинал статьи : Software Triage
Автор: Девид Вален (david.whalen@comcast.net)
Перевод: Галина Галкина (galinaegalkina@yandex.ru)

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

Если обратиться к Википедии, то «triage» является медицинским термином. Означает подход, используемый в медицине, для определения последовательности оказания помощи пострадавшим в условиях нехватки медицинского персонала.

«Triage» - это французское слово, означающее «сортировка». Медицинская сортировка используется на поле боя, или в случае катастроф. Пострадавшие делятся на группы: нуждающиеся в неотложной помощи, могущие подождать. Иногда доктор может принять решение не оказывать помощь больным в критическом состоянии, не имеющим шансов на выживание, т.к. врачи только потратят время, за которое можно спасти остальных.

Чтобы использовать понятие триаж в тестировании программного обеспечения, давайте немного изменим определение.

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

Что-то же – уже лучше.

Если с чем и знакомы тестировщики и руководители групп тестирования, так это с «ограниченными ресурсами». К сожалению, в ограниченное время невозможно протестировать и перепроверить все. Часто мы просим выделить больше времени и больше людей, так? Так!

Так как же лучше использовать ограниченное время и ресурсы? Используйте триаж!

Серьезность и Приоритет
Чтобы триаж был успешен, необходимо использовать две очень близких и все-таки очень разных характеристики ошибки: Серьезность и Приоритет. По подходу Триаж, каждые дефект обладает и Серьезностью и Приоритетом. Многие системы контроля дефектов использует либо одну, либо обе характеристики. Часто они используются взаимозаменяемо. Но все-таки эти характеристики различны. Давайте рассмотрим их подробнее.

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

Сколько же значений серьезности необходимо? Как в сказке «Златовласка и 3 медведя» - 6 слишком много, 3 – слишком мало.

Я предпочитаю использовать четное количество значений. Нечетное количество часто ведет к уклонению от прямого решения (например, для 5 значений, слишком много ошибок бывают с серьезностью = 3). Может быть слишком много значений? Абсолютно! А слишком мало? Конечно. Если значений слишком много, управление дефектами превращается в ночной кошмар. Если слишком мало – тяжело определить степень влияния ошибки. Я работал в проекте, где было около 15 значений Серьезности (3 значения критических, 3 серьезных и т.д.). Со временем показатель Серьезности перестал что-либо означать.

Я пытаюсь не использовать только номер для обозначения серьезности. Обычно я использую номер с описанием (1-Критично, 2-Серьезно, 3-Косметическая проблема, и т.д.). Значения, выражаемые только числом, могут вводить в заблуждение (что более серьезно 1 или 4). Кто-то использует 1 для обозначения самой высокой степени Серьезности, кто-то наоборот. Независимо от того, как использовать обозначения, очень важно определить и задокументировать критерий определения каждого значения Серьезности ошибки. Значения серьезности ошибки изначально определяет тестировщик, который заносит ошибку в систему управления ошибками; тем не менее, занесенные ошибки должны проверяться и исправляться при необходимости. Вернемся к этому позднее.

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

Если исходить от целей Триажа, Приоритет используется для определения очередности исправления ошибок. Например, ошибка имеет Критичную Серьезность, однако в связи с большим объемом ресурсов, необходимых для исправления, может быть непрактичным исправлять ошибку сейчас. Некоторые критичные ошибки могут иметь невысокий приоритет, в то же время менее критичные могут обладать более высоким приоритетом. Например, опечатка не является критической ошибкой, однако наносит урон имиджу вашей компании. Опечатку легко исправить, таким образом, подобной ошибке могут присвоить высокий приоритет.

Уровни Приоритета, как и уровни Серьезности должны быть определены и задокументированы. Мне нравится использовать 3 уровня Приоритета (1-Высокий, 2-Средний, и 3-Низкий), потому что это просто и понятно большинству членов команды. 1-Высокий – ошибки, которые нужно исправлять срочно, 3-Низкий – ошибки, которые не мешают работе. Обычно ошибки с низким приоритетом переносят на следующий релиз.

Приоритет определяет порядок, в котором ошибки должны исправляться. Часто Приоритет определяют исходя из двух факторов: вероятность возникновения и необходимое количество ресурсов (время, доступность разработчиков и тестировщиков, и т.д.). Тест может приводить к падению программы, однако пользователь должен сделать что-то экстраординарное, чтобы повторить это. Если ошибка требует скрупулезного исправления или исправления архитектуры, возможно, не стоит торопиться с исправлением. Критично? Да! Высокий приоритет? Может быть. А может, и нет.

Уровни приоритета полезны в определение готовности релиза или качества (но это уже другая статья).

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

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

Руководитель группы менеджмента продукта/бизнез анализа. Менеджеры продукта или бизнес аналитики, представляют интересы заказчика. Именно они могут лучше всего оценить степень влияния с точки зрения заказчика.

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

Руководитель группы тестирования. Руководитель группы тестирования оценивает ошибку с позиции Качества. Я, как руководитель группы тестирования или группы обеспечения качества, часто веду Триаж совещания, т.к. являюсь ответственным за качество программного продукта и за управление ошибками.

Руководитель группы тестирования, кроме роли ведущего собрания, является тем, кто оценивает степень влияния ошибки на тестирование, включая степень влияния на график работ, когда и куда включить исправление (релиз, окружение), а также степень влияния исправления дефекта на другие части программы (регрессия).

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

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

Цели Триажа
Цель остается одна, вне зависимости от формы проведения триажа: оценить, установить приоритет и адресовать исправление ошибок. Как минимум, необходимо проверить серьезность ошибок, сделать изменения при необходимости, определить очередность исправления ошибок, и распределить ресурсы.

Процедура проведения Триажа
Подход к проведению триажа может меняться, я стараюсь концентрироваться на следующих аспектах.

Обзор ошибок, оценка и распределение. Обычно команда триажа проводит обзор и первичную оценку всех новых и/или отклоненных дефектов. Проводится проверка серьезности ошибки, определяются схожие ошибки, определяется очередность исправления. На совещании в системе управления дефектов устанавливается Приоритет и ошибки распределяются на членов команды либо для решения, либо для исследования. Мне нравится использовать проектор, чтобы все члены собрания могли видеть систему управления дефектами и изменения.

На совещании также просматриваются отклоненные дефекты, проверяется причины отклонения. Иногда дефект назначают на будущий релиз, либо проводят дополнительное исследование.

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

Частота проведения Триажей
Меня часто спрашивают: «Как часто нужно проводить Триаж совещание?». Обычно я отвечаю: «Зависит от многого». Зависит от того, как влияет совещание на график работ команды, на доступность членов команды. Зависит от графика работ всего проекта. Зависит от этапа жизненного цикла разработки, на котором находимся. Зависит от количества ошибок. «Зависит от многого» - это лучший ответ, который я могу дать.

Обычно триаж собирается часто в начале проекта. Например, каждый день – вначале, затем 2-3 раза в неделю, а в конце проекта раз в неделю.

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

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