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