Документация обычно содержится в тестпланах

• Название: Документация обычно содержится в тестпланах
• Дата: 12.10.2021
• Размер: 270.2 Kb.
• Имя файла: Otchyot_po_praktike-1.docx
• Тип: Документация; #246360
• страница: 4 из 10

Сборки и окружения

Для тестирования и воспроизведения дефектов важно обозначить контекст:

• 
  сборку или версию, использованную для тестирования;
  
• 
  сервер, бразуер, операционную систему и другое окружение, на котором производится тестирование.
  

Тестирование на разных окружениях вскрывает зависимости приложения от установленных компонетов или особенностей вспомогательного ПО.

Сборки можно добавлять вручную, перед началом тестирования. Однако, лучше интегрировать систему выпуска сборок (сборочный сервер, например Jenkins или TeamCity) и Devprom ALM. В этом случае, сборки (номера и пути к их расположению) будут регистрироваться автоматически по факту их выпуска. Делается это простыми командами к REST API, примеры которых приведены в контекстной справке к модулю "Сборки".

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

Окружения также можно добавлять вручную, либо при помощи REST API. Например, если ваша тестовая среда динамична, то есть используются виртуальные машины или docker-контейнеры, то окружения можно регистрировать в момент создания таких сред, перед запуском автоматических тестов.

Заполнение отчетов

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

Логи, дампы и прочие бинарные файлы можно прикладывать к отчету при помощи кнопки "+ Файл".

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

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

Тип процесса	Действия для постановки задачи на исправление
Scrum, параллельная работа над требованиями	По окончании итерации или спринта, команда разработки должна поставить качественный продукт. Для этого при планировании создается задача по тестированию. Если в процессе тестирования обнаруживается, что требование реализовано некорректно, то необходимо создать новую задачу на исправление (с типом разработка). После исправления требования, необходимо повторно проверить реализацию и, только при успешном прохождении тестов, отметить задачу по тестированию как выполненную. НЕВЕРНО отклонять требование. Это может быть сделано только на демонстрации. НЕВЕРНО отклонять задачу по разработке. Разработчик выполнил свою задачу и потратил время. Новую задачу по исправлению ошибок, возможно, будет делать другой разработчик. Вместо контроля числа отклонений, нужно контролировать величину фокус-фактора.
Kanban, последовательная работа над требованиями	При тестировании доработки ссылка на нее отображается в правой части отчета. Если обнаружена ошибка, необходимо выполнить действие "Отклонить" для данной доработки. Доработка вернется в очередь разработки, при этом с ней будет связан тестовый отчет, в результате которого доработку отклонили. Если ошибок нет, то доработку сразу можно перевести в состояние "Проверено" и списать время, затраченное на тестирование.

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