Как написать позитивный тест кейс для формы авторизации с логином и паролем

Что проверяют

Умеете ли вы оформить проверку так, чтобы её мог пройти любой коллега и получить однозначный результат. Позитивный вход выбирают специально: он кажется тривиальным, и по нему сразу видно, пишете вы «ввести корректные данные» или конкретные шаги. Следом просят назвать ещё несколько позитивных кейсов для той же формы, а затем негативные.

Как отвечать

Проговорите структуру кейса и заполните её конкретикой:

• заголовок: коротко и проверяемо, например «Вход с валидными email и паролем по кнопке входа»;
• предусловия: существует активный пользователь qa_user@test.local с паролем Qwerty123!, учётная запись не заблокирована, двухфакторная аутентификация отключена, пользователь не залогинен, открыта страница /login;
• шаги: ввести email в поле логина, ввести пароль, нажать кнопку входа. Каждый шаг это одно действие;
• ожидаемый результат: к каждому значимому шагу. Пароль в поле маскируется, после нажатия открывается /dashboard, в шапке видно имя пользователя, сообщений об ошибке нет;
• постусловия: выйти из системы, чтобы следующий кейс стартовал с чистого состояния;
• атрибуты: высокий приоритет, кейс входит в смоук и регресс, указаны окружение и браузер.

Затем покажите, что позитивный кейс не один: вход по клавише Enter, вход с отмеченным «Запомнить меня» и проверкой, что сессия переживает перезапуск браузера, email в другом регистре, если требования это разрешают, пароль максимально допустимой длины и со спецсимволами. Можно добавить проверку на уровне API: запрос к эндпоинту авторизации возвращает 200 и токен или сессионную куку с флагами HttpOnly и Secure.

Ожидаемый результат берётся из требований, а не из текущего поведения системы.

Где спотыкаются

Пишут данные абстрактно: «ввести корректный логин». Два тестировщика подставят разное, и кейс перестанет быть воспроизводимым.

Формулируют ожидаемый результат как «авторизация прошла успешно». Непонятно, что именно проверять глазами: адрес страницы, элемент интерфейса или текст.

Смешивают в одном кейсе позитивные и негативные проверки или пять разных сценариев. Когда такой кейс падает, по отчёту нельзя понять, что сломалось.