Тест-менеджмент системи (TMS) допомагають оптимізувати процес тестування та налагодити спільну роботу між командами. Натомість неправильний підхід може спричинити появу «сірих зон» у продукті та виникнення дефектів уже після релізу. Володимир Матвійченко, Automation QA Engineer у партнерській компанії Quarks, має шестирічний досвід у тестуванні, понад п’ять років — в автоматизації. Він поділився досвідом команди у побудові процесів тестування, розповів, для чого потрібна тест-менеджмент система у продукті, коли варто її змінити, та що дав перехід на Allure TestOps.
Для чого потрібна TMS
Тест-менеджмент система використовується для зберігання документації та відповідає на питання, як саме відбувалося планування та тестування продукту. Вона показує якість релізу, який готується до деплоя на продакшн, на скільки той чи інший функціонал закритий тестовою документацією.
Основні функції тест-менеджмент системи:
Мені доводилося працювати з різними TMS: ALM, TestLink, TestRail, Allure TestOps тощо. Їхні переваги та недоліки за різними критеріями зібрані в таблиці нижче.
Донедавна ми використовували TestRail для проєктів у Quarks. У порівнянні з ним Allure TestOps надає наступні переваги:
Відкритість. Allure TestOps є повністю відкритою платформою з відкритим вихідним кодом, що дозволяє розробникам та тестувальникам налаштовувати та розширювати функціональність за потреби.
Простота інтеграції з фреймворками автоматизації, можливість збирати та відображати додаткову інформацію про результати тестів.
Зручна візуалізація результатів тестів за допомогою графіків і діаграм, що дозволяє швидко орієнтуватися в статусі тестів.
Інтеграція з іншими інструментами, такими як JIRA, Git, Slack, Docker, Jenkins та багатьма іншими. Це дозволяє забезпечити повну автоматизацію тестового процесу та максимальну ефективність роботи команди тестування.
Можливість створювати та зберігати описи тестів, пов'язувати їх з тестовими скриптами та відповідними багами. Крім того, можна додавати до тестів скріншоти та інші зображення, що забезпечує більш детальну документацію результатів тестування.
Робота з TestRail: що пішло не так
Як виглядав тестовий процес під час використання системи TestRail: Manual QA детально описував тест-кейс для певного функціонала. AQA-команда переводила мануальні кроки в автоматизовані за допомогою певної мови програмування. Далі ці сценарії пушили в BitBucket, після чого їх забирав Jenkins, запускав на ремоут-сервері, формував тестові звіти. Мануальний та автоматизований сценарій поєднувався через анотацію Test Case ID — це вказувало, що цей сценарій автоматизований. І далі з допомогою API TestRail ми проставляли статус для автоматизованого тест-кейса у Test Run (passed/failed).
Але в цього процесу була низка недоліків:
1. Оновлення тестової документації. Наприклад, коли в одному з ланцюгів ламався тест-кейс, ми вносили правки у фреймворк автоматизації, а не в TestRail. І через декілька циклів релізів автоматизований тест-кейс відрізнявся від мануального тест-кейса, описаного в TMS. В результаті, в TestRail документація не оновлювалася і зберігалася неактуальною.
2. Підтримка версійності тест-кейсів. Наприклад, в TestRail у нас була одна реалізація тест-кейса, у фреймворку автоматизації — друга, а при тестуванні нового функціоналу — третя. І під час випуску нового релізу щоразу виникало питання, де ж актуальна документація, на що орієнтуватися.
3. Генерація тестової документації на основі автоматичних тестових сценаріїв. Наприклад, у нас є реалізація автотестів, але не написана документація.
4. Робота з параметризованими тестами. Доволі часто в процесі автоматизації використовуються параметризовані тести. Але TestRail не підтримував можливості проставляти через API декілька статусів для мануальних тест-сценаріїв.
5. Інтеграція тестового фреймворку з TMS. Для автоматизації ми використовуємо Java та тестовий фреймворк JUnit 5. Але інтеграція тестового фреймворку з TestRail — непросте завдання, адже необхідно добре розуміти публічну API самої TMS, та саме яким чином в Test Run проставляти статуси для тест-кейсів, як при цьому TMS взаємодіє з фреймворком тестування. У випадку якщо ви вирішите переїхати з одного тестового фреймворку на інший, наприклад з TestNG на JUnit 5, то вся інтеграція у вас зламається і потрібно буде переписувати інтеграцію з TMS. Щоразу ми думали: чому це так складно й немає плагіна, який би «з коробки» зробив інтеграцію з TMS?
Але найголовніший недолік Test Rail полягав у тому, що ми не могли створити Test Run, який би обʼєднував автоматичні та мануальні сценарії. Кожна з команд QA орієнтувалася на власні тест-кейси, і тестування зводилося до двох паралельних процесів. Виходило, що зʼявлялися «сірі зони», взагалі не покриті тестами, і після релізу виникали дефекти на продукті.
«Переїзд» на Allure TestOps. Новий тестовий процес
В новому тестовому процесі, організованому з допомогою Allure TestOps, коли проходить задача на тестування нового функціоналу, Manual QA в першу чергу створює Test Launch, який включає автоматизовані та мануальні тестові сценарії. Якщо в рамках нового функціоналу продукту необхідно актуалізувати документацію, її дописують у межах цього Test Launch. Allure TestOps може автоматично взаємодіяти з CI, тобто Manual QA не потрібно звертатися до Jenkins. Єдине, що має зробити тестувальник — створити Launch та включити в нього тести, які необхідно перевірити в рамках розробки нового функціонала. Він може містити як автоматизовані тестові сценарії, так і мануальні. Після запуску Allure TestOps автоматично проставляє статуси про успішність виконання тестових сценаріїв. Якщо якісь з них не покриваються автоматизацією, Manual QA перевіряє логіку та визначає статуси самостійно.
Також Allure TestOps дозволяє на основі автоматизованих тест-кейсів створювати документацію. Наприклад, якщо мануальна команда завантажена, а AQA Engineer добре ознайомлений з функціоналом продукту, він може написати автосценарій і на його основі згенерувати тест-кейс, який буде використовуватися обома QA командами. Актуальна документація на проєкті — дуже важлива, адже допомагає мінімізувати час на автоматизацію нових сценаріїв.
Як в Allure TestOps підтримуються параметризовані тести
В проєкті автоматизації над параметризованим тестом додаємо анотацію DataProvider. Вона є врапером над анотацією ParameterizedTest. Далі додається анотація Allur ID — фактично вона зʼєднує мануальний та автоматизований сценарій в Allure TestOps. І далі нам достатньо додати рядок «parameter», описати вхідний параметр наприклад title і додати вхідний параметр, який ми приймаємо з анотації MethodSource. На основі цих даних Allure TestOps побудує таблицю вхідних параметрів для тестового сценарію. Отже, достатньо написати один мануальний тестовий сценарій замість шести. Для цього і використовуються параметризовані тести.
Ще один приклад, як можна реалізувати параметризовані тести в Allure TestOps: в анотації СsvSource вказується ID тест-кейс. Тоді один автоматичний сценарій проставить статуси для двох мануальних сценаріїв і побудує таблицю.
Інтеграція з фреймворком автоматизації та інші фічі Allure TestOps
Для інтеграції Allure TestOps з фреймворком достатньо встановити плагін IntelliJ IDEA та в Jenkins файл додати інформацію про посилання на Cloud Allure TestOps. Єдина умова — ви маєте використовувати репортинг Allure. На відміну від TestRail, на стороні фреймворку не треба нічого знати про Public API TMS, заглиблюватись у нюанси та писати додатковий код — інтеграція працює «з коробки».
Allure TestOps має інтуїтивно зрозумілий та легкий в навігації інтерфейс. Головний екран містить панель навігації зі списком доступних модулів:
Test Cases — список усіх тест-кейсів з можливістю створення нових та редагування вже існуючих.
Test Runs — список усіх Test Launches, що дозволяє запускати, переглядати результати та аналізувати стан тестування.
Defects — список дефектів, що дозволяє стежити за ними та відслідковувати стан їх виправлення.
Reports — різноманітні звіти та діаграми на основі результатів тестування.
Integrations — налаштування інтеграції з різноманітними інструментами для автоматизації тестування.
Крім цього, в Allure TestOps є можливість швидкого пошуку тест-кейсів, тестових ланчів та дефектів за ключовими словами чи тегами. Також застосунок підтримує можливість створення проєктів та управління правами доступу до них. Усі ці функції дозволяють швидко та ефективно організовувати процес тестування та відстежувати стан різних проєктів та їхніх компонентів.
У цій TMS є можливість створення кастомних дашбордів, наприклад, для регресійного та смоук-тестування. Вони можуть показувати інформацію про епіки (унікальний функціонал для певного продукту) — наскільки вони покриті тестами. Коли відбувається оновлення функціонала, ми одразу на дашборді бачимо нові сценарії, фільтруємо за статусами та переходимо до автоматизації.
Ще одна перевага — Allure TestOps «з коробки» підтримує матрицю покриття. Наприклад, у кожному епіку є окремі фічі, за кожною з яких показується, скільки автоматизованих сценаріїв, скільки мануальних. З допомогою кольорів підсвічуються статуси, завдяки чому зручно слідкувати за покриттям функціонала. Наприклад, темнозелений — усе закрито тестами. Червоний — ця фіча не закрита автоматизованими сценаріями, тут треба автоматизувати певну кількість мануальних тест-кейсів тощо.
Зміна тест-менеджмент системи та перехід на Allure TestOps допоміг нам оптимізувати деякі процеси, налагодити ефективну взаємодію між командами AQA та Manual, забезпечити краще покриття тестами та підвищити якість продукту.
