Сообщений в теме: 14

[fishcka]

привет всем!!

я достаточно недавно работаю тестером (1 год примерно), и до недавних пор не сталкивалась с проблемой документации
за последние два месяца уже научилась писать тест-план и тест-кейсы

теперь требуется научиться писать отчёты по результатам тестирования, я поизучала форум, но мало чего нашла

вопрос: как правильно составить test-report? что в нём должно описываться и как?

[Case]

Может посто спросить у того, кто хочет читать этот тест-репорт? Всё-равно не угадаешь, что в нём должно быть, по мнению старшего менеджера.

[fishcka]

как раз он то и попросил меня найти шаблон отчёта, потом переделать для нашего продукта и предоставить :P

[ShS]

Можно сказать, самый простой вариант отчета,
отчет за временной интервал или по версии.

1. Что было сделано
2. Сколько проблем было выявлено (иерархия по важности, а внутри по состоянию, например)
3. Результаты обработки ранее выявленных проблем.

А вообще конечно надо уточнять у того, кому он нужен :)

[Doveangel]

привет всем!!

я достаточно недавно работаю тестером (1 год примерно), и до недавних пор не сталкивалась с проблемой документации

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

Главными пунктами в отчете должны быть:
--какие задачи были протестированы (функциональности)
--сроки проведения тестирования, кем проводилось тестирование
--найденные ошибки (с описанием критических ошибок)
--исправлены ли эти ошибки на дату подачи отчета
--обратить внимание на часто повторяющиеся ошибки (если такие есть)
--по необходимости добавить приложение со всеми тест-кейсами

[van]

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

[Victorea]

Вообще для написания отчетов по результатам тестирования есть автоматизированные средства. Но если их нет, то пункты в отчете для описания каждой ошибки должны быть такими:
1. Идентификационный номер ошибки
2. Имя докладчика
3. Имя того, кому эта ошибка предназначается
4. Приоритет ошибки
5. Статус ошибки
6. Категория ошибки
7. Воспроизводимость ошибки
8. Дата предъявления ошибки, дата ее последней модернизации
9. Резолюция
10. Версия тестируемого продукта и билд продукта
11. Заголовок ощибки
12. Описание ошибки
13. Шаги к воспроизведению ошибки
14. Возможны приложенные файлы и добавочная информация

[Case]

А по-моему это не отчёт о тестировании, а описание бага.

[SALar]

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

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

Пишем отчет в виде Резюме.
--------------------------------------------------------------------
Версия 158/32ф.
Было выполнено 60% тестов из запланированных. Тестирование было прехращено ввиду большого числа ошибок, закрывающих доступ к тестированию.
В настоящий момент полностью неработоспособны 18 из 150 юзкейсов.
Полностью неработоспособны 3 из 45 критически важных юзкейса. Это:
Невозможно сохранение файла под тем же именем
Невозможен запуск приложения под аккаунтом с правами, менее чем у роли администратора.
Не работает справка

Работает с оговорками 93 юзкейса.
39 юзкейсов реализованы хорошо.

Я не рекомендую поставку данной версии клиентам. Версия ограничено пригодна для ознакомления с возможностями программы.
--------------------------------------------------------------------

[van]

Отличный отчет!

Еще бы добавить данный по метрикам, связанным непосредственно с ошибками (по статусам/приоритетам и т.д., по времени решения/открытия и т.п.) цены бы ему не было.

В общем, мое видение проблемы:
При составлении отчета
1. необходимо отталкиваться от нужд и целей, ради которых составляется отчет
2. необходимо отталкиваться от применяемых (собираемых) метрик

[SALar]

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

данный по метрикам, связанным непосредственно с ошибками (по статусам/приоритетам и т.д.,

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

по времени решения/открытия и т.п.

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

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

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

[Navr]

Главными пунктами в отчете должны быть:
--какие задачи были протестированы (функциональности)
--сроки проведения тестирования, кем проводилось тестирование
--найденные ошибки (с описанием критических ошибок)
--исправлены ли эти ошибки на дату подачи отчета
--обратить внимание на часто повторяющиеся ошибки (если такие есть)
--по необходимости добавить приложение со всеми тест-кейсами

Я бы к этому добавил еще:
- Описание самого процесса тестирования (что использовалось/применялось)
- Описание конфигурации на которой проводилось тестирование
- Пожелания, замечания, выводы

И получится вполне нормальный шаблон для отчета.
Более подробно - исходя из конкретной ситуации.

[Vit]

Просто в качестве примера. В течение года используем стандартную схему отчета для всех проектов:
1. Расписание (с указанием того, кто и в какие сроки что делал)
2. Результаты по типам проведенных тестов (список протестированной ф-сти, системы, на которых смотрели, всяческие графики по performance и т.п.)
3. Заключение (самая читаемая часть), включает наши общие выводы о качестве продукта, с описанием критических вещей.
4. Приложение со списком багов и распределениями багов по severity/компонентам/времени и т.п.

[Green]

SALar хорошо расписал принцип написания отчета. Хочу только немного дополнить.

В написании документа необходимо отталкиваться от того, как будет использоваться документ - его назначение. Для недельного отчета могут быть две основных задачи:
1. Оценить степень готовности продукта (прогресс разработки)
2. Оценить проделанную работу по тестированию

Прогресс - это величина динамическая и получить ее можно только сравнив результаты предыдущей недели и настоящей. Сравнивать нужно по категориям - открытые, исправленные, закрытые баги (зависит от принятой системы классификации). Если результаты перенести на график, то можно наглядно определить насколько продукт готов к выпуску. В идеальном случае кривая незакрытых багов (найденных, исправленных) должна сойтись с кривой исправленных. Другими словами к финальному релизу нужно, что бы все баги были устранены. Если это не так, то должно быть волевое решение руководства, что продукт сдается с дефектами.

График демонстрирует динамику активности на проекте. После выхода очередного билда кривая не закрытых багов обычно возрастает не линейно. Если разработчиками или тестировщиками уделяется мало внимания существующим багам, то кривая закрытых багов растет медленнее чем не закрытых.

В дополнение к графику нужно оформлять табличку: баги прошлой недели (по категориям), баги текущей недели, прирост. Данные таблицы хорошо поясняют график. (Если быть точным, то график строится на основании этой таблицы.)

Отдельным разделом описываются задачи, выполненые тестировщиками:
- состав команды и время, затраченное на проект;
- прирост подготовленных тестов (тест кейсов);
- количество выполненных тест кейсов;
- описание проблем, с которыми столкнулись в процессе тестирования и предпринятые меры;
- планы на будущую неделю;
- возможные проблемы будущей недели и пути их устранения.