Test Case Management Tool: як правильно зробити вибір і не пошкодувати про це



Керівник QA-підрозділи Redmadrobot Ілля Горщиків розповідає, як вибирав інструментарій для роботи з тест-кейсами.

У процесі роботи над будь-якою складною програмною системою створюється велика кількість проектної документації. Її структурний склад у більшості випадків практично однаковий — це вимоги до системи різного рівня, опис її архітектури, програмний код, документація QA-команди, проектні плани, звіти і т. д.

Сьогодні я розповім про артефактах QA-команди Redmadrobot, з якими ми працюємо в ході проектів. Це тест-стратегії, тест-плани, test runs і тест-кейси, traceability matrix, bug reports, метрики продуктивності та якості, різні звіти за результатами тестування і т. д. Всі вони мають певну ієрархію, що створюються в певній послідовності і вимагають періодичної актуалізації.

Вирішити завдання створення єдиної системи для роботи з усіма QA-артефактами можна кількома способами. Наприклад, вибрати Excel і Google Docs, вести все у баг-трекері (використовуючи Test Case як Issue Type) або використовувати один з test case management tools, інтегрований з баг-трекером компанії. Ми в Redmadrobot вибрали третій варіант, виходячи зі специфіки проектів, обсягів завдань, типів QA-документації і використовуваних нами видів тестування, кількості розроблюваних і виконуваних manual тест-кейсів і різних проектів у роботі одночасно.

Наступним етапом для нас став вибір відповідного test case management tool. Дуже важливо підійти до цього вибору максимально відповідально, оскільки ціна помилки при виборі подібного інструменту для компанії досить висока. QA-команда Redmadrobot йшла до фінального рішенням в кілька етапів і починала з розробки критеріїв, яким необхідний інструмент повинен відповідати.

Критерії ми ввели наступні:

  • інтеграція з баг-трекером компанії (JIRA)
  • зберігання та редагування тест-кейсів, в тому числі імпорт тест-кейсів, створених нами раніше
  • простота відстеження покриття вимог тест-кейсами
  • зручне формування Test Runs/Test Suites і зручний користувальницький інтерфейс
  • зберігання всієї інформації по Test Development і Test Execution в одному місці і створення єдиного простору для роботи QA-команди
  • можливість створення Traceability Matrix
  • можливість розподілу завдань і призначення їх на конкретних інженерів
  • простота отримання звітів, метрик, статистики
  • зручність установки, впровадження, підтримки


З чого вибирати:

Після вироблення критеріїв ми розглянули кілька найбільш популярних на ринку тулов, які відповідали нашим очікуванням. Частина тулов була відкинута при більш детальному розгляді, залишилися ми оформили evaluation-ліцензії і продовжили дослідження. У результаті список скоротився до трьох тулов, на яких були проведені пілотні проекти:

1. Zephyr
2. TestRail
3. Meliora

По завершенні пілотів склалося чітке розуміння можливостей і зручності роботи в кожному з них, стали зрозумілі фічі кожного тула, їх придатність і зручність використання для нас. Ось високорівневі характеристики кожного тула:

Zephyr (1 user — 30$) — відмітна риса цього тула в тому, що це продукт Atlassian, а значить, він повинен бути відмінно сумісний c JIRA, але проблема в тому, що це валидно для JIRA Server, а ми поки використовуємо OnDemand, з яким на етапі пілота було багато проблем. Крім цього недоліку Zephyr незручний у використанні: додавати тест-кейси довго і не настільки просто, багато зайвих дій при створенні планів і runs.

Meliora (1 user — $25) — також необхідний перехід на JIRA Server + сам по собі Meliora досить громіздкий інструмент, штучно ускладнює більшу частину простих завдань, включає в себе ще й власний bug-трекер.

TestRail (1 user — $20) — простий і зручний тул. Основний плюс — кастомізація можлива практично у всьому, і будь-які дії інтуїтивно зрозумілі. Є можливість імпорту/експорту тест-кейсів.

Проаналізувавши результати пілотів і фідбек по кожному тулу, вирішили сконцентруватися на TestRail, який включає в себе і дозволяє:

  • Створення/зберігання/редагування тестових сценаріїв, управління тестовими планами, запуск тестових циклів, занесення результатів тестування.
  • Чітке опис тестових сценаріїв, їх рев'ю, співвідношення з вимогами, поділ на галузі — все це дозволяє оцінити як повноту покриття тестами функціоналу, так і є необхідним матеріалом для всієї проектної команди.
  • Створення звітів по зовсім різним критеріям: Defect Summary, Comparison for Cases, тестові результати по проектах/компонентів/майлстоунам і т. д.
  • Можливості для повної кастомізації «робочого dashboard», а також зручне отримання статусу роботи QA-команди за різні періоди часу (допомагає при створенні weekly/monthly QA report).
  • Легка інтеграція з JIRA.
  • Розумна ціна.
  • Відмінний support.
  • Легкий і зручний спосіб імпорту тестів з Excel.




Можливість легко імпортувати вже створені раніше тест кейси для нас була дуже важливим критерієм. Коли ми тільки починали розвивати QA-практику в Redmadrobot, мови про Test Case Management Tool ще не йшло, а для роботи з тестами використовували Excel. Але ми одразу підійшли до питання використання Excel з доробком на майбутнє і виробили чіткий формат тестів, розуміючи, що через деякий час будемо «згодовувати» їх в якій-небудь тул. Коли ми запустили TestRail в промислову експлуатацію, змогли експортувати «as is» кілька тисяч тест-кейсів, що сильно скоротило зусилля на впровадження тула.

Нижче я докладно розгляну можливості TestRail для різних QA-активностей:

Test Development:

  • створення test plans/suits/test cases;
  • зручне зберігання, оновлення та організація;
  • імпорт/експорт можливість редагування;
  • легко настроюється набір будь-яких атрибутів тесту;
  • Requirements Traceability.

Test Execution:

  • milestones (згідно з критерієм якості в компанії);
  • складання test runs;
  • заклад дефектів з test runs;
  • розподіл завдань;
  • зручна інтеграція з JIRA.


Test Management:

  • управління активностями;
  • розподіл ролей;
  • призначення завдань і контроль виконання.

Reporting:

  • прогрес тестування;
  • результати тестування у вигляді готових звітів;
  • статистика за проектами;
  • різноманіття варіантів звітів;
  • метрики продуктивності команди.

Що ж у підсумку:

Остаточний вибір ми зробили ще в серпні. У вересні перевели в TestRail більшу частину QA-активностей за проектами. Продовжуємо переводити туди все нові проекти. За весь час ще жодного разу не пошкодували про вибір. Зібрали кілька показників, які підтвердили наші припущення щодо вірності вибору і позитивний ефект від впровадження. Змогли швидко навчити інженерів ефективно використовувати тул. Найближчим часом закінчимо роботи над впровадженням Вимога Traceability для всіх проектів і будемо розвивати використання TestRail далі.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.