Чек-листы и тест-кейсы

Зачем записывать проверки

Проверять «по памяти» можно, пока приложение маленькое. Как только экранов становится десятки, без записей начинаются проблемы:

• проверки забываются, особенно редкие;
• коллега, который вас подменит, не знает, что уже проверено;
• перед каждым выпуском одно и то же приходится вспоминать заново;
• нельзя показать, насколько хорошо функция проверена.

Поэтому проверки записывают. Самые частые форматы — чек-лист и тест-кейс.

Чек-лист

Чек-лист — список того, что нужно проверить, без подробных шагов. Его быстро составить и легко читать. Пример для формы входа:

1. Вход с правильными почтой и паролем.
2. Вход с неправильным паролем — понятное сообщение об ошибке.
3. Вход с незарегистрированной почтой.
4. Пустые поля — кнопка «Войти» неактивна или появляется подсказка.
5. Почта с пробелами в начале и в конце.
6. Пароль отображается точками, есть кнопка «показать».
7. Ссылка «Забыли пароль?» ведёт на восстановление.
8. После пяти неудачных попыток вход временно блокируется (если так написано в требованиях).

Чек-листы хороши для опытных тестировщиков и быстро меняющихся проектов.

Тест-кейс

Тест-кейс — подробный сценарий проверки. Его может выполнить даже человек, который видит приложение впервые. Обычно в нём есть:

• номер и название — коротко, что проверяем;
• предусловия — что должно быть готово до начала;
• шаги — действия по порядку;
• ожидаемый результат — что должно получиться.

Пример:

Поле	Значение
Номер	TC-012
Название	Вход с правильными почтой и паролем
Предусловия	Есть зарегистрированный пользователь test@example.com с паролем Qwerty123
Шаги	1. Открыть страницу входа. 2. Ввести почту test@example.com. 3. Ввести пароль Qwerty123. 4. Нажать «Войти».
Ожидаемый результат	Открывается личный кабинет, в шапке — имя пользователя

Тест-кейсы полезны там, где ошибка стоит дорого (банки, медицина), и для регресса — повторного прогона проверок перед каждым выпуском.

Позитивные и негативные проверки

• Позитивные — пользователь делает всё правильно, и приложение должно работать: вход с верным паролем, заказ с корректным адресом.
• Негативные — данные неправильные, и приложение должно корректно отреагировать: показать понятное сообщение, не упасть и не сохранить мусор. Например, буквы в поле телефона или дата рождения в будущем.

Новички часто проверяют только позитивные сценарии. А пользователи ошибаются постоянно — и именно там прячется много багов. Где ещё они любят прятаться — в уроке 3.

Как не перебирать всё подряд

Допустим, поле «Возраст» принимает целые числа от 18 до 60. Проверить все числа невозможно, да и не нужно. Помогают две техники тест-дизайна.

Классы эквивалентности. Делим все возможные значения на группы, внутри которых программа ведёт себя одинаково:

Класс	Пример	Ожидание
Меньше 18	10	Ошибка: слишком мало
От 18 до 60	35	Принимается
Больше 60	75	Ошибка: слишком много
Не число	«тридцать»	Ошибка: нужны цифры

Из каждого класса достаточно одного значения: если 35 принимается, то и 36 почти наверняка тоже.

Граничные значения. Ошибки любят края. Разработчик мог написать «больше 18» вместо «больше или равно 18» — и тогда 18-летнего не пустят. Поэтому проверяем сами границы и соседние значения: 17, 18, 60, 61.

Где хранят проверки

В небольших командах — в таблицах. В крупных — в специальных системах управления тестами: например, TestRail, Qase или Test IT. Они помогают отмечать, что проверено, и собирать отчёты перед выпуском. О них и других инструментах — в уроке 7.