Отчёты по тестированию
#1
Отправлено 14 января 2005 - 11:07
я достаточно недавно работаю тестером (1 год примерно), и до недавних пор не сталкивалась с проблемой документации
за последние два месяца уже научилась писать тест-план и тест-кейсы
теперь требуется научиться писать отчёты по результатам тестирования, я поизучала форум, но мало чего нашла
вопрос: как правильно составить test-report? что в нём должно описываться и как?
#2
Отправлено 14 января 2005 - 11:27
Редактор портала www.it4business.ru
#3
Отправлено 14 января 2005 - 12:07
#4
Отправлено 14 января 2005 - 12:12
отчет за временной интервал или по версии.
1. Что было сделано
2. Сколько проблем было выявлено (иерархия по важности, а внутри по состоянию, например)
3. Результаты обработки ранее выявленных проблем.
А вообще конечно надо уточнять у того, кому он нужен :)
#5
Отправлено 14 января 2005 - 13:52
вообще-то год (!) - это достаточно большоя срок для тестера... за это время можно было многому научиться... Даже если начальство не требует - для своего же опыта могли бы поинтересоваться специализированной литературой и информацией из других возможных источников..привет всем!!
я достаточно недавно работаю тестером (1 год примерно), и до недавних пор не сталкивалась с проблемой документации
Это не осуждение - это зов к действию ;)
Главными пунктами в отчете должны быть:
--какие задачи были протестированы (функциональности)
--сроки проведения тестирования, кем проводилось тестирование
--найденные ошибки (с описанием критических ошибок)
--исправлены ли эти ошибки на дату подачи отчета
--обратить внимание на часто повторяющиеся ошибки (если такие есть)
--по необходимости добавить приложение со всеми тест-кейсами
#6
Отправлено 17 января 2005 - 08:55
#7
Отправлено 17 января 2005 - 15:22
1. Идентификационный номер ошибки
2. Имя докладчика
3. Имя того, кому эта ошибка предназначается
4. Приоритет ошибки
5. Статус ошибки
6. Категория ошибки
7. Воспроизводимость ошибки
8. Дата предъявления ошибки, дата ее последней модернизации
9. Резолюция
10. Версия тестируемого продукта и билд продукта
11. Заголовок ощибки
12. Описание ошибки
13. Шаги к воспроизведению ошибки
14. Возможны приложенные файлы и добавочная информация
#8
Отправлено 17 января 2005 - 15:38
Редактор портала www.it4business.ru
#9
Отправлено 18 января 2005 - 10:53
Как правило ответственным людям требуется ответы на следующие вопросы:
1) Это можно продавать / устанавливать / выкидывать?
2) Какова степень уверенности?
3) Как называется то, о чем одет речь?
Пишем отчет в виде Резюме.
--------------------------------------------------------------------
Версия 158/32ф.
Было выполнено 60% тестов из запланированных. Тестирование было прехращено ввиду большого числа ошибок, закрывающих доступ к тестированию.
В настоящий момент полностью неработоспособны 18 из 150 юзкейсов.
Полностью неработоспособны 3 из 45 критически важных юзкейса. Это:
Невозможно сохранение файла под тем же именем
Невозможен запуск приложения под аккаунтом с правами, менее чем у роли администратора.
Не работает справка
Работает с оговорками 93 юзкейса.
39 юзкейсов реализованы хорошо.
Я не рекомендую поставку данной версии клиентам. Версия ограничено пригодна для ознакомления с возможностями программы.
--------------------------------------------------------------------
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#10
Отправлено 18 января 2005 - 11:29
Еще бы добавить данный по метрикам, связанным непосредственно с ошибками (по статусам/приоритетам и т.д., по времени решения/открытия и т.п.) цены бы ему не было.
В общем, мое видение проблемы:
При составлении отчета
1. необходимо отталкиваться от нужд и целей, ради которых составляется отчет
2. необходимо отталкиваться от применяемых (собираемых) метрик
#11
Отправлено 18 января 2005 - 14:55
Кому отчет? Зачем? Что на его основании будут делать?
данный по метрикам, связанным непосредственно с ошибками (по статусам/приоритетам и т.д.,
Эти метрики скажут что нибудь только человеку прекрасно понимающему процесс. А, например, менеджеру по продажам ничего не скажут.
- У нас в этой версии неисправлено 15 важных 78 маловажных ошибок.
- А сколько должно быть? Вот я слышал, что продукт Х был выпущен с несколькими сотнями тысяч известных неисправленных ошибок. И очень успешный продукт. А тут всего 93. Выпускаем или нет?
Человек, же который понимает процесс и в нем участвует, должен быть подключен к системе бак трекинга. Если он управляет процессом, то эту статистику он сам должен просматривать в этой системе с некоторой периодичностью. Не ему должны поставлять такой отчет, а он должен его и сам формировать, и сам просматривать, и сам принимать решения на его основе.
Эти метрики могут понадобиться для начисления / лишения премии (увольнения / прима на работу). Т.е. дествительно, если есть такая практика, то будем формировать отчет, в который войдут:по времени решения/открытия и т.п.
процент возвратов,
среднее время исправления дефектов, с разбивкой по приоритетам, и т.д.
и не войдут:
номер версии и даже название проекта (отчет будет помесячным)
оценка работоспособности программы
Здесь мы оцениваем работника, а не проект.
В первом примере (мой предыдущий пост) отчет говорил не о том какие есть ошибки, а какого состояние проекта. Поэтому в нем должны быть метрики проекта и может не быть метрик ошибок.
Развивая тему дальше.
Мой опыт показывает, что список ошибок включать в отчет бессмысленно, его все равно никто из руководства не читает. Такой список хорош только если работник не подключен к системе бак трекинга. Например, из-за экономии денег дизайнеру интерфесов не купили компьютер.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#12 Гость_sofiya_*
Отправлено 20 января 2005 - 19:22
#13
Отправлено 23 января 2005 - 19:25
Главными пунктами в отчете должны быть:
--какие задачи были протестированы (функциональности)
--сроки проведения тестирования, кем проводилось тестирование
--найденные ошибки (с описанием критических ошибок)
--исправлены ли эти ошибки на дату подачи отчета
--обратить внимание на часто повторяющиеся ошибки (если такие есть)
--по необходимости добавить приложение со всеми тест-кейсами
Я бы к этому добавил еще:
- Описание самого процесса тестирования (что использовалось/применялось)
- Описание конфигурации на которой проводилось тестирование
- Пожелания, замечания, выводы
И получится вполне нормальный шаблон для отчета.
Более подробно - исходя из конкретной ситуации.
#14
Отправлено 02 февраля 2005 - 07:43
1. Расписание (с указанием того, кто и в какие сроки что делал)
2. Результаты по типам проведенных тестов (список протестированной ф-сти, системы, на которых смотрели, всяческие графики по performance и т.п.)
3. Заключение (самая читаемая часть), включает наши общие выводы о качестве продукта, с описанием критических вещей.
4. Приложение со списком багов и распределениями багов по severity/компонентам/времени и т.п.
#15
Отправлено 02 февраля 2005 - 08:48
В написании документа необходимо отталкиваться от того, как будет использоваться документ - его назначение. Для недельного отчета могут быть две основных задачи:
1. Оценить степень готовности продукта (прогресс разработки)
2. Оценить проделанную работу по тестированию
Прогресс - это величина динамическая и получить ее можно только сравнив результаты предыдущей недели и настоящей. Сравнивать нужно по категориям - открытые, исправленные, закрытые баги (зависит от принятой системы классификации). Если результаты перенести на график, то можно наглядно определить насколько продукт готов к выпуску. В идеальном случае кривая незакрытых багов (найденных, исправленных) должна сойтись с кривой исправленных. Другими словами к финальному релизу нужно, что бы все баги были устранены. Если это не так, то должно быть волевое решение руководства, что продукт сдается с дефектами.
График демонстрирует динамику активности на проекте. После выхода очередного билда кривая не закрытых багов обычно возрастает не линейно. Если разработчиками или тестировщиками уделяется мало внимания существующим багам, то кривая закрытых багов растет медленнее чем не закрытых.
В дополнение к графику нужно оформлять табличку: баги прошлой недели (по категориям), баги текущей недели, прирост. Данные таблицы хорошо поясняют график. (Если быть точным, то график строится на основании этой таблицы.)
Отдельным разделом описываются задачи, выполненые тестировщиками:
- состав команды и время, затраченное на проект;
- прирост подготовленных тестов (тест кейсов);
- количество выполненных тест кейсов;
- описание проблем, с которыми столкнулись в процессе тестирования и предпринятые меры;
- планы на будущую неделю;
- возможные проблемы будущей недели и пути их устранения.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных