БЛОК 5. Документация тестирования — 16. Чек-листы
🧭 Введение: зачем QA нужны чек-листы
Чек-лист помогает быстро и стабильно пройти набор важных проверок без лишней документации. Это особенно полезно в smoke, коротких регрессах и повторяемых ежедневных проверках.
Когда чек-листа нет, QA легко забывает часть проверок, особенно под дедлайном. В итоге команда получает «дырявый» прогон и ложное ощущение качества.
💡 Совет:
Чек-лист должен быть коротким, но покрывать критичные зоны.
✅ Вывод:
Чек-лист — это инструмент скорости и дисциплины, а не «упрощённый тест-кейс».
⚠️ Проблема -> решение
Проблема: полные тест-кейсы писать и поддерживать для каждой мелкой проверки слишком дорого по времени.
Решение: для повторяемых и понятных проверок использовать чек-листы, а тест-кейсы оставлять для сложной и рискованной логики.
🟢 Если совсем просто:
Чек-лист = что проверить быстро и без пропусков.
🎯 Как понять, что этап прошёл успешно:
Команда проходит ключевые проверки быстро и одинаково, без «я забыл это протестировать».
🛠️ Чем помогает и как работает
Чек-лист ускоряет исполнение и делает проверки стабильными между разными QA. Он хорошо работает там, где шаги уже очевидны и важна именно полнота покрытия.
Как это работает:
- Шаг 1: берём требования и выделяем набор обязательных проверок.
- Шаг 2: формулируем короткие и проверяемые пункты.
- Шаг 3: группируем пункты по модулям или риску.
- Шаг 4: отмечаем приоритет (P1/P2/P3) для релизного порядка.
- Шаг 5: выполняем чек-лист и фиксируем статус пунктов.
- Шаг 6: обновляем список после изменения фичи.
✅ Вывод:
Хороший чек-лист экономит время и не теряет критичное покрытие.
📚 Ключевые термины (простыми словами)
- Checklist (чек-лист) — список проверок, который QA проходит по пунктам.
- Smoke testing (смоук-тестирование) — быстрая проверка, что система в целом работает.
- Regression testing (регрессионное тестирование) — проверка, что старый функционал не сломался после изменений.
- Coverage (покрытие) — насколько полно список проверяет важные зоны.
- Priority (приоритет) — порядок, в котором нужно выполнять пункты.
- Traceability (трассируемость) — связь пунктов с требованиями/AC.
1. Что такое чек-лист и где он особенно полезен
Чек-лист — это не «короткий тест-кейс», а отдельный формат документации. Он подходит для быстрых и повторяемых прогонов, когда длинное пошаговое описание не нужно.
🟢 Если совсем просто:
Чек-лист нужен, когда важно быстро проверить «ничего критичного не сломалось».
🎯 Как понять, что этап прошёл успешно:
По чек-листу реально пройти проверку за ограниченное время и получить понятный результат.
Назначение:
Сократить время на исполнение без потери обязательного покрытия.
Простыми словами:
Это контрольный список, который не даёт забыть ключевые проверки.
Для новичка:
Если задача простая и повторяется часто, сначала думай про чек-лист.
Аналогия:
Перед вылетом пилот проходит preflight-checklist, чтобы не пропустить критичные пункты.
Пример:
Checklist: Login Smoke- [ ] Страница /login открывается- [ ] Вход с валидными данными успешен- [ ] Ошибка показывается при неверном пароле- [ ] Кнопка Login заблокирована при пустых полях🔎 Как это происходит на практике:
- Перед релизом QA берёт smoke-чек-лист.
- Проходит пункты по приоритету.
- Если критичный пункт падает, релиз останавливают до фикса.
Характеристики:
- ✅ Короткий формат
- ✅ Быстрый прогон
- ✅ Понятный статус по каждому пункту
Когда использовать:
Smoke, короткий регресс, ежедневные sanity-проверки.
✅ Вывод:
Чек-лист эффективен там, где нужен быстрый и стабильный контроль базового качества.
2. Структура хорошего чек-листа
Плохой чек-лист превращается в набор общих фраз и не даёт объективной проверки. Хороший чек-лист состоит из конкретных и наблюдаемых пунктов.
🟢 Если совсем просто:
Пункт чек-листа должен отвечать на вопрос «могу ли я однозначно поставить pass/fail».
🎯 Как понять, что этап прошёл успешно:
В каждом пункте ясно, что именно проверяется и как понять результат.
Назначение:
Сделать пункты проверяемыми и однозначными.
Простыми словами:
Меньше «проверить всё ок», больше конкретики.
Для новичка:
Пиши пункт так, чтобы другой QA не спрашивал «а что именно ты имел в виду».
Минимальный шаблон чек-листа:
ID/РазделПункт проверкиОжидаемый результат (кратко)ПриоритетСтатус (Pass/Fail/Blocked)Комментарий (если Fail/Blocked)Пример:
CHK-LOGIN-03 | Неверный парольExpected: сообщение "Неверный email или пароль"Priority: P1Status: Pass🔎 Как это происходит на практике:
- QA пишет черновик списка.
- На ревью убирает размытые формулировки.
- Добавляет приоритеты и критерии результата.
Характеристики:
- ✅ Краткость
- ✅ Измеримость
- ✅ Единый формат для команды
Когда использовать:
Когда нужны быстрые циклы исполнения и простая отчётность.
✅ Вывод:
Качество чек-листа определяется проверяемостью пунктов, а не количеством строк.
3. Чек-лист vs тест-кейс: как выбрать формат
Оба формата нужны, но решают разные задачи. Ошибка джуна — использовать один формат везде.
🟢 Если совсем просто:
Чек-лист — быстро, тест-кейс — глубоко.
🎯 Как понять, что этап прошёл успешно:
Для сложной логики выбран тест-кейс, для быстрых повторяемых проверок — чек-лист.
Назначение:
Выбрать правильную глубину документации под риск и сложность.
Простыми словами:
Не всё нужно расписывать пошагово, но и не всё можно оставить одним пунктом.
Для новичка:
Если есть много веток и условий, переходи с чек-листа на тест-кейсы.
Сравнение:
| Критерий | Чек-лист | Тест-кейс |
|---|---|---|
| Детализация | Низкая/средняя | Высокая |
| Скорость подготовки | Высокая | Ниже |
| Скорость прогона | Высокая | Ниже |
| Подходит для сложной логики | Ограниченно | Да |
| Подходит для smoke | Да | Иногда избыточно |
🔎 Как это происходит на практике:
- Команда готовит релизный прогон.
- Critical бизнес-потоки оформляют тест-кейсами.
- Вспомогательные проверки закрывают чек-листом.
Характеристики:
- ✅ Баланс скорости и качества
- ✅ Контроль уровня детализации
Когда использовать:
При выборе формата тестовой документации под конкретную задачу.
✅ Вывод:
Формат выбирают по риску, а не по привычке.
4. Приоритизация чек-листа
Даже в чек-листе нужен порядок выполнения, иначе при нехватке времени команда может не успеть пройти критичные пункты.
🟢 Если совсем просто:
Сначала P1, потом всё остальное.
🎯 Как понять, что этап прошёл успешно:
Run order в чек-листе совпадает с рисками функционала.
Назначение:
Защитить релиз от пропуска наиболее опасных дефектов.
Простыми словами:
Не все пункты чек-листа одинаково важны.
Для новичка:
Если времени мало, сначала пункты про доступ, оплату, авторизацию и критичные интеграции.
Пример:
P1: Авторизация пользователяP1: Создание заказаP2: Смена аватараP3: Визуальная подсказка в профиле🔎 Как это происходит на практике:
- QA lead выставляет приоритеты.
- Команда сначала закрывает P1.
- P2/P3 выполняются по оставшемуся времени.
Характеристики:
- ✅ Риск-ориентированный порядок
- ✅ Понятное релизное решение
Когда использовать:
Всегда в релизных и предрелизных проверках.
✅ Вывод:
Приоритизация превращает чек-лист из «списка задач» в инструмент релизного контроля.
5. Когда чек-листа недостаточно
Чек-лист не заменяет тест-кейсы в сложных сценариях. Если логика многошаговая или критичная, кратких пунктов может быть мало.
🟢 Если совсем просто:
Чек-лист хорош для «что проверить», но не всегда хватает для «как именно проверить».
🎯 Как понять, что этап прошёл успешно:
Команда заранее знает, где чек-лист уместен, а где нужен полноценный тест-кейс.
Назначение:
Избежать ложной экономии на документации.
Простыми словами:
Не пытайся закрыть сложный флоу одним коротким пунктом.
Для новичка:
Если после чтения пункта остаются вопросы про шаги и ожидаемый итог, делай тест-кейс.
Где обычно нужен тест-кейс вместо чек-листа:
- платежные сценарии и деньги;
- доступы/роли/права;
- сложные multi-step пользовательские потоки;
- критичные интеграции и обработка ошибок.
🔎 Как это происходит на практике:
- QA начинает с чернового чек-листа.
- Видит, что пункт «Проверить оплату» слишком широкий.
- Декомпозирует его в 3–5 тест-кейсов с шагами.
Характеристики:
- ✅ Реалистичный выбор формата
- ✅ Меньше пропусков критичных дефектов
Когда использовать:
На этапе test design, до старта активного прогона.
✅ Вывод:
Чек-лист ускоряет работу, но не должен скрывать сложность высокорискованных потоков.
📌 Must-know факты
- Чек-лист должен состоять из конкретных и проверяемых пунктов.
- Пункт вида «проверить, что всё ок» — плохой пункт.
- В релизных прогонах чек-лист обязан иметь приоритеты.
- Чек-лист подходит для smoke/sanity и повторяемых проверок.
- Для сложной логики и критичных флоу нужен тест-кейс.
- Чек-лист нужно обновлять при изменении требований.
❗ Частые мифы
❌ Миф: Чек-лист — это «плохая версия» тест-кейса.
✅ Как правильно: Это отдельный формат для быстрых и повторяемых проверок.
📎 Почему это важно: Неправильное отношение к формату снижает качество документации.
❌ Миф: В чек-листе можно писать очень общо, «и так понятно».
✅ Как правильно: Каждый пункт должен быть измеримым и давать однозначный статус.
📎 Почему это важно: Размытые пункты не дают объективного pass/fail.
❌ Миф: Чек-лист не надо обновлять после изменений.
✅ Как правильно: Чек-лист должен жить вместе с продуктом и меняться вместе с AC.
📎 Почему это важно: Устаревший список даёт ложное покрытие.
❌ Миф: Чек-лист всегда достаточно, тест-кейсы не нужны.
✅ Как правильно: Для сложных и рискованных потоков нужен детальный тест-кейс.
📎 Почему это важно: Иначе высока вероятность пропуска критичных багов.
💬 Часто спрашивают на собеседованиях
❓ Вопрос: Чем чек-лист отличается от тест-кейса?
✅ Ответ: Чек-лист фиксирует, что проверить, а тест-кейс детализирует шаги и expected result.
❓ Вопрос: Когда вы выберете чек-лист вместо тест-кейса?
✅ Ответ: Для быстрых повторяемых smoke/sanity проверок, где логика простая и понятная.
❓ Вопрос: Какие признаки плохого чек-листа?
✅ Ответ: Размытые формулировки, отсутствие приоритетов и пунктов с измеримым результатом.
❓ Вопрос: Нужно ли связывать пункты чек-листа с требованиями?
✅ Ответ: Да, особенно в релизных проверках, чтобы понимать покрытие AC и объяснять риски.
❓ Вопрос: Можно ли делать релиз только по чек-листу?
✅ Ответ: Можно для простых изменений, но при сложной логике и высоких рисках нужны тест-кейсы.
🚨 Типичные ошибки
Ошибка 1: Слишком общий пункт
❌ Неправильно:
"Проверить логин".
✅ Правильно:
"Вход с валидными данными ведёт на
/dashboard".Почему:
Размытый пункт не даёт объективной проверки.
Ошибка 2: Нет приоритета
❌ Неправильно:
Все пункты идут в случайном порядке.
✅ Правильно:
Пункты помечены P1/P2/P3 и выполняются по риску.
Почему:
Без приоритета можно не успеть проверить критичное.
Ошибка 3: Чек-лист пытается покрыть сложный флоу
❌ Неправильно:
Один пункт «Проверить оплату полностью».
✅ Правильно:
Разбить на детальные тест-кейсы для ключевых веток оплаты.
Почему:
Сложная логика требует детальной проверки.
Ошибка 4: Не обновляют список после релиза
❌ Неправильно:
Использовать старый чек-лист после изменения AC.
✅ Правильно:
После каждого изменения фичи пересматривать релевантные пункты.
Почему:
Иначе покрытие становится фиктивным.
Ошибка 5: Нет статусов по пунктам
❌ Неправильно:
Пункты просто «пройдены на словах».
✅ Правильно:
Каждый пункт имеет статус Pass/Fail/Blocked и комментарий.
Почему:
Без статусов нельзя прозрачно оценить результат прогона.
✅ Best Practices
- Делайте пункты короткими и проверяемыми.
- Добавляйте приоритет для релизных прогонов.
- Храните один шаблон чек-листа для всей команды.
- Связывайте критичные пункты с требованиями/AC.
- Проводите мини-ревью чек-листа перед релизом.
- Регулярно удаляйте дубли и устаревшие пункты.
🏁 Заключение
Чек-лист — это быстрый и практичный формат QA-документации, который помогает не пропустить базовые проверки под давлением сроков.
Для junior QA важный навык — понимать границы формата: где чек-листа достаточно, а где нужно переходить к полноценным тест-кейсам.