Почему важно собирать требования перед тестированием страницы логина
Что проверяют
Умеете ли вы сформулировать ожидаемый результат до того, как напишете первый assert. Без требований автотест фиксирует текущее поведение, то есть превращается в защиту существующего бага.
Как отвечать
Тест это сравнение факта с ожиданием, а ожидание берётся из требований. У страницы входа большая часть поведения из вида формы не выводится. Выяснять стоит:
- правила проверки полей: что считается корректным адресом, требования к паролю, обрезаются ли пробелы, зависит ли логин от регистра;
- политику ошибок: одинаковое ли сообщение для несуществующего пользователя и для неверного пароля. Часто это осознанное требование, чтобы не подсказывать, какие учётки есть;
- защиту от перебора: сколько попыток, на какой срок блокировка, есть ли капча;
- жизнь сессии: срок действия токена, что делает галка сохранения входа, что происходит во второй вкладке и после смены пароля;
- второй фактор, вход через внешнего провайдера, возврат на страницу, с которой пришли.
Дальше требования превращаются в таблицу «ввод и ожидание», а таблица в @pytest.mark.parametrize. Учётки готовят через API в фикстуре, браузером проверяют только сам сценарий входа: так набор остаётся быстрым и падает по делу.
Где спотыкаются
Пишут тесты по внешнему виду формы, а потом заводят дефекты на осознанные решения: обобщённое сообщение об ошибке, отсутствие подсветки конкретного поля. Без записанного требования это спор о вкусах, а не дефект, и время уходит в обсуждение.
Не спрашивают про лимит попыток и капчу и упираются в них на первом же прогоне: учётка блокируется, весь набор краснеет, причина ищется в коде тестов. Нужен контур с отключённой защитой или отдельные пользователи под каждый сценарий.
Проверяют только успешный вход. Основная часть требований это отказы: неверный пароль, отключённый пользователь, просроченный пароль, недоступный сервис аутентификации. Ожидаемое поведение для них согласуют заранее, иначе тест напишут под то, что вернулось в первый раз.