SlideShare a Scribd company logo
1 of 31
Jira как инструмент тест-
менеджмента


February 21, 2013   www.ExigenServices.com
                                             1   www.ExigenServices.com
СОДЕРЖАНИЕ

   Краткий обзор Jira в контексте тестирования
   Зачем использовать Jira как инструмент тест-менеджмента
   Иерархия задач в Jira
   Добавление Feature Groups
   Добавление тестов в Jira
   Регрешн – оценка скоупа и времени
   Стандартные тест-практики в Джира
   Определение тестового покрытия
   Сбор тестовых метрик




                                                   2    www.ExigenServices.com
КРАТКИЙ ОБЗОР JIRA В КОНТЕКСТЕ
              ТЕСТИРОВАНИЯ
   Что такое Jira
   Что такое Компонент
   Что такое “issue” (сущность)
   Иерархия задач в Jira
   Взаимосвязь элементов Jira
   Как добавлять задачи в Jira



На примере проекта ETPONE




                                      3   www.ExigenServices.com
ЧТО ТАКОЕ JIRA


   Вся проектная информация хранится в базе данных
   Jira – тул, который позволяет нам работать с этой информацией
   Jira поддерживает типизацию данных
   Jira настраивается под нужды проекта




             DATABASE                JIRA




                                                    4    www.ExigenServices.com
ЧТО ТАКОЕ КОМПОНЕНТ



                                              Стул Медведя


               cтол



    шкаф
                      Мишуткин стульчик




скамеечка
                                              Стул Медведицы
                                          5       www.ExigenServices.com
ЧТО ТАКОЕ “ISSUE”


 “Issue” это проектная сущность в Jira
 Issue бывают разных типов, например:
   –   Bug
   –   User story
   –   Sub-task
   –   Test case
   –   Или любой другой, который вам нужен
       * Джиру можно настраивать под нужды проекта
 Не все типы issues равны 




                                                     6   www.ExigenServices.com
ИЕРАРХИЯ ЗАДАЧ В JIRA



 Jira поддерживает всего 2 уровня иерархии
 Более гибкие зависимости – с помощью линок




                                               7   www.ExigenServices.com
ВЗАИМОСВЯЗЬ ЭЛЕМЕНТОВ JIRA




         Сomponent




                      8   www.ExigenServices.com
КАК ДОБАВЛЯТЬ ЗАДАЧИ В JIRA


 Для того, чтобы добавить любой тип issue:
   – Выбрать этот тип из меню
   – Наполнить содержанием
   – Слинковать с другими задачами




                                              9   www.ExigenServices.com
ЗАЧЕМ ИСПОЛЬЗОВАТЬ JIRA ДЛЯ ТЕСТ-
             МЕНЕДЖМЕНТА

   Вся проектная информация хранится в одном месте
–   Доступна всей команде
–   Не нужно создавать отдельных аккаунтов
–   Проще отслеживать покрытие требований кейсами
–   Удобно для DMT (Development manual testing)
–   Проще поддерживать тесты




                                                10    www.ExigenServices.com
ДОБАВЛЕНИЕ ТЕСТОВ В JIRA

   Добавление типа “feature group”
   Добавление тест-кейса
   Линкование тестов
   Создание тестовых сценариев




                                      11   www.ExigenServices.com
ДОБАВЛЕНИЕ FEATURE GROUP



   Что такое Feature Group?
   Зачем нужен Feature Group?
   Пример Feature Group
   Жизненный цикл Feature Group




                                   12    www.ExigenServices.com
ЧТО ТАКОЕ FEATURE GROUP

 Feature group это контейнер тестовых задач



                                                Устойчивость
 User Interface   Юзабильность   Безопасность
                                                и прочность




                                                  13    www.ExigenServices.com
ЗАЧЕМ НУЖЕН FEATURE GROUP

 Feature group нужен для:
   – структурирования тест кейсов
   – нахождения “affected functionality”
   – создания планов регрешн тестинга




                                           14   www.ExigenServices.com
ПРИМЕР FEATURE GROUP




                       15   www.ExigenServices.com
ЖИЗНЕННЫЙ ЦИКЛ FEATURE GROUP



    У Feature group eсть всего 2 статуса:
  – Открытый (используется)
  – Закрытый (если данная группа стала неактуальна)
 Мы не можем удалять Feature Groups
 Mы можем настраивать фильтры, чтобы видеть только
  актуальные данные




                                              16      www.ExigenServices.com
ДОБАВЛЕНИЕ ТЕСТ КЕЙСА



   Как добавлять тест-кейсы
   Стандартные поля тест-кейса
   Другие полезные параметры кейса
   Состояния тест-кейса
   С чем линкуются тест-кейсы
   Как линкуются тест-кейсы




                                      17   www.ExigenServices.com
КАК ДОБАВЛЯТЬ ТЕСТ-КЕЙСЫ

 Тест-кейсы добавляются как подзадачи Feature Groups
  a) More actions->
  b) Create sub-task ->
  c) Выбрать тип Test-Case sub-task

 Кейсу можно менять родителя
  a) More actions ->
  b) Move ->
  c) Change parent
  d) Select new Parent




                                               18       www.ExigenServices.com
СТАНДАРТНЫЕ ПОЛЯ ТЕСТ-КЕЙСА


   Summary – имя тест-кейса
   Preconditions – входные условия
   Entry point
   Actions – шаги теста
   Expected result – ожидаемый результат
   Priority – Приоритет (от блокера до trivial)




                                                   19   www.ExigenServices.com
ДРУГИЕ ПОЛЕЗНЫЕ ПОЛЯ

 Parameters
   – Автоматизирован
   – Зависит от браузера
   – Зависит от локали

 Components
   К какому/каким из компонентов кейс относится

 Original estimate
   Примерное время на прохождение теста.
   Зависит от Parameters


                                                  20   www.ExigenServices.com
СОСТОЯНИЯ ТЕСТ-КЕЙСА


   Open
   Reopen
   Passed
   Failed
   Blocked
   Deprecated




                                    21   www.ExigenServices.com
С ЧЕМ ЛИНКУЮТСЯ ТЕСТ-КЕЙСЫ


Тест кейсы линкуются с:
 User stories
   – Для оценки тестового покрытия
   – Для создания тест-планов
 Саб-таскам, как
   – DMT (developer manual testing)
   – Test execution (в качестве тест-плана)
 Багам
   – Для удобства восприятия
   – Для создания дополнительного тест-кейса
   – Для более детального повторного прохождения


                                               22   www.ExigenServices.com
КАК ЛИНКУЮТСЯ ТЕСТ-КЕЙСЫ

 Чтобы залинковать кейс:
  а) More Actions ->
  b) Link ->
  c) Выбрать тип связи (executes) ->
  d) Выбрать один или несколько Issues




                                         23   www.ExigenServices.com
СТАНДАРТНЫЕ ТЕСТ-ПРАКТИКИ В JIRA

   Создание тест плана
   Определение тестового покрытия
   Практика ДМТ
   Поддержка тест-кейсов
   Оценка скоупа регрешена
   Оценка времни для регрешн тестинга
   Сбор тестовых метрик




                                         24   www.ExigenServices.com
СОЗДАНИЕ ПЛАНА ТЕСТИРОВАНИЯ

 Для юзер-стори:
   – Открываем юзер стори
   – Читаем и анализируем требования
   – Открываем подзадачу Test-execution
   – Перечисляем всё, что нужно протестировать
   – Заходим в Feature Groups
   – Линкуем уже существующие тесты к нашей стори
   – Создаем тесты, которых еще нет
   – Линкуем

   В итоге, получаем список линок на тесты.
   Это и будет планом тестирования.
   .
                                              25    www.ExigenServices.com
ОПРЕДЕЛЕНИЕ ТЕСТОВОГО ПОКРЫТИЯ

 Каждаю юзер стори имеет список требований
 Каждая тестовая подзадача тоже =>
 Залинковав тесты к
   а) Подзадаче
   б) Основной юзер-стори
 мы гарантируем полное тестовое покрытие.

Список тестов доступен всей команде и заказчику.




                                                   26   www.ExigenServices.com
ПРАКТИКА DMT

 DMT = Developer Manual Testing
 Уменьшает количество багов
 Дает общее видение функциональности
   – Тестеры дают список тестов
   – Девелоперы проходят тесты сами

    Такска DMT асайнится на разработчика




                                            27   www.ExigenServices.com
ПОДДЕРЖКА ТЕСТ КЕЙСОВ

 При изменении требований, находим affected кейсы в Feature
  группах
 Так как базовые кейсы являются entry points, достаточно
  одного изменения
 История изменения кейса доступна
 При регрешн-тестировании – перепроверка актуальности




                                                28    www.ExigenServices.com
ОЦЕНКА СКОУПА РЕГРЕШН ТЕСТИНГА



 Открыть Featrue groups
 Выбрать тесты высшего приоритета по текущей
  функциональности
 С помощью филтров, выбрать все аксептенс тесты
 Слинковать с задачей регрешн




                                              29   www.ExigenServices.com
ОЦЕНКА ВРЕМЕНИ НА РЕГРЕШН

 Определить глубину тестирования
   – Проверить параметры тест-кейса
   – Выделить самые важные параметры
    Время на прохождение*к-во параметров
    Суммировать время всех тестов
    При необходимости:
   – Уменьшить количество параметров
   – Сделать выборку самых важных тестов




                                            30   www.ExigenServices.com
СБОР ТЕСТОВЫХ МЕТРИК



Как собирать тестовые метрики:
 Настроить и расшарить фильтры для
   – Acceptance кейсов
   – Автоматизированных кейсов
   – Общего количества кейсов
   – Пройденных за неделю
   – Упавших за неделю и т.д

i.e: project = ESR AND component in (Rejta, EMPTY) AND issuetype
    = "Test Case sub-task" AND status !=Deprecated AND priority =
    Blocker


                                                    31   www.ExigenServices.com

More Related Content

What's hot

მადლობის სიგელი
მადლობის სიგელიმადლობის სიგელი
მადლობის სიგელი
Maia Siradze
 
REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁
mkoszk
 
SteelEye 표준 제안서
SteelEye 표준 제안서SteelEye 표준 제안서
SteelEye 표준 제안서
Yong-uk Choe
 

What's hot (20)

「UI自動テストツールとAI」〜AIを使った自動テストの「今」と「未来」〜
「UI自動テストツールとAI」〜AIを使った自動テストの「今」と「未来」〜「UI自動テストツールとAI」〜AIを使った自動テストの「今」と「未来」〜
「UI自動テストツールとAI」〜AIを使った自動テストの「今」と「未来」〜
 
モデリングもしないでアジャイルとは何事だ
モデリングもしないでアジャイルとは何事だモデリングもしないでアジャイルとは何事だ
モデリングもしないでアジャイルとは何事だ
 
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
 
მადლობის სიგელი
მადლობის სიგელიმადლობის სიგელი
მადლობის სიგელი
 
Qlik Tips: 実践!ExcelDataの抽出と加工.pptx
Qlik Tips: 実践!ExcelDataの抽出と加工.pptxQlik Tips: 実践!ExcelDataの抽出と加工.pptx
Qlik Tips: 実践!ExcelDataの抽出と加工.pptx
 
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
 
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
 
ソフトウェア技術者のキャリアパスを考える ~ 技術者になるための戦略・戦術・作戦術
ソフトウェア技術者のキャリアパスを考える ~ 技術者になるための戦略・戦術・作戦術ソフトウェア技術者のキャリアパスを考える ~ 技術者になるための戦略・戦術・作戦術
ソフトウェア技術者のキャリアパスを考える ~ 技術者になるための戦略・戦術・作戦術
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
 
私にとってのテスト
私にとってのテスト私にとってのテスト
私にとってのテスト
 
Adamiani da garemo
Adamiani da garemoAdamiani da garemo
Adamiani da garemo
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
 
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
 
C#エンジニアのためのdocker kubernetesハンズオン (再)
C#エンジニアのためのdocker kubernetesハンズオン (再)C#エンジニアのためのdocker kubernetesハンズオン (再)
C#エンジニアのためのdocker kubernetesハンズオン (再)
 
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCIどうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCI
 
მეგობრები არ ითვლიან ქრომოსომებს - სასპონსორო შეთავაზება
მეგობრები არ ითვლიან ქრომოსომებს - სასპონსორო შეთავაზებამეგობრები არ ითვლიან ქრომოსომებს - სასპონსორო შეთავაზება
მეგობრები არ ითვლიან ქრომოსომებს - სასპონსორო შეთავაზება
 
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
 
REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁
 
CI / CD ( 지속적인 통합 / 지속적인 전달 ) 발표 자료 다운로드
CI / CD ( 지속적인 통합 / 지속적인 전달 ) 발표 자료 다운로드CI / CD ( 지속적인 통합 / 지속적인 전달 ) 발표 자료 다운로드
CI / CD ( 지속적인 통합 / 지속적인 전달 ) 발표 자료 다운로드
 
SteelEye 표준 제안서
SteelEye 표준 제안서SteelEye 표준 제안서
SteelEye 표준 제안서
 

Viewers also liked

Profsoux2014 presentation by Pavelchuk
Profsoux2014 presentation by PavelchukProfsoux2014 presentation by Pavelchuk
Profsoux2014 presentation by Pavelchuk
Return on Intelligence
 
Тест-менеджмент в Jira. Анна Добрынина
Тест-менеджмент в Jira. Анна ДобрынинаТест-менеджмент в Jira. Анна Добрынина
Тест-менеджмент в Jira. Анна Добрынина
qasib
 

Viewers also liked (20)

Non Blocking Algorithms at Traffic Conditions
Non Blocking Algorithms at Traffic ConditionsNon Blocking Algorithms at Traffic Conditions
Non Blocking Algorithms at Traffic Conditions
 
Time Management
Time ManagementTime Management
Time Management
 
Successful interview for a young IT specialist
Successful interview for a young IT specialistSuccessful interview for a young IT specialist
Successful interview for a young IT specialist
 
Profsoux2014 presentation by Pavelchuk
Profsoux2014 presentation by PavelchukProfsoux2014 presentation by Pavelchuk
Profsoux2014 presentation by Pavelchuk
 
Quality Principles
Quality PrinciplesQuality Principles
Quality Principles
 
Introduction to python
Introduction to pythonIntroduction to python
Introduction to python
 
Agile Project Grows
Agile Project GrowsAgile Project Grows
Agile Project Grows
 
Windows Azure: Quick start
Windows Azure: Quick startWindows Azure: Quick start
Windows Azure: Quick start
 
Apache Maven presentation from BitByte conference
Apache Maven presentation from BitByte conferenceApache Maven presentation from BitByte conference
Apache Maven presentation from BitByte conference
 
English for E-mails
English for E-mailsEnglish for E-mails
English for E-mails
 
Apache Maven 2 Part 2
Apache Maven 2 Part 2Apache Maven 2 Part 2
Apache Maven 2 Part 2
 
How to develop your creativity
How to develop your creativityHow to develop your creativity
How to develop your creativity
 
Large Scale Software Project
Large Scale Software ProjectLarge Scale Software Project
Large Scale Software Project
 
Introduction to XML
Introduction to XMLIntroduction to XML
Introduction to XML
 
Service design principles and patterns
Service design principles and patternsService design principles and patterns
Service design principles and patterns
 
Risk Management
Risk ManagementRisk Management
Risk Management
 
Тест-менеджмент в Jira. Анна Добрынина
Тест-менеджмент в Jira. Анна ДобрынинаТест-менеджмент в Jira. Анна Добрынина
Тест-менеджмент в Jira. Анна Добрынина
 
Principles of personal effectiveness
Principles of personal effectivenessPrinciples of personal effectiveness
Principles of personal effectiveness
 
Atlassian jira как полностью раскрыть возможности
Atlassian jira   как полностью раскрыть возможностиAtlassian jira   как полностью раскрыть возможности
Atlassian jira как полностью раскрыть возможности
 
Cross-cultural communication
Cross-cultural communicationCross-cultural communication
Cross-cultural communication
 

Similar to Jira as a test management tool

Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
solit
 
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2SeleniumAgile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
jazzteam
 
TestLink
TestLinkTestLink
TestLink
ISsoft
 
Simonova CSEDays
Simonova CSEDaysSimonova CSEDays
Simonova CSEDays
LiloSEA
 
Katerina Simonova CSEDays
Katerina Simonova CSEDaysKaterina Simonova CSEDays
Katerina Simonova CSEDays
LiloSEA
 

Similar to Jira as a test management tool (20)

Jira as a test management tool
Jira as a test management toolJira as a test management tool
Jira as a test management tool
 
JUnit, дай пять!
JUnit, дай пять!JUnit, дай пять!
JUnit, дай пять!
 
AUG-5: Testing tools
AUG-5: Testing toolsAUG-5: Testing tools
AUG-5: Testing tools
 
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
 
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2SeleniumAgile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
Agile Java Development компания JazzTeam - Техническая презентация Xml2Selenium
 
Solit 2013, Разбор конкретного примера – продукта XML2Selenium, Горячко Дмитрий
Solit 2013, Разбор конкретного примера – продукта XML2Selenium, Горячко ДмитрийSolit 2013, Разбор конкретного примера – продукта XML2Selenium, Горячко Дмитрий
Solit 2013, Разбор конкретного примера – продукта XML2Selenium, Горячко Дмитрий
 
TestLink
TestLinkTestLink
TestLink
 
Вадим Зубович - Test Link
Вадим Зубович - Test LinkВадим Зубович - Test Link
Вадим Зубович - Test Link
 
Simonova sql server-enginetesting
Simonova sql server-enginetestingSimonova sql server-enginetesting
Simonova sql server-enginetesting
 
Практические рекомендации по использованию системы TestRail | Дмитрий Рыльцов...
Практические рекомендации по использованию системы TestRail | Дмитрий Рыльцов...Практические рекомендации по использованию системы TestRail | Дмитрий Рыльцов...
Практические рекомендации по использованию системы TestRail | Дмитрий Рыльцов...
 
Дело тестера боится: как в опытных руках могут заиграть Java и TestNg
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgДело тестера боится: как в опытных руках могут заиграть Java и TestNg
Дело тестера боится: как в опытных руках могут заиграть Java и TestNg
 
"Опыт создания системы управления сборкой и тестированием" (полная)
"Опыт создания системы управления сборкой и тестированием" (полная)"Опыт создания системы управления сборкой и тестированием" (полная)
"Опыт создания системы управления сборкой и тестированием" (полная)
 
Организация процесса ручного тестирования
Организация процесса ручного тестированияОрганизация процесса ручного тестирования
Организация процесса ручного тестирования
 
ReqLabs PechaKucha Евгений Сафроненко
ReqLabs PechaKucha Евгений СафроненкоReqLabs PechaKucha Евгений Сафроненко
ReqLabs PechaKucha Евгений Сафроненко
 
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...
 
Building Open Source Test Automation Frameworks. Watir based automation case ...
Building Open Source Test Automation Frameworks. Watir based automation case ...Building Open Source Test Automation Frameworks. Watir based automation case ...
Building Open Source Test Automation Frameworks. Watir based automation case ...
 
Как построить свой фреймворк для автотестов?
Как построить свой фреймворк для автотестов?Как построить свой фреймворк для автотестов?
Как построить свой фреймворк для автотестов?
 
Сергей Ревко
Сергей РевкоСергей Ревко
Сергей Ревко
 
Simonova CSEDays
Simonova CSEDaysSimonova CSEDays
Simonova CSEDays
 
Katerina Simonova CSEDays
Katerina Simonova CSEDaysKaterina Simonova CSEDays
Katerina Simonova CSEDays
 

More from Return on Intelligence

Types of testing and their classification
Types of testing and their classificationTypes of testing and their classification
Types of testing and their classification
Return on Intelligence
 
Организация внутренней системы обучения
Организация внутренней системы обученияОрганизация внутренней системы обучения
Организация внутренней системы обучения
Return on Intelligence
 

More from Return on Intelligence (14)

Types of testing and their classification
Types of testing and their classificationTypes of testing and their classification
Types of testing and their classification
 
Differences between Testing in Waterfall and Agile
Differences between Testing in Waterfall and AgileDifferences between Testing in Waterfall and Agile
Differences between Testing in Waterfall and Agile
 
Windows azurequickstart
Windows azurequickstartWindows azurequickstart
Windows azurequickstart
 
Организация внутренней системы обучения
Организация внутренней системы обученияОрганизация внутренней системы обучения
Организация внутренней системы обучения
 
Shared position in a project: testing and analysis
Shared position in a project: testing and analysisShared position in a project: testing and analysis
Shared position in a project: testing and analysis
 
Introduction to Business Etiquette
Introduction to Business EtiquetteIntroduction to Business Etiquette
Introduction to Business Etiquette
 
Agile Testing Process
Agile Testing ProcessAgile Testing Process
Agile Testing Process
 
Оценка задач выполняемых по итеративной разработке
Оценка задач выполняемых по итеративной разработкеОценка задач выполняемых по итеративной разработке
Оценка задач выполняемых по итеративной разработке
 
Meetings arranging
Meetings arrangingMeetings arranging
Meetings arranging
 
The art of project estimation
The art of project estimationThe art of project estimation
The art of project estimation
 
Resolving conflicts
Resolving conflictsResolving conflicts
Resolving conflicts
 
Velocity как инструмент планирования и управления проектом
Velocity как инструмент планирования и управления проектомVelocity как инструмент планирования и управления проектом
Velocity как инструмент планирования и управления проектом
 
Testing your code
Testing your codeTesting your code
Testing your code
 
Reports Project
Reports ProjectReports Project
Reports Project
 

Jira as a test management tool

  • 1. Jira как инструмент тест- менеджмента February 21, 2013 www.ExigenServices.com 1 www.ExigenServices.com
  • 2. СОДЕРЖАНИЕ  Краткий обзор Jira в контексте тестирования  Зачем использовать Jira как инструмент тест-менеджмента  Иерархия задач в Jira  Добавление Feature Groups  Добавление тестов в Jira  Регрешн – оценка скоупа и времени  Стандартные тест-практики в Джира  Определение тестового покрытия  Сбор тестовых метрик 2 www.ExigenServices.com
  • 3. КРАТКИЙ ОБЗОР JIRA В КОНТЕКСТЕ ТЕСТИРОВАНИЯ  Что такое Jira  Что такое Компонент  Что такое “issue” (сущность)  Иерархия задач в Jira  Взаимосвязь элементов Jira  Как добавлять задачи в Jira На примере проекта ETPONE 3 www.ExigenServices.com
  • 4. ЧТО ТАКОЕ JIRA  Вся проектная информация хранится в базе данных  Jira – тул, который позволяет нам работать с этой информацией  Jira поддерживает типизацию данных  Jira настраивается под нужды проекта DATABASE JIRA 4 www.ExigenServices.com
  • 5. ЧТО ТАКОЕ КОМПОНЕНТ  Стул Медведя cтол шкаф Мишуткин стульчик скамеечка Стул Медведицы 5 www.ExigenServices.com
  • 6. ЧТО ТАКОЕ “ISSUE”  “Issue” это проектная сущность в Jira  Issue бывают разных типов, например: – Bug – User story – Sub-task – Test case – Или любой другой, который вам нужен * Джиру можно настраивать под нужды проекта  Не все типы issues равны  6 www.ExigenServices.com
  • 7. ИЕРАРХИЯ ЗАДАЧ В JIRA  Jira поддерживает всего 2 уровня иерархии  Более гибкие зависимости – с помощью линок 7 www.ExigenServices.com
  • 8. ВЗАИМОСВЯЗЬ ЭЛЕМЕНТОВ JIRA Сomponent 8 www.ExigenServices.com
  • 9. КАК ДОБАВЛЯТЬ ЗАДАЧИ В JIRA  Для того, чтобы добавить любой тип issue: – Выбрать этот тип из меню – Наполнить содержанием – Слинковать с другими задачами 9 www.ExigenServices.com
  • 10. ЗАЧЕМ ИСПОЛЬЗОВАТЬ JIRA ДЛЯ ТЕСТ- МЕНЕДЖМЕНТА  Вся проектная информация хранится в одном месте – Доступна всей команде – Не нужно создавать отдельных аккаунтов – Проще отслеживать покрытие требований кейсами – Удобно для DMT (Development manual testing) – Проще поддерживать тесты 10 www.ExigenServices.com
  • 11. ДОБАВЛЕНИЕ ТЕСТОВ В JIRA  Добавление типа “feature group”  Добавление тест-кейса  Линкование тестов  Создание тестовых сценариев 11 www.ExigenServices.com
  • 12. ДОБАВЛЕНИЕ FEATURE GROUP  Что такое Feature Group?  Зачем нужен Feature Group?  Пример Feature Group  Жизненный цикл Feature Group 12 www.ExigenServices.com
  • 13. ЧТО ТАКОЕ FEATURE GROUP  Feature group это контейнер тестовых задач Устойчивость User Interface Юзабильность Безопасность и прочность 13 www.ExigenServices.com
  • 14. ЗАЧЕМ НУЖЕН FEATURE GROUP  Feature group нужен для: – структурирования тест кейсов – нахождения “affected functionality” – создания планов регрешн тестинга 14 www.ExigenServices.com
  • 15. ПРИМЕР FEATURE GROUP 15 www.ExigenServices.com
  • 16. ЖИЗНЕННЫЙ ЦИКЛ FEATURE GROUP  У Feature group eсть всего 2 статуса: – Открытый (используется) – Закрытый (если данная группа стала неактуальна)  Мы не можем удалять Feature Groups  Mы можем настраивать фильтры, чтобы видеть только актуальные данные 16 www.ExigenServices.com
  • 17. ДОБАВЛЕНИЕ ТЕСТ КЕЙСА  Как добавлять тест-кейсы  Стандартные поля тест-кейса  Другие полезные параметры кейса  Состояния тест-кейса  С чем линкуются тест-кейсы  Как линкуются тест-кейсы 17 www.ExigenServices.com
  • 18. КАК ДОБАВЛЯТЬ ТЕСТ-КЕЙСЫ  Тест-кейсы добавляются как подзадачи Feature Groups a) More actions-> b) Create sub-task -> c) Выбрать тип Test-Case sub-task  Кейсу можно менять родителя a) More actions -> b) Move -> c) Change parent d) Select new Parent 18 www.ExigenServices.com
  • 19. СТАНДАРТНЫЕ ПОЛЯ ТЕСТ-КЕЙСА  Summary – имя тест-кейса  Preconditions – входные условия  Entry point  Actions – шаги теста  Expected result – ожидаемый результат  Priority – Приоритет (от блокера до trivial) 19 www.ExigenServices.com
  • 20. ДРУГИЕ ПОЛЕЗНЫЕ ПОЛЯ  Parameters – Автоматизирован – Зависит от браузера – Зависит от локали  Components К какому/каким из компонентов кейс относится  Original estimate Примерное время на прохождение теста. Зависит от Parameters 20 www.ExigenServices.com
  • 21. СОСТОЯНИЯ ТЕСТ-КЕЙСА  Open  Reopen  Passed  Failed  Blocked  Deprecated 21 www.ExigenServices.com
  • 22. С ЧЕМ ЛИНКУЮТСЯ ТЕСТ-КЕЙСЫ Тест кейсы линкуются с:  User stories – Для оценки тестового покрытия – Для создания тест-планов  Саб-таскам, как – DMT (developer manual testing) – Test execution (в качестве тест-плана)  Багам – Для удобства восприятия – Для создания дополнительного тест-кейса – Для более детального повторного прохождения 22 www.ExigenServices.com
  • 23. КАК ЛИНКУЮТСЯ ТЕСТ-КЕЙСЫ  Чтобы залинковать кейс: а) More Actions -> b) Link -> c) Выбрать тип связи (executes) -> d) Выбрать один или несколько Issues 23 www.ExigenServices.com
  • 24. СТАНДАРТНЫЕ ТЕСТ-ПРАКТИКИ В JIRA  Создание тест плана  Определение тестового покрытия  Практика ДМТ  Поддержка тест-кейсов  Оценка скоупа регрешена  Оценка времни для регрешн тестинга  Сбор тестовых метрик 24 www.ExigenServices.com
  • 25. СОЗДАНИЕ ПЛАНА ТЕСТИРОВАНИЯ  Для юзер-стори: – Открываем юзер стори – Читаем и анализируем требования – Открываем подзадачу Test-execution – Перечисляем всё, что нужно протестировать – Заходим в Feature Groups – Линкуем уже существующие тесты к нашей стори – Создаем тесты, которых еще нет – Линкуем В итоге, получаем список линок на тесты. Это и будет планом тестирования. . 25 www.ExigenServices.com
  • 26. ОПРЕДЕЛЕНИЕ ТЕСТОВОГО ПОКРЫТИЯ  Каждаю юзер стори имеет список требований  Каждая тестовая подзадача тоже =>  Залинковав тесты к а) Подзадаче б) Основной юзер-стори мы гарантируем полное тестовое покрытие. Список тестов доступен всей команде и заказчику. 26 www.ExigenServices.com
  • 27. ПРАКТИКА DMT  DMT = Developer Manual Testing  Уменьшает количество багов  Дает общее видение функциональности – Тестеры дают список тестов – Девелоперы проходят тесты сами  Такска DMT асайнится на разработчика 27 www.ExigenServices.com
  • 28. ПОДДЕРЖКА ТЕСТ КЕЙСОВ  При изменении требований, находим affected кейсы в Feature группах  Так как базовые кейсы являются entry points, достаточно одного изменения  История изменения кейса доступна  При регрешн-тестировании – перепроверка актуальности 28 www.ExigenServices.com
  • 29. ОЦЕНКА СКОУПА РЕГРЕШН ТЕСТИНГА  Открыть Featrue groups  Выбрать тесты высшего приоритета по текущей функциональности  С помощью филтров, выбрать все аксептенс тесты  Слинковать с задачей регрешн 29 www.ExigenServices.com
  • 30. ОЦЕНКА ВРЕМЕНИ НА РЕГРЕШН  Определить глубину тестирования – Проверить параметры тест-кейса – Выделить самые важные параметры  Время на прохождение*к-во параметров  Суммировать время всех тестов  При необходимости: – Уменьшить количество параметров – Сделать выборку самых важных тестов 30 www.ExigenServices.com
  • 31. СБОР ТЕСТОВЫХ МЕТРИК Как собирать тестовые метрики:  Настроить и расшарить фильтры для – Acceptance кейсов – Автоматизированных кейсов – Общего количества кейсов – Пройденных за неделю – Упавших за неделю и т.д i.e: project = ESR AND component in (Rejta, EMPTY) AND issuetype = "Test Case sub-task" AND status !=Deprecated AND priority = Blocker 31 www.ExigenServices.com

Editor's Notes

  1. Этот тренинг предназначен для тестировщиков, Разработчиков, Менеджеров проектов, Конфигурейшн менеджеров и всех, кому интересно, как пользоваться джирой для хранения тест-кейсов. Цель этого тренинга, показать, как можно добавлять, структурировать и использовать тесты в джире, Собирать тестовые метрики наряду с проектными и определять качество продукта с помощью обычных фильтров.
  2. В этой презентации я расскажу: Что такое Jira в контектсе тестирования Зачем использовать для хранения тест-кейсов джиру Как создавать, хранить и поддерживать тест-кейсы Как структурировать кейсы в джире Как создавать тест план Как выбрать тесты и оценить время на регрессионное тестирование О жизненном цикле теста Об использовании стандартных тест – практик в Jira Об отслеживании покрытия требований тест кейсами О сборе тестовых метрик Проект, как и любой из наших в Джире, состоит из набора юзер сторей и соответствующих подзадач. Я специально создала проект, не имеющий никакого отношения к IT сфере, чтобы не отвлекать внимание на технические моменты. https://jira.exigenservices.com/browse/ETPONE (все стори в фильтре all stories)
  3. Любая баг-трекинговая система – удобный интерфейс к базе данных ошибок. За исключением того, что работает не только с багами, но и всей проектной информацией, как требования, чейнд-реквесты, компоненты и даже тест кейсы. Основное преимущество джиры в том, что она позволяет структурировать проет, раздробив его на модули, а модули в свою очередь на более мелкие единицы – юзер стори. Данные в джира могут быть разных типов. В зависимости от типа данных, нам доступны с этими данными разные действия.
  4. Как я уже сказала, Jira позволяет дробить проект на логические компоненты. Например, задача нашего проекта – сделать кухонную мебель для 3х медведей из сказки. Сначала мы перечисляем все основные предметы мебели, которые должны сделать. Это и будет компонентами, или модулями нашего проекта. https://jira.exigenservices.com/browse/ETPONE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel
  5. Чтобы реализовать компонент, нужно выполнить множество задач. Задачи в Jira o дним словом называются issue. Issue могут быть разных типов – Юзер стори, бага, саб-таска и так далее. Основная разница между ними в том, что одни из них являются конкретной задачей минимального размера, которую может выполнить один человек, а другие, контейнерами для этих мелких выполнимых задач. Вот пример основных « user stories » проекта: https://jira.exigenservices.com/secure/IssueNavigator.jspa?mode=hide&requestId=25613 Например, мы у нас есть issue типа юзер стори – построить стул-качалку для Мишутки https://jira.exigenservices.com/browse/ETPONE-3 Это задача-контейнер, которая дробится на более мелкие подзадачи (или же, мелкие задачи наследуются от задачи-контейнера). Пока все задачи не выполнены, основная тоже не считается выполненной. И есть «недробимые» типы – подзадачи, как забить гвоздь или, например, покрыть стул лаком. Создать подзадачу для подзадачи невозможно.
  6. Как я уже говорила выше, есть задачи контейнеры, от которых наследуются подзадачи Любой набор данных должен быть структурирован Для структурирования данных в джира используются всего 2 уровня иерархии Более гибкой структуры можно добиться с помощью использования линок ( issue любого типа могут линковаться с issue любого типа)
  7. Ключевым для проекта является сущность «Компонент» (или модуль) Все сущности джира связаны между собой А) отношением родитель-ребенок Б) линками. Поэтому вероятность «потерять» какой-либо нужный кусок практически равна нулю.
  8. https://jira.exigenservices.com/browse/ETPONE Как я уже говорила, мы можем «настраивать» свой проект и определять, какой набор задач нам нужен. В некоторых проектах нужны чейндж реквесты, риски и так далее.
  9. M ы можем хранить всю проектную информацию в одном месте Информация доступна всей команде Ta ким образом, не нужно создавать отдельные аккаунты для отдельного тест-тула, вся команда, включая разработчиков, может видить все кейсы через джиру. Проще отслеживать покрытие требований тест кейсами. Это очень полезно, когда на проекте используется практика ДМТ – Development manual testing. Легче обновлять тесты по мере изменения требований Обо всем этом речь пойдет дальше Проще собирать метрики по продукту, так как вся необходимая информация хранится в одном месте и собирается на уровне фильтров. Например, мы легко можем узнать, сколько тестов было пройдено за неделю, сколько из них упало, сколько было автоматизировано, и сколько устарело. Проще оценивать время на прохождения регрешн-тестинга.
  10. Добавляем тип задачи « Feature group » Добавляет сам тест кейс, как сабтаску к feature group Линкуем тест-кейсы (саб-таски) к сторям Линкуем feature group к сторям Используем стандартный воркфлоу в Джире (или кастомизируем его)
  11. Мы обсудим: что такое Feature group , и зачем он нужен И какой у него жизненный цикл Второй - куда писать кейсы и как их структурировать.
  12. На слайде 5 мы говорили о том, что такое Компонент (логическая единица или модули, на которые мы делим наш проект) https://jira.exigenservices.com/browse/ETPONE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel Feature Group делает примерно то же самое, но для тестов https://jira.exigenservices.com/secure/IssueNavigator.jspa?mode=hide&requestId=25614 Как мы видим, у компонентов проекта можно выделить общие модули для тестирования. К каждому из тестовых модулей ( Feature Group) мы добавляем соответствующие тест-кейсы.
  13. Нам нужно структурировать наши тесты, но в Jira есть всего два уровня: Основная задача и подзадача. Для того, чтобы иметь структуру тестов в джире, мы создаем «условную единицу» – Feature group ( в данном случае, мы выделили основные общие параметры, по которым мы будем тестировать каждый из компонентов). https://jira.exigenservices.com/secure/IssueNavigator.jspa?mode=hide&requestId=25615 Единственное, что нам нужно от Feature group – это возможность давать ему название и создавать тест-кейсы в виде саб-тасок (об этом позже).
  14. https://jira.exigenservices.com/browse/ETPONE-72 В нашем проекте есть определенные явно-указанные требования к надежности (разные, для каждого из компонентов) А также неявно указанные требования – как защита от термитов и рассыхание мебели. Если требования на надежность разные для каждого из компонентов, мы добавляем отдельные тесты. Если есть тест, который одновременно относится к каждому из компонентов (как защита от термитов и рассыхания), нет нужды клонировать его. Достаточно слинковать его с соответствующей юзер-стори. Если требования на прочность поменялись, нам не нужно искать стори, к которой были привязаны тесты. Мы заходим в нашу Feature группу и модифицируем то, что есть. Если нас просят построить еще один предмет мебели, мы проходимся по Feature группам, реюзаем что есть, добавляем чего нет и полностью уверены, что ничего не забыли.
  15. У Feature Group есть всего 2 состояния: Открытый и Закрытый. Открытый – значит, что данная функциональность сейчас актуальна. Закрытый – что функциональность больше не используется. Мы не можем удалять компоненты, зато имеем возможность их переоткрывать, вместе с тест кейсами.
  16. Тест-кейсы добавляются как подзадачи к Feature Groups https://jira.exigenservices.com/browse/ETPONE-73 Если есть сомнения, к какой из Feature групп добавлять кейс – ничего страшного. Кейсу всегда можно поменять родителя. https://jira.exigenservices.com/browse/ETPONE-78
  17. Стандартные поля тест кейса: Summary – собственно, название тест кейса 2) Preconditions – Например, если мы хотим проверить качество краски, предусловием для нас является то, что стол готов, покрашен и высох (указывать в качестве прекондишена, что какой-либо кейс уже пройден – не очень хороший тон, так как тест, на который мы сслыаемся, может быть изменен) 3) Entry point – например, мы находимся на определенной странице нашего приложения. Entry point можно делать ссылкой на тест. Если приходит новый тестер и не знает, как добраться до какой-либо страницы, он пройдет по ссылке и всё сразу поймет. Приоритет – Blocker, Critical, Major, Minor, Trivial Если мы указвыаем тесту приоритет блокер, мы, тем самым, говорим, что это один из аксептенс тестов. Есть смысл проходить все кейсы с таким приоритетом перед каждым релизом.
  18. Parameters – параметры – набор чек боксов – A втоматизирован, Завист от браузера (может вести себя по разному в разынх браузерах), Зависит от локали – т.е отображение в разных локалях (языках) приложения может быть разным Компонент - принадлежность теста к какому-либо компоненту Грубая оценка времени на прохождение теста. В случае, если проставлена галочка browser dependent оценка умножается на количество браузеров. Если тест зависит от локали – на количество локалей
  19. 1) Изначально, при создании, тест кейс находится в состоянии О pen. При прохождении кейса ему дается статус passed, failed Если кейс открыт, значит, он не проходился Если кейс переоткрыт, значит, его снова надо пройти. Переоткрытие удобно при составлении тест плана. Например, у нас есть 2 дня на регрессионное тестирование и список тестов. https://jira.exigenservices.com/browse/ETPONE-99 Рядом с каждым тестом есть значок, который указывает текущее состояние. Например: Упал, пройден, не проходился. Чтобы не забыть, что мы уже смотрели, а что нет (особенно если на проекте больше 1 тестера), перед началом тестирования все кейсы переводятся в состояние реопен. Если у кейса состояние НЕ опен, значит, его уже проходили в этой задаче. История тест кейса (и его статусов) хранится во вкладке Activity – History 2) Если тест кейс уже не актуален, удалять его мы не можем, но можем переводить в состояние Deprecated (устаревший) И использовать фильтры, чтобы они не показывали тесты такого типа. Если удаленный кусок функциональности приложения был восстановлен, мы восстанавливаем и все deprecated тесты.
  20. Итак, тест кейсы имеет смысл линковать с Юзер сторями – чтобы понять, какой набор тестов нужно пройти для полного тестирования функциональности С саб-тасками, например – DMT. DMT – это development manual testing – набор самых приоритетных тестов, которые проходит девелопер, прежде чем отдать задачу на тестирование. Или с саб-таской test execution. Бывает, что юзер стори декомпозируется на разные под-задачи, которые выполняют разные разработчики. https://jira.exigenservices.com/browse/ETPONE-66 Тогда тестер проводит тестирование этих задач по отдельности. Открывая задачу test execution , тестер сразу видит, какой набор тестов ему нужно пройти. Если в функциональности были найдены баги даже после DMT , список линок на кейсы помогает оценить, что именно не было учтено при написании тест кейсов. Еще, конечно, имеет смысл линковать тест с багами. На это есть как минимум 2 причины: Если мы проходим кейс повторно, то сразу видим, куда еще можно покопать, чтобы убедиться в полной надежности. Если соответствующего багу кейса не нашлось (а баг важный), то нужно такой кейс написать. Многие задают вопрос, почему бы не добавлять тест-кейс как саб-таску к юзер-стори. Изначально так и делалось. Но тут есть несколько существенных недостатков. Тест кейсы не структурированы. Нужно много времени, чтобы найти, например, все тесты, относящиеся к определенному компоненту системы. По этой же причине, при обновлении части функциональности, сложно найти и отредактировать все релевантные тесты Поскольку тесты раскиданы по сторям, сложнее делать выборку для регрессионного тестирования. Так как каждый из кейсов прогоняется не единожды, тест-кейсы не имеют состояния closed. В результате мы получаем кучу закрытых сторей в released versions , в которых есть открытые таски. Что усложняет отслеживание состояния проекта.
  21. https://jira.exigenservices.com/browse/ETPONE-79 Для того, чтобы залинковать тест-кейс, нужно открыть сам кейс, выбрать из меню More Actions опцию Link, выбрать тип связи – executes и ввести номер таски, с которой Вы тест кейс линкуете. При открытии таски, к которой прилинкован тест, Вы увидите issue links – где будет список всех кейсов, которые нужно пройти и их статус. https://jira.exigenservices.com/browse/ETPONE-96
  22. https://jira.exigenservices.com/browse/ETPONE-3 Показать на практике Все тесты в джире unassigned. Имеет смысл ассайнить только саб-таску ( execution), в которой находится тест-план.
  23. Как показано в примере выше, мы перечислили то, что нужно протестировать и залинковали соответствующие тесты. Таким образом, гарантировали полное покрытие . Заинтересованные стороны могут посмотреть на список и оценить, стоит ли что-либо добавить или убрать.
  24. ДМТ сводится к тому, что тестеры выделяют основные тест-кейсы по куску функциональности каждого разработчика. Прежде чем передать кусок на тестирование, девелопер проходит основные кейсы сам. Создается задача DMT и туда линкуется список основных тестов, которые девелопер проходит сам на тестовом инвайренменте. Тесты не ассайнятся на девелопера, на девелопера ассайнится DMT c абтаска. Если при дмт найдены баги, разработчик, не отвлекаясь на другие задачи, фиксит их и передает задачу на финальное тестирование.
  25. https://jira.exigenservices.com/browse/ETPONE-66 Поскольку кейсы привязаны не к стори, а к компоненту, при изменении требований можно легко найти и изменить тесты. Важно, что мы всегда можем видеть историю изменений кейса. Легче обновлять тесты по мере изменения требований
  26. Как оценить, какие тесты нам нужно пройти для регрессионного тестирования: Каждый кусок функциональности относится к определенной feature группе. Для выборки кейсов мы открываем соответствующий компонент (тест-компонент) и выбираем оттуда характерные тесты. Если текущая разработка может повлиять на другие компоненты, мы открываем список кейсов для этих компонентов и тоже делаем выборку Есть набор тестов с приоритетом Blocker. Это тесты вроде acceptance, которые нужно проходить перед самым релизом, чтобы убедиться что вся система в основном работает Проще оценивать время на прохождения регрешн-тестинга. к каждому из кейсов можно добавить предварительную оценку времени на прохождение. Мы выбираем набор тестов, складываем это время, и получаем время на регрессионное тестирование. С помощью стандартных фильтров легко планировать скоуп и время на регрешн – потом расскажу как (Проще выявлять скоуп регрешена. При прохождении теста фиксируется дата изменения результата (модификации теста). С помощью фильтров в джире можно найти тесты нужного приоритета (или относящиеся к нужному куску функциональности), которые не проходились с (нужной даты). И внести их в список регрешн таски (залинковать). Выбранные кейсы линкуются к таске “regression”. Эту таску можно отправить на апрувал разработчикам, или, в случае неожиданных косяков, документально подтвердить, что всё было протетстировано 
  27. При регрешене или беглом аксептенс-тестинге не всегда обязательно проходить тест во всех браузерах и локалях Поэтому выбираем достаточный минимум параметров, умножаем original estimate ( время на один прогон) на количество параметров и получаем итоговую цифру. Например, один прогон в одном браузере на одной локали занимает 4 мин. Если мы проверяем 3 браузера = 12 минут на прохождение теста. Если проверяем 3 локали в каждом браузере = 36 минут на прохождение теста.
  28. Как собирать тестовые метрики в джире? Тестовые метрики собираются с помощью фильтров. Например, еженедельно нам нужно: Сколько у нас открытых кастомерских багов Сколько открытых тестерских багов Сколько всего тест кейсов, сколько автоматизировано, сколько пройдено за неделю и т д. Для этого мы пишем фильтр. Например: Выбрать все тест кейсы из проекта, статус которых поменялся меньше недели назад. И получаем к-во пройденных тест кейсов. Фильтр сохраняется. И если он правильно написан, будет акруален всегда.