Пример отчета по тестированию

При написании отчета следует понимать: Кому отчет? Зачем? Что на его основании будут делать?

Как правило ЛПР (лицам принимающим решения) требуются ответы на следующие вопросы:
1) Это можно продавать/устанавливать или нужно доработать/выкинуть?
2) Какова степень уверенности?
3) Как называется то, о чем идет речь?

Напишем отчет в виде краткого резюме по текущему состоянию продукта.
——————————————————————–
Продукт СМФ (проект “Банзай”), версия 158/32ф.

Было выполнено 60% тестов из запланированных. Тестирование было прекращено ввиду большого числа ошибок, закрывающих доступ к тестированию.

В настоящий момент полностью неработоспособны 18 из 150 юзкейсов.
Полностью неработоспособны 3 из 45 критически важных юзкейсов.
Работает с оговорками 93 юзкейса.
39 юзкейсов реализованы хорошо.

Я не рекомендую поставку данной версии клиентам. Версия ограничено пригодна для ознакомления с возможностями программы. Оценочное время готовности продукта: декабрь - 30%, февраль - 70%. Полагаю, нам не стоит приурочивать рекламную компанию к рождеству.
Отчет подготовлен 17 сентября сего года лидером тестирования проекта “Банзай” имярек.
——————————————————————–

Повторюсь.
Кому отчет? Зачем? Что на его основании будут делать?

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

скажут что нибудь только тому человеку, который прекрасно понимает процесс. А, например, менеджеру по продажам не скажут ничего. Т.е. вообще ничего.
- У нас в этой версии остались неисправленными 15 важных, 78 маловажных ошибок.
- А сколько должно быть? Вот я слышал, что продукт Х был выпущен с несколькими сотнями тысяч известных неисправленных ошибок. И очень успешный продукт. А тут всего 93. Так выпускаем или нет?

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

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

  • процент возвратов,
  • среднее время исправления дефектов, с разбивкой по приоритетам,
  • и т.д.

[1]
и не войдут:

  • номер версии и даже название проекта (отчет будет помесячным)
  • оценка работоспособности программы

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

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

Мой опыт показывает, что список ошибок включать в отчет бессмысленно, его все равно никто из руководства не читает. Такой список хорош, только если работник не может быть подключен к системе бактрекинга. Например, из-за экономии денег генеральному директору или дизайнеру интерфейсов не купили компьютер ;-) . [2]


[1] По хорошему тут бы карты Шухарта приложить. Но ими мало кто пользоваться умеет.
[2] Нечто подобное я имел несчастье наблюдать в одном из проектов.Небольшая экономия денег обернулась необходимостью распечатывать список ошибок и передавать его на бумаге. Со всеми вытекающими.

Комментариев: 4

  1. Alexei Barantsev написал:

    Сергей, формулировка отчёта в терминах только чисел тоже не очень хороша.

    Что значит “неработоспособны 3 из 45 критически важных юзкейсов”? Может быть руководство решит, что эти 3 не так уж критически важны, и можно выпустить продукт без них. Для этого ЛПР должны получить информацию, какие именно три неработоспособны.

  2. SALar написал:

    А вот с этим пожалуй соглашусь.

    Не работает:
    * сохранение файлов
    * справка
    * неработоспособно разделение прав (работать можно только по root-вым аккаунтом)

    Изначально эти вещи даже были, но я их выкинул. Так лучше?

  3. Alexei Barantsev написал:

    Да, так лучше.

    Однако следующий шаг — ЛПР захочет знать, кого спросить про эти три неработающие юзкейса? У кого узнать размер бедствия и прогнозы по исправлению ситуации? Либо мы включаем эту информацию (фактически часть описания дефекта и его текущий статус) в отчёт, либо даём ссылку и надеемся, что начальник сообразит, что есть что в этой дурацкой баг-трекинговой системе. Что лучше?

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

    А является таким признаком наличие фактов, полезных для принятия решения. Для чего нужно общаться с ЛПР, чтобы научиться понимать, какие факты могут быть им полезны. А не клепать отчёты всегда по единому шаблону.

  4. Alexei Barantsev написал:

    http://mavericktester.com/software-test-reports-for-startups

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.