Практические рекомендации по использованию системы TestRail | Дмитрий Рыльцов, Алексей Васильев

1. Цели использования TestRail.
2. Сущности системы TestRail.
3. Особенности проекта.
4. Наше решение.
5. TestRail Integration & Customization.

1. Практические рекомендации по использованию системы TestRail Дмитрий Рыльцов [email protected] Алексей Васильев [email protected] Группа продуктового тестирования 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.vccp\\MPX\\Functional Requirements\\SIEM" , " 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