Как локализовать ошибку при регистрации на портале при появлении ошибки валидации

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

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

Как отвечать

Двигайтесь от воспроизведения к слою, где ломается валидация:

• зафиксировать данные: точное значение каждого поля, включая невидимое: пробелы по краям, кириллическую «с» в латинском адресе, эмодзи, вставку из буфера, автозаполнение браузера;
• клиент или сервер: откройте вкладку Network в DevTools. Если запрос не ушёл, сработала клиентская проверка: атрибуты required, pattern, type="email" или JS-валидатор. Если ушёл, смотрите код ответа (обычно 400 или 422) и тело с описанием поля;
• сравнить отправленное с введённым: фронтенд мог обрезать строку, поменять регистр, отправить поле под другим именем или в другой кодировке;
• обойти интерфейс: повторите запрос через Postman или curl, его удобно взять из DevTools через Copy as cURL. Сервер принимает, значит проблема на фронте, отклоняет, значит в бэкенде или в требованиях;
• сузить условие: меняйте по одному параметру, опираясь на классы эквивалентности и граничные значения: длина, спецсимволы, домен, возраст;
• логи: найдите запрос в логах сервера по времени или request id и посмотрите, какое правило сработало.

Затем сверьтесь с требованиями: правило может быть намеренным, а баг окажется в тексте сообщения. В репорт кладите шаги, точные данные, окружение, ожидаемый и фактический результат, запрос и ответ или HAR-файл.

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

Меняют несколько полей за раз. Ошибка пропала, но непонятно, какое изменение её убрало.

Не проверяют, что ошибка «валидации» на самом деле другая: например, почта уже занята, а сервер отвечает общим сообщением.

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