Формирование отчетной документации по результатам работ.

 

 

Цель занятия: составить итоговый отчет о результатах тестирования

приложения.

Задание:

1. Провести документирование результатов тестирования программного средства.

2. Составить отчет по лабораторной работе.

Теоретические сведения:

Итоговый отчет можно разделить на части с соответствующей информацией:

· Приветствие.

· Общая информация (Common Information).

· Тестовое окружение (Test Platform).

· Рекомендации QA (QA Recommendations).

· Детализированная информация (Detailed Information).

· Окончание содержимого.

Приветствие

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

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

Общая информация (Common Information)

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

Тестовое окружение (Test Platform)

Как правило, в этой части указываются:

· Название проекта.

· Номер сборки.

· Ссылка на проект (сборку). Необходимо убедиться, что зайдя по этой

· ссылке вы действительно попадаете на проект или можете установить приложение.

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

Рекомендации QA (QA Recommendations)

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

В этом разделе должна быть информация о следующем:

· Указан функционал (часть функционала), который заблокирован для проверки. Даны пояснения почему этот функционал не проверен (указаны наиболее критичные дефекты).

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

· Если качество сборки ухудшилось, то обязательно должны быть указаны регрессионные места.

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

· Даны рекомендации по тому функционалу и дефектам, скорейшее исправление которых является наиболее приоритетным.

· Список наиболее критичных для сборки дефектов, с указанием названия и их критичности.

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

Помимо всего вышеуказанного для релизных и предрелизных сборок в отчете о качестве продукта важно указывать следующее:

· Дана информация о всех проблемах, характерных сборке. Проведен анализ, насколько оставшиеся проблемы являются критичными для конечного пользователя.

· Указаны дефекты, которые следует исправить, чтобы качество конечной сборки было выше.

Детализированная информация (Detailed Information)

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

Smoke

При оценке качества функционала на уровне Smoke теста, оно может быть либо Приемлемым, либо Неприемлемым. Качество сборки зависит от нескольких факторов:

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

· Наличие нового функционала. Новый функционал, который впервые поставляется на тестирование, не должен содержать дефектов уровня Smoke для выставления Приемлемого качества всей сборки.

· Чтобы установить сборке Приемлемое качество, не должно быть дефектов уровня Smoke у того функционала, по которому планируется проводить полные тесты.

· Все наиболее важные части функционала отрабатывают корректно, тогда качество всего функционала на уровне Smoke может быть оценено, как Примлемое.

В части о детализированной информации качества сборки следует более подробно описать проблемы, которые были найдены во время теста.

DV

В этой части отчета указывается качество о проведении валидации дефектов.

Здесь должна быть следующая информация:

· Общее количество всех дефектов, поступивших на проверку.

· Количество неисправленных дефектов и их процент от общего количества.

· Список дефектов, которые не были проверены и причины, по которым этого не было сделано.

· Наглядная таблица с неисправленными дефектами.

По вышеуказанным результатам выставляется качество теста. Если процент неисправленных дефектов < 10%, то качество Приемлемое, если > 10%, то качество Неприемлемое.

NFT

При проведении полного теста нового функционала качество отдельно проверенного функционала может быть: Высокое, Среднее, Низкое.

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

· Дана общая оценка реализации нового функционала (сгруппированная по качеству).

· Подробная (детальная) информация о качестве каждой из частей новой функциональности.

· Проведен анализ каждой из новых функций в отдельности.

· Даны ясные пояснения о выставлении соответствующего качества.

· Даны рекомендации по улучшению качества (какие проблемы следует исправить).

· Показана таблица с новыми функциями (название), их качеством, статусом фуннкции из CQ.

AT, MAT, Regression

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

Для указанных видов тестов в данной части отчета должна быть описана информация следующего характера:

· Дана сравнительная характеристика каждой из частей функционала в сравнении с предыдущими версиями сборки.

· Подробная (детальная) информация о качестве каждой из частей проверенной функциональности.

· Даны ясные пояснения о выставлении соответствующего качества каждой функции в отдельности.

· Даны рекомендации по улучшению качества (какие проблемы следует исправить).

Окончание содержимого

В завершении содержимое отчета должно включать в себя информацию следующего характера:

· Ссылка на тест-план.

· Ссылка на документ feature matrix (если таковой имеется).

· Ссылка на документ со статистикой (если таковой имеется).

· Общее количество всех новых дефектов.

· Подпись высылающего отчет.

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

 

Выполнение работы:

1. Запустить ранее созданное приложение.

2. Составить итоговый отчет по результатам тестирования приложения.

3. Оформить отчет и защитить лабораторную работу.

Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке.

Контрольные вопросы:

1. Какая структура итогового отчета о результатах тестирования?

2. Что содержится в разделе Приветствие?

3. Что содержится в разделе Общая информация?

4. Что содержится в разделе Тестовое окружение?

5. Что содержится в разделе Рекомендации QA?

6. Что содержится в разделе Детализированная информация?

7. Что содержится в разделе Окончание содержимого?