Чеклист QA-тестирования, который остаётся на рабочем элементе

Что такое чеклист 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 — так у тестировщиков будет стабильный каркас и те же заголовки каждый раз. Уберите строки, которые команда пропускает; добавьте те, что нужны процессу.

Этот каркас нужен на каждом баге и на stories, которым нужен структурированный проход. В Checklist for Jira вы добавляете или отмечаете пункты на панели задачи, сохраняете заголовки как проектный или глобальный шаблон и автоприменяете его при создании Bug или когда статус становится Ready for test — или вручную через Add → Add from template, когда нужно.

Сохраните стартер, автоматизируйте проход

1. Checklist for Jira добавляет панель чеклиста на виде задачи. Вставьте пример выше на баг или story, подгоните строки под процесс и сохраните форму как проектный или глобальный шаблон в Checklist settings.
2. Отметьте шаблон Protected, если список шагов должен быть заблокирован, пока тестировщики отмечают пункты и ставят статусы вроде In Progress и Blocked.
3. Используйте автоматизацию на шаблон, чтобы вешать каркас QA-тестирования при создании Bug или когда статус становится Ready for test. Эти автоматизации встроены в Checklist for Jira и идут без кредитов Jira Automation.
4. Если команде нужно напоминание до Done, добавьте валидатор завершения на этот переход, ограниченный этим шаблоном, чтобы рабочий элемент оставался открытым, пока проход не закончен.
5. Сочетайте с acceptance criteria для примеров, которые проход доказывает, Definition of Done в конце и чеклист релиза, когда изменение готово к отгрузке — см. руководство по автоматизации.

Сочетайте с остальным delivery-набором

Держите acceptance criteria на той же задаче для обещанного поведения. Вешайте Definition of Done, когда работа входит в спринт, чтобы планка отгрузки была видна с первого дня. Используйте Definition of Ready на refinement, если качество intake помогает команде. Продолжайте чеклист релиза, когда изменение готово к отгрузке. Полный набор — в хаб шаблонов.

Частые вопросы