Чек-лист теста – один из самых полезных инструментов в арсенале тестировщика, методиста или разработчика, который хочет проверить продукт системно, а не наугад. Примеры чек-листа теста помогают понять, как именно выглядит этот документ на практике: что в него входит, как он структурируется и почему одни варианты работают лучше других. В этой подборке собраны рабочие образцы для разных форматов и задач – от функционального тестирования до проверки UX и безопасности.
Каждый пример показывает логику построения, а не готовый текст для копирования без изменений. Адаптируйте структуру под свой продукт, команду и контекст – именно в этом главная ценность таких шаблонов.
В подборку вошли те варианты, с которыми чаще всего работают на практике и которые проще всего адаптировать под свою задачу.
Что войдет в подборку: форматы и примеры чек-листов теста
Функциональные чек-листы
- Чек-лист теста формы регистрации
- Чек-лист теста корзины интернет-магазина
- Чек-лист теста личного кабинета пользователя
- Чек-лист теста функции поиска
Чек-листы тестирования UX и интерфейса
- Чек-лист UX-проверки мобильного приложения
- Чек-лист проверки адаптивной верстки
- Чек-лист проверки онбординга нового пользователя
Чек-листы регрессионного тестирования
- Чек-лист регрессии после обновления платежного модуля
- Чек-лист регрессии при выходе новой версии мобильного приложения
Чек-листы тестирования безопасности
- Чек-лист базовой проверки безопасности веб-приложения
- Чек-лист проверки авторизации и прав доступа
Чек-листы тестирования API
- Чек-лист тестирования REST API
- Чек-лист проверки обработки ошибок API
Чек-листы для нефункционального тестирования
- Чек-лист нагрузочного тестирования
- Чек-лист тестирования производительности страницы
Короткие чек-листы для быстрых проверок
- Чек-лист smoke-теста после деплоя
- Чек-лист sanity-проверки конкретной функции
- Чек-лист предрелизной проверки
Примеры чек-листа теста разных видов и форматов: основной FAQ
Что такое чек-лист теста. Чек-лист теста – это структурированный список проверок, которые нужно выполнить, чтобы убедиться в корректной работе продукта или его отдельной части. В отличие от тест-кейса, чек-лист не описывает пошаговые действия и не фиксирует ожидаемый результат в деталях – он дает перечень того, что нужно проверить, а не как именно.
Основные форматы чек-листов:
- Функциональный – проверяет, работает ли функционал согласно требованиям.
- UX и интерфейсный – проверяет удобство, логику и внешний вид интерфейса.
- Регрессионный – проверяет, не сломалось ли старое после новых изменений.
- Безопасности – проверяет защиту данных, авторизацию и уязвимости.
- API – проверяет корректность работы программных интерфейсов.
- Нефункциональный – проверяет нагрузку, скорость, стабильность.
- Быстрые форматы – smoke, sanity, предрелизные проверки.
Где применяют. Чек-листы используют в командах разработки, QA-отделах, при приемке продукта, в стартапах без выделенного тестировщика и при аудите готового решения. Их пишут как опытные QA-инженеры, так и продакт-менеджеры и разработчики – в зависимости от задачи и ресурсов команды.
Функциональные чек-листы теста
Функциональные чек-листы – самый распространенный формат. Они проверяют, работает ли система так, как задумано: принимает ли форма данные, корректно ли считается сумма, открывается ли нужная страница. Это основа тестирования любого продукта, и именно с таких образцов чек-листа обычно начинают.
📌 Чек-лист теста формы регистрации
- Сценарий: проверка формы создания нового аккаунта на веб-сервисе
- Адресат: QA-инженер, разработчик, тестировщик без специализации
- Задача: убедиться, что форма принимает корректные данные, отклоняет некорректные и корректно сообщает об ошибках
Пример:
Чек-лист теста: форма регистрации
Продукт: [Название сервиса] Версия: [Номер версии] Дата: [Дата проверки] Тестировщик: [Имя]
1. Поля ввода – корректные данные
- [ ] Поле "Email" принимает адрес в формате name@domain.ru
- [ ] Поле "Пароль" принимает строку от 8 символов
- [ ] Поле "Имя" принимает кириллицу и латиницу
- [ ] Поле "Телефон" принимает номер в формате +7 900 000-00-00
- [ ] Чекбокс "Согласен с условиями" можно отметить и снять
2. Поля ввода – некорректные данные
- [ ] Email без знака @ – форма показывает ошибку
- [ ] Email с пробелом внутри – форма показывает ошибку
- [ ] Пароль из 4 символов – форма показывает ошибку
- [ ] Пустое обязательное поле – форма блокирует отправку
- [ ] Поле "Имя" с цифрами – форма реагирует согласно требованиям
- [ ] SQL-инъекция в поле "Имя" – форма не ломается
3. Сообщения об ошибках
- [ ] Сообщение об ошибке появляется рядом с нужным полем
- [ ] Текст ошибки понятен пользователю
- [ ] После исправления ошибки сообщение исчезает
- [ ] Форма не сбрасывает корректно заполненные поля при ошибке
4. Отправка формы
- [ ] При корректных данных форма отправляется
- [ ] После отправки пользователь получает письмо подтверждения
- [ ] Повторная регистрация с тем же email – форма сообщает о дубле
- [ ] Кнопка "Зарегистрироваться" блокируется после первого клика (защита от дублей)
5. Технические проверки
- [ ] Форма работает в браузерах Chrome, Firefox, Safari, Edge
- [ ] Форма корректно отображается на мобильном устройстве
- [ ] Передача данных идет по HTTPS
- [ ] Поле "Пароль" маскирует символы при вводе
- Почему подходит: Форма регистрации – критический элемент любого сервиса. Этот шаблон чек-листа покрывает позитивные, негативные и технические сценарии, что соответствует минимально достаточному уровню проверки.
- Что важно не выкидывать: Блок с некорректными данными и блок с сообщениями об ошибках – именно там чаще всего находят баги в реальных проектах.
- Как адаптировать: Если форма содержит дополнительные поля (дата рождения, город, промокод), добавьте отдельные строки в блок "Корректные данные" и "Некорректные данные".
📌 Чек-лист теста корзины интернет-магазина
- Сценарий: проверка функционала корзины на e-commerce платформе
- Адресат: QA-инженер, разработчик, приемочное тестирование
- Задача: убедиться, что корзина корректно добавляет, хранит и удаляет товары, правильно считает суммы
Пример:
Чек-лист теста: корзина интернет-магазина
Продукт: [Название магазина / платформы] Версия: [Номер версии] Дата: [Дата проверки]
1. Добавление товаров
- [ ] Товар добавляется в корзину с карточки товара
- [ ] Товар добавляется в корзину из листинга (каталога)
- [ ] Счетчик товаров в иконке корзины обновляется
- [ ] При добавлении того же товара количество увеличивается, а не создается дубль
- [ ] Товар с выбором вариантов (размер, цвет) добавляется с нужным вариантом
2. Управление количеством
- [ ] Кнопки "+" и "–" изменяют количество товара
- [ ] При уменьшении до 0 товар удаляется или появляется подтверждение удаления
- [ ] Ручной ввод количества работает корректно
- [ ] Ввод отрицательного числа или нуля – корзина обрабатывает без ошибок
- [ ] Количество ограничено остатком на складе – при превышении выводится сообщение
3. Удаление товаров
- [ ] Товар удаляется кнопкой "Удалить"
- [ ] После удаления последнего товара корзина показывает состояние "пусто"
- [ ] Удаленный товар не восстанавливается при обновлении страницы
4. Расчет стоимости
- [ ] Итоговая сумма считается корректно при изменении количества
- [ ] Промокод применяется и уменьшает сумму
- [ ] Недействительный промокод – выводится сообщение об ошибке
- [ ] Стоимость доставки отображается и учитывается в итоге
- [ ] При бесплатной доставке от суммы – порог отображается корректно
5. Сохранение состояния
- [ ] Корзина сохраняется после закрытия и повторного открытия браузера (авторизованный пользователь)
- [ ] Корзина сохраняется в сессии неавторизованного пользователя
- [ ] После авторизации корзина гостя объединяется с корзиной аккаунта
6. Переход к оформлению заказа
- [ ] Кнопка "Оформить заказ" ведет на страницу оформления
- [ ] Неавторизованный пользователь перенаправляется на вход или может оформить как гость
- [ ] Товары из корзины переносятся в заказ без изменений
- Почему подходит: Корзина – один из ключевых конверсионных элементов магазина. Ошибки в расчете суммы или потеря товаров при обновлении страницы напрямую влияют на выручку.
- Что важно не выкидывать: Блок "Сохранение состояния" часто пропускают – а именно там теряются заказы неавторизованных пользователей.
- Как адаптировать: Если магазин работает с подписками или комплектами, добавьте отдельный блок для этих сценариев.
📌 Чек-лист теста личного кабинета пользователя
- Сценарий: проверка раздела управления аккаунтом в веб-сервисе или мобильном приложении
- Задача: убедиться, что пользователь может управлять своими данными, историей и настройками без ошибок
Пример:
Чек-лист теста: личный кабинет
Продукт: [Название сервиса] Дата: [Дата проверки]
1. Авторизация и доступ
- [ ] Авторизованный пользователь попадает в кабинет без повторного входа
- [ ] Неавторизованный пользователь перенаправляется на страницу входа
- [ ] Прямой URL кабинета недоступен без авторизации
2. Просмотр и редактирование профиля
- [ ] Отображаются имя, email, телефон – данные соответствуют реальным
- [ ] Поля редактируются и сохраняются
- [ ] После сохранения данные обновляются без перезагрузки страницы (или с корректной перезагрузкой)
- [ ] Попытка сохранить email в некорректном формате – выводится ошибка
- [ ] Смена пароля: требуется ввод старого пароля
- [ ] Новый пароль, не соответствующий требованиям, – выводится ошибка
3. История операций
- [ ] История заказов / транзакций отображается
- [ ] Каждая запись содержит корректную дату, статус и сумму
- [ ] Детали операции открываются по клику
- [ ] Пагинация или подгрузка работает без ошибок
4. Настройки уведомлений
- [ ] Пользователь может включить и отключить email-уведомления
- [ ] Настройки сохраняются и применяются
- [ ] После отключения уведомлений письма не приходят
5. Выход из аккаунта
- [ ] Кнопка "Выйти" завершает сессию
- [ ] После выхода доступ к кабинету закрыт
- [ ] Кнопка "Назад" в браузере не возвращает в кабинет после выхода
- Почему подходит: Личный кабинет – зона повышенного риска для безопасности и UX. Проверки на прямой доступ по URL и поведение после выхода критичны и часто упускаются при базовом тестировании.
- Как адаптировать: Если в кабинете есть раздел с документами, подписками или реферальной программой – добавьте отдельные блоки для каждого.
📌 Чек-лист теста функции поиска
- Сценарий: проверка строки поиска на сайте или в приложении
- Задача: убедиться, что поиск выдает релевантные результаты, корректно обрабатывает крайние случаи и не ломается при нестандартном вводе
Пример:
Чек-лист теста: функция поиска
1. Базовый поиск
- [ ] Поиск по точному совпадению возвращает релевантные результаты
- [ ] Поиск по части слова работает (например, "ноут" находит "ноутбук")
- [ ] Поиск нечувствителен к регистру
- [ ] Поиск с опечаткой предлагает исправление или находит похожее
2. Крайние случаи
- [ ] Пустой запрос – поиск не запускается или выводит все результаты (согласно требованиям)
- [ ] Запрос из пробелов – обрабатывается корректно
- [ ] Очень длинный запрос (500+ символов) – поиск не ломается
- [ ] Спецсимволы в запросе (<, >, &, “, ‘) – поиск не ломается
- [ ] Запрос на кириллице и латинице в одной строке – обрабатывается
3. Результаты
- [ ] При отсутствии результатов выводится понятное сообщение
- [ ] Количество найденных результатов отображается
- [ ] Сортировка и фильтры работают корректно
- [ ] Пагинация результатов работает без ошибок
4. Производительность
- [ ] Результаты появляются за приемлемое время (ориентир: до 2 секунд)
- [ ] При быстром вводе (автодополнение) запросы не дублируются
- Почему подходит: Поиск – один из самых нагруженных компонентов по числу возможных вариантов ввода. Блок "Крайние случаи" защищает от XSS-уязвимостей и неожиданных падений при нестандартном пользовательском поведении.
- Что важно не выкидывать: Проверку спецсимволов – именно через них чаще всего проходят атаки типа XSS (межсайтовый скриптинг).
Чек-листы тестирования UX и интерфейса
UX-чек-листы проверяют не то, работает ли функционал технически, а то, насколько удобно и понятно он работает для конечного пользователя. Это отдельный пласт тестирования, который часто недооценивают – особенно в командах без выделенного UX-специалиста.
📌 Чек-лист UX-проверки мобильного приложения
- Сценарий: проверка нового или обновленного мобильного приложения перед релизом
- Адресат: QA-инженер, продакт-менеджер, дизайнер
- Задача: выявить проблемы удобства до того, как они дойдут до пользователей
Пример:
Чек-лист UX-проверки: мобильное приложение
Платформа: iOS / Android (нужное подчеркнуть)
Версия приложения: [Номер]
Устройство: [Модель и версия ОС]
1. Навигация
- [ ] Основные разделы доступны не более чем в 2 касания от главного экрана
- [ ] Кнопка "Назад" работает ожидаемо на каждом экране
- [ ] Нижняя навигационная панель (если есть) не перекрывает контент
- [ ] При глубокой вложенности есть понятный путь возврата
2. Текст и читаемость
- [ ] Размер шрифта достаточен для чтения без масштабирования
- [ ] Контраст текста соответствует стандартам доступности (WCAG AA)
- [ ] Длинные тексты не обрезаются без индикации
- [ ] Тексты кнопок однозначны и понятны без контекста
3. Сенсорное взаимодействие
- [ ] Кнопки и ссылки имеют достаточную зону касания (рекомендуется от 44×44 pt)
- [ ] Элементы управления не расположены вплотную друг к другу
- [ ] Жесты (свайп, пинч) работают предсказуемо
- [ ] Нет случайных срабатываний при скролле
4. Состояния загрузки и ошибок
- [ ] При загрузке данных отображается индикатор
- [ ] При потере соединения выводится понятное сообщение
- [ ] Пустые состояния экрана (нет данных) содержат подсказку пользователю
- [ ] Ошибки не выводятся техническим текстом (коды, стек-трейс)
5. Онбординг и первый запуск
- [ ] При первом запуске понятно, что делать дальше
- [ ] Запросы разрешений (геолокация, камера) сопровождаются объяснением зачем
- [ ] Онбординг можно пропустить
- Почему подходит: Мобильные приложения имеют свою специфику – маленький экран, касание вместо клика, жесты. Этот шаблон чек-листа закрывает именно мобильные UX-риски, а не общие.
- Термин: WCAG (Web Content Accessibility Guidelines) – международный стандарт доступности веб-контента. Уровень AA – базовый минимум для большинства продуктов.
- Как адаптировать: Для планшетов добавьте проверки ландшафтной ориентации и использования пространства на большом экране.
📌 Чек-лист проверки адаптивной верстки
- Сценарий: проверка корректного отображения сайта на разных устройствах и разрешениях
- Задача: убедиться, что верстка не ломается при изменении ширины экрана
Пример:
Чек-лист проверки адаптивной верстки
Проверяемые разрешения: 320px, 375px, 768px, 1024px, 1440px, 1920px
1. Общая структура
- [ ] Горизонтальная прокрутка отсутствует на всех разрешениях
- [ ] Блоки не выходят за пределы экрана
- [ ] Отступы и поля сохраняются на узких экранах
- [ ] Переходы между брейкпоинтами плавные, без резких скачков
2. Изображения и медиа
- [ ] Изображения масштабируются пропорционально
- [ ] Изображения не вылезают за контейнер
- [ ] Видео корректно масштабируется и не выходит за рамки
3. Текст
- [ ] Текст не обрезается и не перекрывается другими элементами
- [ ] Заголовки уменьшаются на узких экранах, но остаются читаемыми
- [ ] Длинные слова или URL не ломают верстку
4. Навигация
- [ ] На мобильных экранах меню переходит в бургер или другой мобильный формат
- [ ] Мобильное меню открывается и закрывается корректно
- [ ] Ссылки в меню кликабельны и ведут на нужные страницы
5. Формы и кнопки
- [ ] Поля форм не выходят за пределы экрана
- [ ] Кнопки полностью отображаются и кликабельны
- [ ] Клавиатура не перекрывает активное поле ввода на мобильных
- Почему подходит: Адаптивность – обязательное требование для современных сайтов. Этот образец чек-листа покрывает типовые точки поломки верстки при разных разрешениях.
- Термин: Брейкпоинт – точка разрешения экрана, при которой меняется компоновка страницы.
- Как адаптировать: Добавьте конкретные разрешения, релевантные вашей аудитории, на основе аналитики реальных устройств.
📌 Чек-лист проверки онбординга нового пользователя
- Сценарий: проверка процесса первого знакомства пользователя с продуктом
- Задача: убедиться, что новый пользователь понимает, что делать, и доходит до первого ключевого действия
Пример:
Чек-лист проверки онбординга
1. Первый экран после регистрации
- [ ] Пользователю понятно, что он попал в нужное место
- [ ] Есть четкое следующее действие или подсказка
- [ ] Экран не перегружен информацией
2. Подсказки и туториал
- [ ] Подсказки появляются в нужный момент, а не все сразу
- [ ] Туториал можно пропустить
- [ ] Туториал можно перезапустить из настроек
- [ ] Подсказки не перекрывают ключевые элементы интерфейса
3. Первое ключевое действие
- [ ] Пользователь может совершить первое ключевое действие без посторонней помощи
- [ ] После первого действия есть положительная обратная связь (сообщение, анимация)
- [ ] Ошибка при первом действии сопровождается понятной подсказкой
4. Письма и уведомления
- [ ] Письмо-приветствие приходит своевременно
- [ ] Письмо содержит полезную информацию, а не только "Добро пожаловать"
- [ ] Ссылки в письме рабочие
- Почему подходит: Онбординг напрямую влияет на активацию пользователей. Проблемы в этом сценарии не всегда видны в стандартных функциональных тестах, но критически влияют на удержание.
Чек-листы регрессионного тестирования
Регрессионный тест – это проверка того, что после изменений в коде старая функциональность не сломалась. Такие чек-листы строятся на основе уже работавшего функционала и обновляются при каждом релизе. Это один из самых практичных шаблонов чек-листа для команд с регулярными выпусками.
📌 Чек-лист регрессии после обновления платежного модуля
- Сценарий: выход обновления платежного модуля или смена платежного провайдера
- Задача: убедиться, что оплата работает корректно и смежные функции не пострадали
Пример:
Чек-лист регрессии: платежный модуль
Версия до изменений: [X.X] Версия после изменений: [X.X] Дата: [Дата]
1. Основной сценарий оплаты
- [ ] Оплата банковской картой проходит успешно (тестовая карта)
- [ ] Оплата через электронный кошелек проходит успешно
- [ ] После успешной оплаты заказ переходит в статус "Оплачен"
- [ ] Пользователь получает письмо с подтверждением оплаты
2. Сценарии ошибок
- [ ] Оплата с недостаточным балансом – корректное сообщение об ошибке
- [ ] Оплата с истекшей картой – корректное сообщение
- [ ] Таймаут на стороне банка – система не зависает, выводится сообщение
- [ ] Двойная оплата не проходит (защита от дублей)
3. Смежный функционал
- [ ] Корзина сохраняется при переходе на страницу оплаты
- [ ] Промокоды применяются до оплаты корректно
- [ ] Возврат средств (если поддерживается) работает через административную панель
- [ ] История платежей в личном кабинете обновляется
4. Безопасность
- [ ] Данные карты не сохраняются на сервере в открытом виде
- [ ] Платежная страница работает по HTTPS
- [ ] 3D Secure (если используется) запрашивается корректно
- Почему подходит: Платежный модуль – зона нулевой терпимости к ошибкам. Регрессионный чек-лист для него должен покрывать не только успешный сценарий, но и все виды отказов.
- Термин: 3D Secure – дополнительный уровень проверки при оплате картой (SMS-код или подтверждение в банковском приложении).
📌 Чек-лист регрессии при выходе новой версии мобильного приложения
- Сценарий: выход обновления мобильного приложения
- Задача: убедиться, что ключевые сценарии работают после обновления на обеих платформах
Пример:
Чек-лист регрессии: мобильное приложение v[X.X]
Платформы: iOS, Android
Дата: [Дата]
1. Установка и запуск
- [ ] Обновление устанавливается без ошибок
- [ ] Приложение запускается после обновления
- [ ] Данные пользователя сохранились после обновления
- [ ] Сессия активна (не требует повторного входа без причины)
2. Ключевые сценарии
- [ ] Авторизация работает
- [ ] Основной пользовательский сценарий выполняется от начала до конца
- [ ] Push-уведомления приходят корректно
- [ ] Работа в офлайн-режиме (если поддерживается) не нарушена
3. Производительность
- [ ] Время запуска не увеличилось по сравнению с предыдущей версией
- [ ] Нет заметных зависаний или лагов в основных сценариях
- [ ] Потребление памяти в норме (нет утечек при длительном использовании)
4. Специфика платформ
- [ ] На iOS: приложение проходит проверку на актуальной версии операционной системы
- [ ] На Android: приложение работает на минимально поддерживаемой версии ОС
- [ ] Разрешения приложения не изменились без причины
- Почему подходит: Регрессия для мобильного приложения требует проверки на двух платформах с разными версиями ОС. Этот шаблон фиксирует именно те точки, где обновления чаще всего ломают старое поведение.
Чек-листы тестирования безопасности
Тестирование безопасности – отдельная область, требующая специальных знаний. Но базовый чек-лист проверки безопасности доступен любому тестировщику и должен быть частью стандартного процесса. Ниже – рабочие образцы для наиболее частых сценариев.
📌 Чек-лист базовой проверки безопасности веб-приложения
- Сценарий: базовая security-проверка веб-приложения перед релизом или аудитом
- Задача: выявить наиболее распространенные уязвимости без использования специализированных инструментов
Пример:
Чек-лист базовой проверки безопасности
1. Передача данных
- [ ] Весь сайт работает по HTTPS
- [ ] HTTP-запросы перенаправляются на HTTPS
- [ ] Сертификат SSL действителен и не просрочен
- [ ] Чувствительные данные не передаются в URL (в GET-параметрах)
2. Авторизация и аутентификация
- [ ] Пароли хранятся в хешированном виде (не в открытом тексте)
- [ ] Нет возможности перебора паролей без ограничений (captcha или блокировка)
- [ ] Сессия завершается после выхода
- [ ] Токен сессии меняется после входа
- [ ] Доступ к чужим данным по прямому URL невозможен
3. Формы и ввод данных
- [ ] Поля форм фильтруют HTML-теги и скрипты (защита от XSS)
- [ ] SQL-инъекция через поля ввода не приводит к ошибкам базы данных
- [ ] Файловые загрузки ограничены по типу и размеру
- [ ] Загруженные файлы не исполняются на сервере
4. Сообщения об ошибках
- [ ] Ошибки не раскрывают техническую информацию (стек-трейс, путь к файлам)
- [ ] При неверном логине сообщение не указывает, что именно неверно (логин или пароль)
5. Заголовки HTTP
- [ ] Присутствует заголовок Content-Security-Policy
- [ ] Присутствует заголовок X-Frame-Options (защита от clickjacking)
- [ ] Заголовок Server не раскрывает версию серверного ПО
- Почему подходит: Этот шаблон чек-листа закрывает топ уязвимостей из списка OWASP Top 10 на базовом уровне – без специализированных инструментов и навыков пентестера.
- Термин: XSS (Cross-Site Scripting) – тип атаки, при которой злоумышленник внедряет вредоносный скрипт на страницу через незащищенное поле ввода. Clickjacking – атака, при которой пользователь кликает по скрытому элементу, думая, что кликает по другому.
- Что важно не выкидывать: Блок "Сообщения об ошибках" – часто игнорируют, но именно там происходит утечка информации о структуре системы.
📌 Чек-лист проверки авторизации и прав доступа
- Сценарий: проверка разграничения прав между ролями пользователей
- Задача: убедиться, что пользователь не может получить доступ к функциям и данным, которые ему не разрешены
Пример:
Чек-лист проверки прав доступа
Роли в системе: [Перечислить роли, например: гость, пользователь, модератор, администратор]
1. Доступ к разделам
- [ ] Гость не имеет доступа к закрытым разделам
- [ ] Пользователь не имеет доступа к административным функциям
- [ ] Модератор видит только те данные, которые разрешены его ролью
- [ ] Прямой URL к закрытому разделу перенаправляет на страницу входа или выдает 403
2. Действия с данными
- [ ] Пользователь не может редактировать данные другого пользователя через API
- [ ] Пользователь не может удалить чужой объект, подставив чужой ID в запросе
- [ ] Массовые операции доступны только администратору
3. API-запросы
- [ ] Запросы без токена авторизации возвращают 401
- [ ] Запросы с токеном роли "пользователь" к эндпоинтам администратора возвращают 403
- [ ] Токен одного пользователя не дает доступ к данным другого
- Почему подходит: Нарушение разграничения прав – одна из самых частых и критических уязвимостей в веб-приложениях. Этот чек-лист проверяет именно IDOR-уязвимости (несанкционированный доступ к объектам через подстановку идентификаторов) и вертикальное эскалирование привилегий.
- Термин: 401 – ошибка "Не авторизован". 403 – ошибка "Запрещено". IDOR (Insecure Direct Object Reference) – уязвимость, позволяющая получить доступ к чужим данным, подменив ID в запросе.
Чек-листы тестирования API
API-тестирование – обязательная часть работы с современными веб-сервисами и мобильными приложениями. Чек-листы для API помогают системно проверить корректность запросов, обработку ошибок и соответствие документации.
📌 Чек-лист тестирования REST API
- Сценарий: проверка REST API нового или обновленного эндпоинта
- Адресат: QA-инженер, backend-разработчик
- Задача: убедиться, что API возвращает корректные данные и коды ответов во всех сценариях
Пример:
Чек-лист тестирования REST API
Эндпоинт: [Название и URL, например: GET /api/v1/users/{id}] Документация: [Ссылка на спецификацию]
1. Позитивные сценарии
- [ ] Запрос с корректными параметрами возвращает код 200
- [ ] Тело ответа соответствует схеме из документации
- [ ] Все обязательные поля присутствуют в ответе
- [ ] Типы данных в ответе соответствуют спецификации (строка, число, булево)
- [ ] Пагинация работает корректно (параметры page, limit)
2. Негативные сценарии
- [ ] Запрос без обязательного параметра возвращает 400 с понятным сообщением
- [ ] Запрос с несуществующим ID возвращает 404
- [ ] Запрос без токена авторизации возвращает 401
- [ ] Запрос с невалидным токеном возвращает 401
- [ ] Запрос с неверным типом данных (строка вместо числа) возвращает 400
3. Граничные значения
- [ ] Минимально допустимое значение параметра – обрабатывается корректно
- [ ] Максимально допустимое значение – обрабатывается корректно
- [ ] Значение, превышающее максимум, – возвращает ошибку
- [ ] Пустая строка в строковом параметре – обрабатывается согласно спецификации
4. Производительность и заголовки
- [ ] Время ответа не превышает допустимый порог (ориентир: до 500 мс для простых запросов)
- [ ] Заголовок Content-Type в ответе соответствует формату данных
- [ ] CORS-заголовки настроены корректно (если нужны)
- Почему подходит: Этот образец чек-листа покрывает три уровня проверки API: позитивные, негативные и граничные сценарии. Именно такая трехуровневая структура дает уверенность в надежности эндпоинта.
- Термин: CORS (Cross-Origin Resource Sharing) – механизм, который позволяет или запрещает запросы к API с других доменов.
📌 Чек-лист проверки обработки ошибок API
- Сценарий: специализированная проверка только сценариев ошибок в API
- Задача: убедиться, что API корректно и безопасно обрабатывает все нештатные ситуации
Пример:
Чек-лист проверки обработки ошибок API
1. Коды ответов
- [ ] Ошибки клиента возвращают коды 4xx, а не 2xx или 5xx
- [ ] Ошибки сервера возвращают коды 5xx с нейтральным сообщением
- [ ] Код ответа соответствует реальной ситуации (не используется 200 для ошибок)
2. Тело ошибки
- [ ] Тело ошибки содержит понятное описание проблемы
- [ ] Тело ошибки не содержит стек-трейс или внутренние пути
- [ ] Структура ошибки единообразна для всех эндпоинтов
- [ ] Для нескольких ошибок валидации возвращаются все ошибки сразу, а не только первая
3. Нестандартные ситуации
- [ ] Запрос с неверным Content-Type – API возвращает понятную ошибку
- [ ] Очень большое тело запроса – API возвращает 413 или аналог
- [ ] Запрос с неподдерживаемым методом (например, DELETE вместо GET) – возвращает 405
- [ ] Одновременные запросы не приводят к гонке данных
- Почему подходит: Обработка ошибок – часто недотестированная зона. Плохая обработка ошибок приводит к утечкам информации и ухудшению пользовательского опыта при нештатных ситуациях.
- Термин: 413 – код ошибки "Слишком большое тело запроса". 405 – "Метод не разрешен".
Чек-листы нефункционального тестирования
Нефункциональное тестирование проверяет не то, что делает система, а то, как она это делает: насколько быстро, стабильно и под какой нагрузкой. Такие чек-листы часто нужны перед запуском высоконагруженных систем или при подготовке к сезонным пикам трафика.
📌 Чек-лист нагрузочного тестирования
- Сценарий: подготовка и проведение нагрузочного теста перед запуском или пиковым периодом
- Задача: убедиться, что система выдерживает ожидаемую нагрузку без деградации качества
Пример:
Чек-лист нагрузочного тестирования
1. Подготовка
- [ ] Определены целевые показатели нагрузки (количество одновременных пользователей)
- [ ] Определены критерии успеха (время ответа, процент ошибок)
- [ ] Тестовое окружение максимально близко к продакшену
- [ ] Тестовые данные подготовлены в достаточном объеме
- [ ] Инструменты нагрузочного тестирования настроены и проверены
2. Проведение теста
- [ ] Тест выполнен при целевой нагрузке
- [ ] Тест выполнен при нагрузке в 1.5–2 раза выше целевой (стресс-тест)
- [ ] Тест длился достаточно долго для выявления утечек памяти (не менее 30 минут)
- [ ] В процессе теста фиксировались метрики: CPU, RAM, время ответа, ошибки
3. Анализ результатов
- [ ] Время ответа при целевой нагрузке укладывается в норму
- [ ] Процент ошибок при целевой нагрузке не превышает допустимый (ориентир: менее 1%)
- [ ] При снижении нагрузки система восстанавливается до нормальных показателей
- [ ] Узкие места идентифицированы и зафиксированы
- Почему подходит: Нагрузочный тест без четкого чек-листа часто превращается в хаотичный прогон без четких критериев успеха. Этот образец задает правильную структуру: подготовка → проведение → анализ.
- Термин: Продакшн (production) – боевая среда, в которой работают реальные пользователи. Стресс-тест – проверка системы при нагрузке, превышающей ожидаемую.
📌 Чек-лист тестирования производительности страницы
- Сценарий: проверка скорости загрузки конкретной страницы сайта
- Задача: убедиться, что страница загружается быстро и не теряет позиции в поиске из-за низкой производительности
Пример:
Чек-лист производительности страницы
Страница: [URL] Инструменты проверки: PageSpeed Insights, Lighthouse, WebPageTest
1. Ключевые метрики
- [ ] LCP (Largest Contentful Paint) – не более 2.5 секунды
- [ ] FID (First Input Delay) или INP – не более 200 мс
- [ ] CLS (Cumulative Layout Shift) – не более 0.1
- [ ] TTFB (Time to First Byte) – не более 800 мс
2. Изображения
- [ ] Изображения сжаты и оптимизированы
- [ ] Используется современный формат (WebP, AVIF)
- [ ] Изображения ниже линии сгиба загружаются лениво (lazy load)
- [ ] Размеры изображений указаны в HTML (предотвращает CLS)
3. Ресурсы страницы
- [ ] CSS и JavaScript минифицированы
- [ ] Неиспользуемый CSS и JS удален или загружается асинхронно
- [ ] Шрифты загружаются оптимально (preload, font-display: swap)
- [ ] Кеширование статических ресурсов настроено
- Почему подходит: Core Web Vitals (LCP, FID/INP, CLS) – официальные метрики Google, влияющие на ранжирование в поиске. Этот чек-лист напрямую привязан к реальным SEO-последствиям.
- Термин: Lazy load – отложенная загрузка изображений, которые не видны на экране при первом открытии страницы. CLS – смещение элементов страницы в процессе загрузки.
Короткие чек-листы для быстрых проверок
Smoke, sanity и предрелизные проверки – это быстрые форматы, которые занимают минимум времени, но дают уверенность в базовой работоспособности системы. Такие чек-листы используют после каждого деплоя, перед демонстрацией клиенту или перед выходом релиза.
📌 Чек-лист smoke-теста после деплоя
- Сценарий: быстрая проверка после каждого деплоя на тестовое или боевое окружение
- Задача: убедиться, что система запустилась и критические функции работают
Пример:
Чек-лист smoke-теста
Версия: [Номер деплоя] Окружение: [Тест / Прод] Время: [Время деплоя]
- [ ] Главная страница открывается без ошибок
- [ ] Авторизация работает (тестовый аккаунт)
- [ ] Основной пользовательский сценарий доступен (без прохождения полностью)
- [ ] API отвечает на базовый запрос
- [ ] Нет критических ошибок в логах (500, 503)
- [ ] Платежная страница открывается (если применимо)
- Почему подходит: Smoke-тест – это "дымовая проверка": если система не загорелась при первом запуске, можно продолжать. Он не заменяет полное тестирование, но экономит время при обнаружении катастрофических проблем сразу после деплоя.
- Термин: Деплой – развертывание новой версии кода на сервере.
📌 Чек-лист sanity-проверки конкретной функции
- Сценарий: быстрая проверка конкретной функции после исправления бага или небольшого изменения
- Задача: убедиться, что исправление работает и ничего очевидного не сломалось рядом
Пример:
Чек-лист sanity-проверки: функция применения промокода
Баг / задача: [Номер задачи – например, TASK-1234] Дата: [Дата]
- [ ] Корректный промокод применяется и уменьшает сумму заказа
- [ ] Некорректный промокод отклоняется с понятным сообщением
- [ ] Истекший промокод отклоняется
- [ ] Промокод на конкретную категорию не применяется к другим товарам
- [ ] Итоговая сумма пересчитывается корректно после применения
- [ ] Корзина не ломается при применении промокода
- Почему подходит: Sanity-тест проверяет "здравый смысл" – что конкретная функция работает разумно после изменений. Он короче регрессии, но точнее smoke-теста.
📌 Чек-лист предрелизной проверки
- Сценарий: финальная проверка перед выходом релиза в продакшн
- Задача: убедиться, что команда сделала все необходимое перед публичным выпуском
Пример:
Чек-лист предрелизной проверки
Версия: [Номер] Дата релиза: [Дата] Ответственный: [Имя]
1. Тестирование
- [ ] Все задачи релиза прошли тестирование
- [ ] Критические и высокие баги закрыты
- [ ] Регрессионный чек-лист пройден
- [ ] Smoke-тест на тестовом окружении пройден
2. Документация
- [ ] Release notes подготовлены
- [ ] Пользовательская документация обновлена (если нужно)
- [ ] Внутренние инструкции обновлены (если нужно)
3. Инфраструктура
- [ ] Бэкап базы данных сделан перед деплоем
- [ ] План отката подготовлен
- [ ] Мониторинг настроен и активен
- [ ] Команда поддержки уведомлена о релизе
4. Коммуникация
- [ ] Стейкхолдеры уведомлены о дате и времени релиза
- [ ] Техническое окно для деплоя согласовано
- [ ] Контакт ответственного за релиз доступен
- Почему подходит: Предрелизный чек-лист – это не только про тестирование. Он охватывает документацию, инфраструктуру и коммуникацию – три зоны, где чаще всего возникают проблемы при выпуске.
- Термин: Release notes – краткое описание изменений в новой версии. Стейкхолдеры – все заинтересованные стороны: бизнес, клиенты, команды поддержки.
Как создать чек-лист теста. Правила и этапы сборки с примерами
Примеры выше показывают рабочую логику разных форматов. Теперь разберем, как собрать свой чек-лист теста с нуля – не копируя чужое содержание, а применяя ту же структурную логику к своей задаче.
Базовая схема сборки чек-листа теста:
- Шаг 1. Определить объект тестирования (что именно проверяем)
- Шаг 2. Определить тип чек-листа (функциональный, UX, регрессионный, безопасность, API, нагрузка, быстрый)
- Шаг 3. Выделить основные блоки проверок
- Шаг 4. Внутри каждого блока сформулировать конкретные пункты
- Шаг 5. Добавить заголовок с метаданными (версия, дата, тестировщик)
- Шаг 6. Проверить полноту: есть ли позитивные, негативные и граничные сценарии
| Блок | Зачем нужен | Что сюда подставляется | Пример заполнения |
| Заголовок и метаданные | Идентифицировать чек-лист и контекст его применения | Название объекта, версия, дата, тестировщик | Чек-лист теста: форма оформления заказа. Версия 2.3. Дата: 15.09.2025 |
| Позитивные сценарии | Убедиться, что система работает при корректных данных | Нормальные входные данные, ожидаемое поведение | Форма с корректными данными отправляется и создает заказ |
| Негативные сценарии | Убедиться, что система корректно обрабатывает ошибки | Некорректные данные, пустые поля, невалидные форматы | Поле "Телефон" с буквами – форма показывает ошибку |
| Граничные значения | Проверить поведение на краях допустимого диапазона | Минимальные и максимальные значения, пограничные случаи | Поле "Имя": 1 символ, 255 символов, 256 символов |
| Технические проверки | Убедиться в кроссбраузерности, безопасности, производительности | Браузеры, устройства, протоколы, заголовки | Форма работает в Chrome, Firefox, Safari на мобильных и десктопе |
| Смежный функционал | Убедиться, что изменения не сломали соседние компоненты | Связанные функции, данные, которые передаются дальше | После отправки формы заказ появляется в административной панели |
Пошаговая сборка на одном кейсе
Сценарий: нужно составить чек-лист теста для формы добавления товара в личном кабинете продавца на маркетплейсе.
Шаг 1. Определяем объект тестирования.
Форма добавления товара: поля "Название", "Описание", "Цена", "Категория", "Фото", "Количество на складе".
Шаг 2. Определяем тип чек-листа.
Функциональный – проверяем, что форма работает согласно требованиям.
Шаг 3. Выделяем блоки.
Поля ввода (позитив), поля ввода (негатив), загрузка фото, сохранение товара, смежный функционал.
Шаг 4. Формулируем пункты внутри блоков.
Шаг 5. Добавляем заголовок.
"Чек-лист теста: форма добавления товара. Версия [X.X]. Дата: [дата]. Тестировщик: [имя]".
Шаг 6. Проверяем полноту.
Есть позитив (корректные данные), негатив (некорректные), граница (максимальная длина описания, максимальный размер фото), технические (браузеры, мобильные), смежный (товар появляется в каталоге).
Готовая собранная версия:
Чек-лист теста: форма добавления товара
Продукт: [Название маркетплейса] Версия: [Номер] Дата: [Дата] Тестировщик: [Имя]
1. Поля ввода – корректные данные
- [ ] Поле "Название" принимает текст до 255 символов
- [ ] Поле "Описание" принимает текст с переносами строк
- [ ] Поле "Цена" принимает число с двумя знаками после запятой
- [ ] Поле "Категория" позволяет выбрать значение из списка
- [ ] Поле "Количество" принимает целое положительное число
2. Поля ввода – некорректные данные
- [ ] Пустое обязательное поле – форма блокирует сохранение
- [ ] Цена с буквами – форма показывает ошибку
- [ ] Отрицательная цена – форма показывает ошибку
- [ ] Название длиннее 255 символов – форма ограничивает ввод или показывает ошибку
3. Загрузка фото
- [ ] Фото в форматах JPG, PNG загружается
- [ ] Файл не в формате изображения – форма показывает ошибку
- [ ] Файл больше допустимого размера – форма показывает ошибку
- [ ] Загруженное фото отображается в предпросмотре
4. Сохранение товара
- [ ] При корректных данных товар сохраняется
- [ ] После сохранения выводится подтверждение
- [ ] Кнопка "Сохранить" блокируется после первого клика (защита от дублей)
5. Смежный функционал
- [ ] Сохраненный товар появляется в списке товаров продавца
- [ ] Товар отображается в каталоге маркетплейса (если статус "Активен")
- [ ] Данные товара совпадают с введенными в форме
Границы применимости и типичные ошибки
Когда схема работает: для любого функционального тестирования форм, модулей, API-эндпоинтов с четко описанными требованиями.
Где схема ломается: если требований нет – сначала нужно их зафиксировать, иначе чек-лист будет строиться на предположениях. Для нагрузочного тестирования структура будет другой – там важны метрики и условия теста, а не поля ввода.
Что нельзя выкидывать: блок негативных сценариев – именно там находят большинство реальных багов. Блок смежного функционала – без него чек-лист тестирует компонент в вакууме.
Что можно менять: порядок блоков, их названия, количество пунктов – в зависимости от сложности объекта тестирования.
Что нельзя переносить бездумно из чужого чек-листа: конкретные пункты, привязанные к чужому продукту. Структуру блоков – можно, конкретные проверки – только после адаптации под свои требования.
Практические советы по работе с чек-листами теста
| Совет | Почему важен | Как применять |
| Начинайте с требований | Без требований чек-лист строится на догадках | Перед составлением прочитайте ТЗ, спецификацию или пользовательские истории |
| Всегда включайте негативные сценарии | Большинство багов – в обработке ошибок, а не в позитивном пути | Для каждого позитивного пункта спросите: "Что будет, если данные неверны?" |
| Проверяйте граничные значения | Ошибки часто скрываются на краях допустимого диапазона | Тестируйте минимум, максимум и значение за пределами максимума |
| Обновляйте чек-лист после каждого релиза | Устаревший чек-лист пропускает новые баги | После каждого релиза добавляйте пункты для новых функций |
| Не делайте чек-лист слишком детальным | Избыточная детализация превращает чек-лист в тест-кейс | Один пункт = одна проверка, а не пошаговая инструкция |
| Разделяйте чек-листы по типам | Смешанный чек-лист сложнее поддерживать и применять | Держите функциональные, регрессионные и smoke-чек-листы раздельно |
| Фиксируйте результат каждого пункта | Без фиксации непонятно, что проверено, а что нет | Используйте метки: ✅ Пройдено / ❌ Не пройдено / ⏭ Пропущено (с причиной) |
6 приемов, которые улучшат любой чек-лист теста:
- Используйте активные формулировки. "Форма отправляется" вместо "Проверить отправку формы" – так проще понять, что именно считается успешным результатом.
- Группируйте пункты по смысловым блокам. Не пишите все в одну колонку – разбивайте по функциям, сценариям или компонентам.
- Добавляйте метаданные. Версия, дата, окружение, тестировщик – без этого чек-лист теряет контекст через неделю.
- Не дублируйте тест-кейсы. Чек-лист проверяет "что", тест-кейс – "как". Не смешивайте форматы в одном документе.
- Приоритизируйте пункты. Отмечайте критические проверки – при нехватке времени тестировщик знает, что нельзя пропустить.
- Проводите ревью чек-листа. Попросите коллегу проверить список – свежий взгляд часто находит пропущенные сценарии.
Хорошие примеры чек-листа теста – это не просто готовые тексты для копирования, а рабочие образцы структуры и логики. Используйте их как отправную точку: берите структуру блоков, адаптируйте пункты под свои требования и дополняйте специфическими сценариями вашего продукта. Именно так чек-лист становится реально полезным инструментом, а не формальным документом.
Системный подход к составлению чек-листов экономит время при каждом следующем тестировании: однажды выстроенная структура становится основой для регрессионных, smoke- и предрелизных проверок – достаточно обновлять ее, а не создавать заново.
