Що таке чекліст QA-тестування?
Чекліст QA-тестування перетворює тестовий прохід на кроки з галочками на робочому елементі: середовище готове, функціональне покриття, крайні випадки, браузери, перевірки безпеки й sign-off. Форма списку та сама для кожного бага чи story; змінюються лише галочки й докази.
Прохід стоїть поруч із acceptance criteria: ці рядки описують обіцяну поведінку, а список QA-тестування фіксує, як ви її довели. Definition of Done може вимагати, щоб цей список був завершений, перш ніж story піде у відвантаження.
Чому команди тримають QA-тестування на завданні
Тестовий прохід у таблиці, на сторінці Confluence чи в треді Slack легко загубити, коли наступна людина відкриває тікет. Чекліст на робочому елементі тримає підготовку, покриття й докази там, де вже живе робота — тестувальники ставлять статуси пунктів на кшталт In Progress і Blocked, роблять @mention власника на застряглому рядку, і дошка показує, що лишилося.
Той самий прохід підходить і для бага, і для story: відкриваєте завдання, бачите, що лишилося, додаєте скріншоти чи логи до падінь і записуєте результат на тікеті. Зміни з низьким ризиком можуть прибрати рядки про security і платформи; за високого ризику вони лишаються.
Коли застосовувати
Використовуйте чекліст QA-тестування на багах, на stories, яким потрібен структурований прохід до Done, або коли статус стає Ready for test. Автозастосовуйте його за типом завдання для Bug або на цьому переході статусу, щоб тестувальники завжди отримували один каркас. Прибирайте рядки за низького ризику; залишайте покриття security і регресії, якщо зміна стосується auth, payments або спільного шляху.
QA-тестування vs Acceptance criteria vs Definition of Done
Acceptance criteria описують, що має дати ця story — приклади, які ви будете демо. Чекліст QA-тестування — як ви ці приклади доводите: дані, браузери, регресії й нотатки. Definition of Done — спільна exit-планка, яку кожна story винна наприкінці: тести, рев’ю й готовність до релізу. Тримайте всі три окремими чеклістами на робочому елементі, щоб поведінка, тестовий прохід і якість відвантаження лишалися розрізнюваними.
QA-тестування — приклад для старту
Щоб зібрати перший чекліст QA-тестування, почніть із прикладу нижче. Скопіюйте список і вставте його в поле Checklist for Jira на багу чи story. Ідеально зберегти його як шаблон і автозастосовувати під час створення Bug або коли робота переходить у Ready for test — так у тестувальників буде стабільний каркас і ті самі заголовки щоразу. Приберіть рядки, які команда пропускає; додайте ті, що потрібні процесу.
QA-тестовий прохід
- Підготовка
- Тестове середовище, білд і feature flags відповідають робочому елементу
- Тестові дані й акаунти готові, включно з крайніми випадками прав
- Відомі баги, які поза цим проходом, пов’язані на завданні
- Функціональне покриття
- Happy path відповідає acceptance criteria цього робочого елемента
- Перевірено валідацію, порожні стани й очевидні помилкові шляхи
- Права й відмінності ролей перевірено, коли доступ важливий
- Крайні випадки
- Граничні значення, порожні колекції й паралельні правки покрито, коли це застосовно
- Перервані сценарії продовжуються або падають явно — timeouts, retries і скасовані запити
- Регресія й платформи
- Суміжні сценарії, які ділять цей шлях коду, усе ще працюють
- Основні браузери або пристрої, узгоджені командою, покрито
- Accessibility smoke: шлях із клавіатури й видимий фокус на нових контролах
- Безпека
- Авторизація тримається: користувач не бачить і не змінює дані іншого тенанта
- Чутливі значення не потрапляють в URL, логи й повідомлення про помилки
- Докази й sign-off
- Скріншоти, записи або посилання на логи додано до падінь
- Нові дефекти заведено й пов’язано, severity заповнено
- Результат QA записано на робочому елементі: pass, fail або blocked із власником
Цей каркас потрібен на кожному багу й на stories, яким потрібен структурований прохід. У Checklist for Jira ви додаєте або позначаєте пункти на панелі завдання, зберігаєте заголовки як проєктний чи глобальний шаблон і автозастосовуєте його під час створення Bug або коли статус стає Ready for test — або вручну через Add → Add from template, коли потрібно.
Поставте це на робочий елемент із Checklist for Jira
Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.
Збережіть стартер, автоматизуйте прохід
- Checklist for Jira додає панель чекліста на вигляді завдання. Вставте приклад вище на баг чи story, підженіть рядки під процес і збережіть форму як проєктний чи глобальний шаблон у Checklist settings.
- Позначте шаблон Protected, якщо список кроків має бути заблокований, поки тестувальники позначають пункти й ставлять статуси на кшталт In Progress і Blocked.
- Використовуйте автоматизацію на шаблон, щоб вішати каркас QA-тестування під час створення Bug або коли статус стає Ready for test. Ці автоматизації вбудовані в Checklist for Jira й ідуть без кредитів Jira Automation.
- Якщо команді потрібне нагадування до Done, додайте валідатор завершення на цей перехід, обмежений цим шаблоном, щоб робочий елемент лишався відкритим, поки прохід не закінчено.
- Поєднуйте з acceptance criteria для прикладів, які прохід доводить, Definition of Done наприкінці й чекліст релізу, коли зміна готова до відвантаження — див. посібник з автоматизації.
Поєднуйте з рештою delivery-набору
Тримайте acceptance criteria на тому самому завданні для обіцяної поведінки. Вішайте Definition of Done, коли робота входить у спринт, щоб планка відвантаження була видима з першого дня. Використовуйте Definition of Ready на refinement, якщо якість intake допомагає команді. Продовжуйте чекліст релізу, коли зміна готова до відвантаження. Повний набір — у хаб шаблонів.
Часті запитання
Кожен тест-кейс має бути підзавданням?
Відкривайте підзавдання, коли кейсу потрібні свій виконавець, оцінка й workflow. Структурований чекліст QA-тестування на батьківському елементі — легший спосіб провести стандартний прохід.
Чим QA-тестування відрізняється від acceptance criteria?
Acceptance criteria — приклади, які ви будете демо: як виглядає «правильно». Чекліст QA-тестування — як ви їх довели: середовище, кейси, докази й sign-off на тому самому робочому елементі.
Чи можна звітувати за незавершеними QA-списками?
Checklist for Jira показує прогрес на завданні, на дошках і в JQL, тож незавершена QA-робота фільтрується.
Чи мають баги й stories використовувати один QA-список?
Почніть з одного шаблону й скоротіть. Баги часто залишають повний прохід. Stories можуть прибрати рядки про security чи платформи, якщо зміна низькоризикова. Збережіть другий шаблон за типом завдання, коли два списки лишаються різними.
Поставте це на робочий елемент із Checklist for Jira
Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.