Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,974 views

Published on

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

Published in: Technology
  • Login to see the comments

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

  1. 1. Практические рекомендации по использованию системы TestRail Дмитрий Рыльцов DRyltsov@ptsecurity.com Алексей Васильев AVasilev@ptsecurity.com Группа продуктового тестирования MaxPatrol SIEM
  2. 2. Цели использования TestRail
  3. 3. Цели использования TestRail Основные: • Проверка Бизнес-сценариев использования продукта • Анализ проблемной функциональности • Анализ покрытия Требований • Оперативный контроль за тестированием продукта Вспомогательные: • Сбор базы знаний по использованию продукта • Оценка трудозатрат на тестирование
  4. 4. Сущности системы TestRail
  5. 5. Сущности TestRail: Case Case – сценарий проверки функциональности продукта: • Краткое описание (Цель, Предусловия, Ограничения) • Сценарий (Шаг, Результат) • Параметры (важные для нас): • Type • Priority • Estimate • Milestone • References • State • Obsolete in
  6. 6. Сущности TestRail: Case Просмотр Редактирование
  7. 7. Test Run – выбранный набор Case-ов к проверке Сущности TestRail: Test Plan / Test Run Test Plan – объединение нескольких Test Run в рамках одной сущности
  8. 8. Test – зафиксированный результат проверки Параметры (важные для нас): • Исполнитель • Затраченное время, Версия продукта • Комментарий • Дефекты Сущности TestRail: Test
  9. 9. Особенности проекта
  10. 10. SSDL Enforcement – SDLC Integration Особенности с которыми мы столкнулись • Много сложной функциональности в Release • Частое изменение функциональности • Запаздывающая актуализация требований • Сжатые сроки тестирование • Поддержка нескольких старых Release одновременно • Разработка через Feature Branch(FB) Как результат: • Case быстро устаревают • Становится сложнее отслеживать актуальность Test Plan-ов • Case между релизами сильно модифицируется • Модификация Case пересекается в разных FB
  11. 11. Наше решение 
  12. 12. SSDL Enforcement – SDLC Integration Наше решение: Процесс разработки Case-ов State: • Design – только созданный Case или он требует актуализации • Review – проводим внутри командную проверку силами QA • Ready – получили одобрение от коллег, аналитиков и разработки Design Review Ready Automated Obsolete • Automated – ушло в автоматизацию • Obsolete – Case устарел
  13. 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. 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. 15. Наше решение: Поиск по параметрам TestRail предоставляет расширенный фильтр тестов при составлении Test Run
  16. 16. TestRail Integration & Customization
  17. 17. Цели интеграции • Сократить время на поиск информации в разных системах (TFS / Wiki) • Получать актуальную информацию о статусах дефектов прямо в тестах • Возможность оценить проблемные участки системы с точки зрения наличия дефектов перед выпуском сборки
  18. 18. TestRail & Team Foundation Server REST API+ + – + + Разнообразие параметров рабочих элементов JSON в ответах Множество рабочих элементов –– Скудная документация по плагинам Глобальные и проектные настройки плагинов Нет плагина для TFS – Примеры готовых плагинов
  19. 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. 20. SSDL Enforcement – SDLC Integration Дефекты и требования в тестах
  21. 21. SSDL Enforcement – SDLC Integration Заголовки и статусы дефектов в Test Run
  22. 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. 23. Спасибо! ptsecurity.com

×