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

1. Практические рекомендации
по использованию системы TestRail
Дмитрий Рыльцов
DRyltsov@ptsecurity.com
Алексей Васильев
AVasilev@ptsecurity.com
Группа продуктового тестирования MaxPatrol SIEM

2. Цели использования TestRail

3. Цели использования TestRail
Основные:
• Проверка Бизнес-сценариев использования продукта
• Анализ проблемной функциональности
• Анализ покрытия Требований
• Оперативный контроль за тестированием продукта
Вспомогательные:
• Сбор базы знаний по использованию продукта
• Оценка трудозатрат на тестирование

4. Сущности системы TestRail

5. Сущности TestRail: Case
Case – сценарий проверки функциональности продукта:
• Краткое описание (Цель, Предусловия, Ограничения)
• Сценарий (Шаг, Результат)
• Параметры (важные для нас):
• Type
• Priority
• Estimate
• Milestone
• References
• State
• Obsolete in

6. Сущности TestRail: Case
Просмотр Редактирование

7. Test Run – выбранный набор
Case-ов к проверке
Сущности TestRail: Test Plan / Test Run
Test Plan – объединение нескольких
Test Run в рамках одной
сущности

8. Test – зафиксированный результат проверки
Параметры (важные для нас):
• Исполнитель
• Затраченное время, Версия продукта
• Комментарий
• Дефекты
Сущности TestRail: Test

9. Особенности проекта

10. SSDL Enforcement – SDLC Integration
Особенности с которыми мы столкнулись
• Много сложной функциональности в Release
• Частое изменение функциональности
• Запаздывающая актуализация требований
• Сжатые сроки тестирование
• Поддержка нескольких старых Release одновременно
• Разработка через Feature Branch(FB)
Как результат:
• Case быстро устаревают
• Становится сложнее отслеживать актуальность Test Plan-ов
• Case между релизами сильно модифицируется
• Модификация Case пересекается в разных FB

11. Наше решение 

12. SSDL Enforcement – SDLC Integration
Наше решение: Процесс разработки Case-ов
State:
• Design – только созданный Case или он требует актуализации
• Review – проводим внутри командную проверку силами QA
• Ready – получили одобрение от коллег, аналитиков и разработки
Design Review Ready
Automated
Obsolete
• Automated – ушло в автоматизацию
• Obsolete – Case устарел

13. Наше решение: Develop и Release ветки тестов
Suite – Develop (master):
• Case-ы на разрабатываемый Release
• Case-ы на Новую функциональность
• Актуализация устаревших Case-ов
• Результаты всех Test за все внутренние
прогоны
• Управление Case-ми через параметры
Suite – Release X.Y:
• Правим Case только при изменении функциональности
 В первую очередь актуализируем в Develop и только потом уже в Release X.Y
• Храним только Release TestRun
После выпуска в Release сборки наш Develop с тестами
копируется в отдельную ветку с номером Release

14. Наше решение: Управление Case-ами
Управление Case-ами внутри Develop через параметры:
• Milestone – release когда данный Case появился или был модифицирован
• Obsolete in – release когда данный Case стал неактуален
• References – ID требований для оценки покрытия
• State – состояние Case
Какой это Case Параметры
Новый Case на FB Milestone: FeatureBranch
State: Design / Review / Ready
Новый Case влитый в Release Milestone: Release 12.0
State: Ready / Review
Старый Case не актуален с данного Release Obsolete in: Release 12.0
State: Obsolete
Case в Release требующий актуализации Milestone: Release 12.0
State: Design
Примеры:

15. Наше решение: Поиск по параметрам
TestRail предоставляет расширенный фильтр тестов при составлении Test Run

16. TestRail Integration & Customization

17. Цели интеграции
• Сократить время на поиск информации в разных системах (TFS / Wiki)
• Получать актуальную информацию о статусах дефектов прямо в тестах
• Возможность оценить проблемные участки системы с точки зрения
наличия дефектов перед выпуском сборки

18. TestRail & Team Foundation Server
REST API+
+
–
+
+
Разнообразие параметров
рабочих элементов
JSON в ответах
Множество рабочих элементов
––
Скудная документация по
плагинам
Глобальные и проектные
настройки плагинов
Нет плагина для TFS
–
Примеры готовых плагинов

19. Маппинг параметров: TFS >> TestRail
"id" : 82364,
"fields" : {
"System.Title" : "Доработка функций SIEM. Этап 0 (Поддержка формата времени SAP)",
"System.Description" : "<div><span style="font-weight:bold;">Описание и</span></div>…",
"System.TeamProject" : "MP9.vccp",
"System.State" : "In Development",
"System.AreaPath" : "MP9.vccpMPXFunctional RequirementsSIEM",
"System.Reason" : "Development is started",
"PT.FO" : "Nikolay Arefiev",
........

20. SSDL Enforcement – SDLC Integration
Дефекты и требования в тестах

21. SSDL Enforcement – SDLC Integration
Заголовки и статусы дефектов в Test Run

22. Полезные ссылки
• Документация по REST API для Team Foundation Server
https://www.visualstudio.com/en-us/docs/integrate/api/overview
• Общая информация о плагинах TestRail
http://docs.gurock.com/testrail-integration/defects-plugins
• Описание создания собственного плагина TestRail
http://docs.gurock.com/testrail-integration/defects-plugins-custom
• Модификация существующих плагинов (на примере Jira плагина)
http://docs.gurock.com/testrail-integration/defects-plugins-examples

23. Спасибо!
ptsecurity.com