Результаты ручного тестирования оформляются в виде тестовых отчетов (или тестов). Каждый тестовый отчет состоит из набора тестовых сценариев, которые образуют позиции тестового отчета.
В позиции тестового отчета содержится копия текста исходного тестового сценария. Это позволяет параллельно заполнять разные тестовые отчеты, созданные на основе одного сценария (одновременно тестировать на разных окружениях). Можно хранить и анализировать историю ранее заполненных отчетов. А также параллельно вести доработку тестовой документации, например, под новую фичу, и заполнение тестовых отчетов, при тестировании ранее реализованной функциональности (процесс Kanban).
Если тестовый сценарий находится "В работе", то изменения в тексте отчета будут сохранены в тексте сценария.
Тестовые отчеты создаются на основе:
Чтобы указать в каком состоянии тестового сценария (или тест-плана) можно создать тестовый отчет, используйте настройку "Артефакты" на вкладке "Дополнительно" у состояния.
Для тестирования и воспроизведения дефектов важно обозначить контекст:
Тестирование на разных окружениях вскрывает зависимости приложения от установленных компонетов или особенностей вспомогательного ПО.
Сборки можно добавлять вручную, перед началом тестирования. Однако, лучше интегрировать систему выпуска сборок (сборочный сервер, например Jenkins или TeamCity) и Devprom ALM. В этом случае, сборки (номера и пути к их расположению) будут регистрироваться автоматически по факту их выпуска. Делается это простыми командами к REST API, примеры которых приведены в контекстной справке к модулю "Сборки".
По каждой сборке можно узнать какие требования были в ней реализованы, какие обнаружены дефекты, какие тестовые отчеты заполнены. По сборке можно вести обсуждения, например, на тему ее готовности к передачи на следующий этап контроля качества.
Окружения также можно добавлять вручную, либо при помощи REST API. Например, если ваша тестовая среда динамична, то есть используются виртуальные машины или docker-контейнеры, то окружения можно регистрировать в момент создания таких сред, перед запуском автоматических тестов.
В стандартной форме тестового отчета тестировщик заполняет текст сценария и в поле "Результат" отмечает статус прохождения каждого из действий. В текст сценария можно вставлять комментарии и скриншоты, поясняющие проблемы, возникшие при прохождении сценария.
Логи, дампы и прочие бинарные файлы можно прикладывать к отчету при помощи кнопки "+ Файл".
При обнаружении дефекта, его можно зарегистрировать при помощи кнопки "+ Ошибка". В описании дефекта не нужно описывать все шаги, которые привели к его обнаружению. С дефектом будет связана ссылка на позицию тестового отчета. Когда разработчик приступит к исправлению, он сможет перейти по ссылке и по отчету восстановить контекст обнаружения дефекта. Если тестовый сценарий был связан с требованием, то ошибка также будет связана с этим требованием, сообщая участникам проекта о проблемах в реализации требований.
Поскольку тестовая документация создается на основе доработок или первичных требований, с позицией тестового сценария будет связана одна или несколько доработок. Вместо того, чтобы создавать массу дефектов, причина которых в некорректной реализации конкретной доработки, необходимо поставить задачу на исправление исходной дефектной доработки. В разных процессах это можно организовать по-разному:
| Тип процесса | Действия для постановки задачи на исправление |
|---|---|
| Scrum, параллельная работа над требованиями |
По окончании итерации или спринта, команда разработки должна поставить качественный продукт. Для этого при планировании создается задача по тестированию. Если в процессе тестирования обнаруживается, что требование реализовано некорректно, то необходимо создать новую задачу на исправление (с типом разработка). После исправления требования, необходимо повторно проверить реализацию и, только при успешном прохождении тестов, отметить задачу по тестированию как выполненную. НЕВЕРНО отклонять требование. Это может быть сделано только на демонстрации. НЕВЕРНО отклонять задачу по разработке. Разработчик выполнил свою задачу и потратил время. Новую задачу по исправлению ошибок, возможно, будет делать другой разработчик. Вместо контроля числа отклонений, нужно контролировать величину фокус-фактора. |
| Kanban, последовательная работа над требованиями | При тестировании доработки ссылка на нее отображается в правой части отчета. Если обнаружена ошибка, необходимо выполнить действие "Отклонить" для данной доработки. Доработка вернется в очередь разработки, при этом с ней будет связан тестовый отчет, в результате которого доработку отклонили. Если ошибок нет, то доработку сразу можно перевести в состояние "Проверено" и списать время, затраченное на тестирование. |
Списковое представление отчета удобно для выполнения массовых операций и просмотра всех результатов по заданным критериям. Например, для ускорения тестирования по большому тест-плану, можно распределить работу между несколькими тестировщикам. Отмечайте порцию тестовых сценариев и назначайте их на конкретного тестировщика. При заполнении отчета тестировщик может отфильровать свои позиции и заполнять только их.
Тестовый отчет может быть связан с одной или несколькими задачами. Таким образом вы можете назначать работу на тестировщиков. В каждой задаче указываются плановые трудозатраты, исполнитель и фактические трудозатраты.
Назначенные тестировщику задачи отображаются в списке "Мои задачи" и в верхней части приложения, в списке ближайших задач. Распределение задач по команде, итерациям удобно осуществлять на доске задач. Зафиксируйте фильтр по типу задач, чтобы показывать доску задач тестирования.
На основе плановых трудозатрат можно просматривать загрузку участника и выявлять свободные ресурсы или определять перегрузку, с учетом вовлеченности тестировщиков в нескольких проектов. На основе фактических трудозатрат можно строить план/факт анализ.
На основании заполнения поля Длительность в тест-кейсе в конкретном отчете, система вычисляет значение Последней длительности для сценария,7 а также Средней длительности по набору ранее заполненных тестов. Используя данные показатели вы можете оценивать трудоемкость по тестированию того или иного подмножества сценариев или целиком тест-плана.