Что пишут в блогах

Подписаться

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

Конференции

Что пишут в блогах (EN)

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

Про инструменты

Лучшие вакансии

.
Сладкоголосое пение тест-метрик
22.10.2018 14:42

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Риски

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

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

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

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

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

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

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

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

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

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

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

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

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