Что такое тестирование по чек-листам?
Тестирование по чек-листам использует списки высокого уровня проверяемых пунктов вместо детальных пошаговых тест-кейсов. Каждый пункт напоминает тестировщику что проверить, не предписывая как, давая опытным тестировщикам гибкость и гарантируя покрытие важного.
Чек-листы vs. Детальные тест-кейсы
| Аспект | Чек-лист | Детальный тест-кейс |
|---|---|---|
| Формат | Короткие пункты | Пошагово с ожидаемыми результатами |
| Время создания | Минуты | Часы |
| Гибкость | Высокая — тестировщик решает как тестировать | Низкая — точные шаги предписаны |
| Воспроизводимость | Ниже — зависит от квалификации | Выше — любой может следовать |
| Поддержка | Легко обновлять | Затратно поддерживать |
| Лучше для | Опытных тестировщиков, меняющихся фич | Критических потоков, регуляторного compliance |
Когда использовать чек-листы
Хороший выбор:
- Smoke-тестирование и sanity-проверки
- Опытная команда со знанием домена
- Быстро меняющиеся фичи
- Направление исследовательского тестирования
- Регрессионное тестирование спринта
Плохой выбор:
- Регуляторное тестирование (нужны задокументированные шаги)
- Начинающие тестировщики, нуждающиеся в подробном руководстве
- Создание автоматизированных тестов (нужны точные шаги и данные)
Анатомия хорошего чек-листа
Пункт чек-листа должен быть:
- Кратким: Одна строка, одна проверка
- Действенным: Понятно, что проверять
- Независимым: Каждый пункт проверяется отдельно
- Приоритизированным: Наиболее критичные пункты первыми
Плохо: «Протестировать авторизацию» (слишком размыто) Хорошо: «Вход с валидными данными показывает дашборд» (ясно, проверяемо)
Пример: Чек-лист веб-приложения
## Авторизация
- [ ] Валидные данные → отображается дашборд
- [ ] Неверный пароль → сообщение об ошибке, без подсказки о блокировке
- [ ] Пустой username/пароль → ошибка валидации
- [ ] SQL-инъекция в поле username → корректно очищено
- [ ] Cookie сессии имеет флаги Secure и HttpOnly
- [ ] «Запомнить меня» сохраняет сессию на указанный период
## Навигация
- [ ] Все ссылки меню ведут на правильные страницы
- [ ] Хлебные крошки показывают правильный путь
- [ ] Кнопка «Назад» работает ожидаемо
- [ ] Прямая ссылка работает при авторизации
- [ ] Прямая ссылка перенаправляет на вход без авторизации
## Формы
- [ ] Обязательные поля показывают валидацию при пустой отправке
- [ ] Лимиты длины полей применяются
- [ ] Спецсимволы обрабатываются (без XSS)
- [ ] Форма сохраняет данные при ошибке валидации
- [ ] Кнопка отправки блокируется при обработке
Создание чек-листа с нуля
flowchart TD
A[1. Определить области тестирования] --> B[2. Перечислить ключевые проверки]
B --> C[3. Добавить типичные паттерны ошибок]
C --> D[4. Приоритизировать пункты]
D --> E[5. Ревью с командой]
E --> F[6. Использовать, улучшать, повторять]
Продвинутые стратегии чек-листов
Доменно-специфичные чек-листы
Чек-лист E-Commerce:
- Товар показывает правильную цену во всех валютах
- Итог корзины обновляется при изменении количества
- Промокоды применяются и отображаются корректно
- Обработка платежей поддерживает все методы
- Email подтверждения заказа отправляется с правильными данными
- Инвентарь уменьшается после успешного заказа
Чек-лист API:
- Все эндпоинты возвращают правильные статус-коды
- Схема ответа соответствует документации
- Аутентификация обязательна для защищённых эндпоинтов
- Rate limiting применяется
- Пагинация работает с edge cases
- Ответы об ошибках содержат осмысленные сообщения
Чек-лист мобильного приложения:
- Приложение обрабатывает смену ориентации без потери состояния
- Переходы фон/передний план сохраняют данные
- Оффлайн-режим показывает соответствующие сообщения
- Push-уведомления приходят и навигируют правильно
- Приложение корректно обрабатывает отказ в разрешениях ОС
Многоуровневые чек-листы
Уровень 1: Smoke (5 мин) — Приложение загружается, вход работает, основная фича доступна Уровень 2: Core (30 мин) — Полный поток входа, CRUD, ключевые бизнес-сценарии Уровень 3: Полный (2+ часа) — Все валидации, кросс-браузерность, доступность, производительность, безопасность
Развитие чек-листов
| Действие | Когда |
|---|---|
| Добавить пункт | Найден новый дефект, не покрытый чек-листом |
| Удалить пункт | Фича удалена или пункт стабильно проходит |
| Изменить пункт | Изменилось требование |
| Переупорядочить | Приоритет изменился на основе риска |
Упражнение: Создайте чек-лист тестирования
Сценарий: Вы единственный QA, тестирующий Настройки профиля пользователя: редактирование имени/email/био, загрузка аватара, смена пароля, 2FA, удаление аккаунта, настройки уведомлений.
Задание: Создайте чек-лист с минимум 20 пунктами, организованными по функциональным областям.
Подсказка
Организуйте по фичам: Профиль, Аватар, Пароль, 2FA, Удаление аккаунта, Уведомления. Не забудьте: безопасность (XSS в био), доступность, мобильность, ошибочные состояния и диалоги подтверждения.
Решение
## Редактирование профиля (6 пунктов)
- [ ] Обновить имя → сохранено и отображено
- [ ] Спецсимволы в имени → обработаны
- [ ] Смена email требует верификации нового
- [ ] Био соблюдает лимит символов
- [ ] Пустые обязательные поля → ошибки валидации
- [ ] XSS в био очищен при отображении
## Аватар (5 пунктов)
- [ ] Загрузка валидного изображения → отображается
- [ ] Слишком большое изображение → сообщение об ошибке
- [ ] Файл не-изображение → отклонён
- [ ] Удаление аватара → показан стандартный
- [ ] Аватар корректен во всех размерах
## Пароль (4 пункта)
- [ ] Смена с правильным текущим → успех
- [ ] Смена с неверным текущим → ошибка
- [ ] Новый пароль соответствует политике
- [ ] Смена пароля отправляет уведомление
## 2FA (4 пункта)
- [ ] Включение → QR-код, настройка завершена
- [ ] Вход требует код 2FA
- [ ] Неверный код → отклонён
- [ ] Отключение требует подтверждения паролем
## Удаление аккаунта (4 пункта)
- [ ] Показывает диалог подтверждения
- [ ] Требует повторного ввода пароля
- [ ] Удаление необратимо
- [ ] Отмена возвращает без изменений
## Сквозные проверки (3+ пункта)
- [ ] Всё работает на мобильном viewport
- [ ] Клавиатурная навигация
- [ ] Предупреждение о несохранённых изменениях
Советы профессионала
- Начинайте с истории дефектов. Прошлые баги вашей команды — лучший источник пунктов чек-листа.
- Держите чек-листы до 50 пунктов. Длинные списки вызывают усталость, пункты пропускаются. Разбивайте на подчек-листы.
- Используйте чек-листы как минимальное покрытие, не максимальное. Опытные тестировщики должны исследовать дальше.
- Версионируйте чек-листы. Храните рядом с кодом. Отслеживайте когда и зачем добавлены пункты.
- Сочетайте чек-листы с сессионным тестированием. Используйте чек-лист как направление для ограниченной по времени исследовательской сессии.