Home

Автор: Ким Энджел (Kim Engel)

Оригинал статьи

Перевод: Ольга Алифанова

Когда вы отчитываетесь о тестировании, используя метрики, это может привести к незапланированным последствиям. Какие метрики мы регулярно используем для отчетов, и какую информацию почерпнут из них заинтересованные лица? Давайте детально рассмотрим несколько реальных примеров.

95% тестов прошло, 1% упал, 4% не прогонялись

Метрики "прошло/упало" очень популярны в традиционных отчетах о прогрессе тестирования. Представьте на минутку, что вы продакт-оунер, и ваше слово – решающее в вопросе, выпускать ли продукт в релиз.

Тест-менеджер предоставляет вам вот такой график:

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

Когда я разглядываю этот график, он рождает больше вопросов, чем ответов:

Упавшие тесты

• Какие именно тесты упали?
• В чем причина падения, какова серьезность и статус соответствующих багов?

Тесты, которые не прогонялись

• Что это за тесты?
• Каковы наши риски, если эти тесты не будут проведены?

Прошедшие тесты

• Насколько хорошо протестированы области основного риска?
• Как эти области были определены?

Риски

• Что еще не тестировалось, помимо того, что представлено на графике, но должно быть протестировано с точки зрения команды тестирования? Примерами могут быть сценарии пользователя, end-to-end тесты, обработка ошибок, производительность, безопасность, и т. д.
• Насколько команда тестирования уверена в качестве продукта?

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

100% покрытие требований

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

Что за информация представлена здесь? Источник данных для этой метрики – как правило, матрица отслеживания требований (RTM). Набор тестов сравнивается с бизнес-требованиями, и каждое требование "покрывается" как минимум одним тестом. RTM не принимает во внимание (и не может принимать) неявные требования, она ограничена только внятно сформулированными.

Ряд команд докладывает о 100% покрытии требований, даже не запустив ни единого теста, поскольку RTM соотносит тесты и требования вне зависимости от того, запускались ли эти тесты. Команда традиционного проекта, в муках составившая тесты для каждого требования, может доложить о 100% покрытии требований на основании спецификации, даже ни разу не прикоснувшись к продукту.

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

Возьмем гипотетический, хорошо организованный и полностью документированный проект. Если мы постоянно поддерживаем требования и тесты в актуальном состоянии, а также запускаем все запланированные тесты, можем ли мы сообщить о 100% покрытии требований? RTM демонстрирует, какие требования, по мнению тестировщиков, должны быть покрыты как минимум одним тест-кейсом. Она не показывает объем тестирования этого конкретного требования. Как можно увидеть в этой лекции Кема Кейнера, 100% покрытия требований невозможно добиться при любом более-менее реалистичном сценарии тестирования. Мы не можем проверить все варианты ввода, все комбинации ввода, и все пути через код.

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

Сегодня поставлено 12 багов

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

Вот ряд реальных интерпретаций этой метрики от разных заинтересованных лиц.

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

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

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

Отмечено 0 блокеров, 3 критических бага

В этом релизе нет блокирующих багов (критичность 1), ожидающих фикса, и всего три критических бага (критичность 2).

Эта метрика – отличное начало для беседы, и подводит к очевидному вопросу – что это за три критических бага, и не нужно ли с ними разобраться до релиза?

Есть и менее очевидные вопросы:

• Оценивалась ли их критичность более чем одним человеком?
• Эти баги связаны с регрессом нынешней релизной версии?
• Тестировались ли области высокого риска?
• О каких еще багах стоит знать?
• Не понижалась ли критичность с 2 до 3 для каких-нибудь багов, чтобы получить красивую метрику?

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

Злоупотребление метриками

В большинстве случаев отчетность, состоящая исключительно из метрик – это признак неопытного, раздосадованного и не наделенного достаточными полномочиями тест-лида, который делает все это из лучших побуждений. Я знаю тест-лидов, которые предоставляют требуемые (обычно ПМами) метрики, хотя и раздражаются, потому что метрики нечетко отражают их мнение по поводу качества продукта, так как описывают тестирование лишь частично.

Реальный пример такой ситуации – проект, в котором каждое требование покрыто как минимум одним тестом, 95% тестов пройдено, и нет блокирующих багов. На основании этих метрик ПМ решил, что продукт соответствует выходным критериям, и дополнительное время тестирования не требуется. Как мы видели выше, у каждой из этих метрик, поданной изолированно, есть недостатки. В этом случае тест-менеджеру пришлось сражаться на высшем уровне, объясняя, почему тестированию требуется больше времени на тщательное изучение основных областей риска, несмотря на то, что графики фактически давали релизу зеленый свет.

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

Доступ персонала к системе ограничен соответственно их роли.

Написать пару тестов, которые, на первый взгляд, покрывают это требование, довольно легко:

1. Убедиться, что персонал может получить доступ к нужным им функциям.
2. Убедиться, что персонал не может получить доступ к функциям, которые им не требуются.

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

Менеджер рапортовал о 100% покрытии требований до того, как тесты начали прогоняться, основываясь на RTM. Прочитав образец требований и связанного с ним покрытия, насколько ценной вы сочтете эту метрику? Что, с вашей точки зрения, произойдет, когда команда тестирования попытается удостовериться, что система соответствует этому требованию?

Мораль

Тест-метрики и графики могут улучшить отчет о тестировании, но не могут его заменить. Не отчитывайтесь таким образом и не судите о прогрессе тестирования исключительно по метрикам, используйте не только количественную, но и качественную информацию. Регулярно беседуйте с командой тестирования, чтобы понимать картину целиком.

Эти графики напоминают сладкоголосых сирен из греческих мифов. Они привлекательны, пусты внутри, и несут с собой многие горести и беды, если бездумно за ними последовать. Чтобы узнать об альтернативных методах отчетности, прочитайте мою статью в Testing Trapeze за август 2015 года.

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