Составьте тест-кейсы для формы логина (email, пароль, кнопка «Войти»).
Короткий ответ
- Уточнить требования: правила пароля, блокировки, локали
- Позитив: валидная пара, вход, редирект, сессия
- Негатив: неверный пароль, несуществующий email, пустые поля
- Валидация формата email и граничных длин
- Безопасность: маскировка пароля, одинаковая ошибка, инъекции, брутфорс
- UX: Enter, копипаста, показать пароль, фокус, ошибки
- Нефункциональное: раскладка, мобильная версия, автозаполнение
Тест-кейсы на логин группируются по позитиву, валидации, безопасности и UX, а начинается всё с уточнения требований.
Как сказать вслух
пример ответаСначала уточню требования: правила к паролю, есть ли блокировка после неудачных попыток, что считается валидным email. Потом иду по группам. Позитив: вход с корректной парой, редирект, сессия сохраняется. Негатив: неверный пароль, несуществующий пользователь, пустые поля, невалидный формат email, граничные длины. Безопасность: пароль маскируется, текст ошибки не раскрывает, что именно неверно, попытки ограничены. И удобство: вход по Enter, вставка из буфера, понятные сообщения об ошибках.
Подробный ответ
Основной ответ
Структурированный набор строится по группам. Позитивные: вход с валидными данными, редирект на нужную страницу, сохранение сессии, повторный вход после выхода. Валидация полей: пустой email, пустой пароль, оба пустые; невалидные форматы email (без @, без домена, пробелы, кириллица в домене — по требованиям); граничные длины обоих полей по классам эквивалентности; пробелы в начале и конце (обычно email триммится, пароль — нет). Негативные по логике: неверный пароль, несуществующий аккаунт, заблокированный или неактивированный пользователь. Безопасность: маскирование пароля, одинаковое сообщение об ошибке для неверного пароля и несуществующего email (защита от перебора аккаунтов), ограничение попыток, SQL-инъекции и XSS в полях, пароль не попадает в URL и логи. UX: вход по Enter, кнопка «показать пароль», вставка из менеджера паролей, поведение при двойном клике по кнопке, состояние загрузки. Дополнительно: разные браузеры, мобильная вёрстка, автозаполнение. Каждый кейс оформляется с шагами и ожидаемым результатом; на интервью достаточно озвучить структуру и примеры из каждой группы.
Ключевые моменты
- Начинать с требований. Вопросы про правила пароля и блокировки показывают зрелость сильнее, чем длинный список проверок.
- Группировка вместо потока. Позитив, валидация, безопасность, UX — интервьюер видит систему, а не вспоминание наугад.
- Безопасность обязательна. Одинаковая ошибка, лимит попыток, маскирование — про это забывает большинство джунов.
- Классы и границы. Длины полей и форматы email проверяются техниками тест-дизайна, а не случайными значениями.
Практический контекст
Самое частое практическое задание на интервью джуниора, в том числе письменное. Оценивают структурность мышления, полноту (вспомнил ли про негатив и безопасность) и привычку уточнять требования до тестирования. Типичная ошибка — 15 позитивных проверок и ни одной про безопасность. Озвучивать группы стоит явно: «теперь блок безопасности» — это плюс к впечатлению.
Пример кода
# Проверки валидации логина в виде параметризованного pytest
import pytest
CASES = [
("user@test.com", "Correct1!", "success"),
("user@test.com", "wrong", "error"),
("ghost@test.com", "Correct1!", "error"),
("", "Correct1!", "email_required"),
("user@test.com", "", "password_required"),
("not-an-email", "Correct1!", "email_invalid"),
]
@pytest.mark.parametrize("email,password,expected", CASES)
def test_login_validation(api_client, email, password, expected):
resp = api_client.login(email=email, password=password)
assert resp.result == expectedЧастые ошибки
- Сразу перечисляют кейсы, не уточнив требования к полям и блокировкам
- Забывают проверки безопасности: перебор, инъекции, одинаковые сообщения об ошибках
- Называют только позитивные сценарии, а негатив вспоминают лишь по наводящим вопросам