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