Какие проверки нужны для формы добавления адреса

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

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

Как отвечать

Уточните состав формы и откуда берутся данные: ручной ввод, подсказки адресного сервиса или точка на карте. Потом сгруппируйте проверки:

• обязательность: без города, улицы и дома форма не сохраняется, квартира и подъезд необязательны, потому что есть частные дома;
• формат: номер дома бывает 12А, 12/3, 12к1, 12 стр. 2, так что запрет «спецсимволов» ломает реальные адреса. Почтовый индекс в России это 6 цифр, при международной доставке формат другой;
• подсказки: выбор из списка заполняет все поля, ручная правка после выбора не оставляет несогласованных данных, форма работает, когда сервис подсказок недоступен;
• карта: перемещение метки меняет адрес и наоборот, адрес вне зоны доставки даёт понятное сообщение;
• жизненный цикл: добавление, редактирование, удаление, адрес по умолчанию, лимит на число адресов, удаление адреса, привязанного к активному заказу;
• надёжность: двойное нажатие «Сохранить» не создаёт две записи, потеря сети при отправке, возврат назад без сохранения;
• безопасность: комментарий курьеру выводится экранированным, а запрос с чужим address_id через API не даёт изменить чужой адрес.

Отдельно упомяните длинные названия улиц в интерфейсе и в чеке, а также то, что смена адреса может поменять стоимость и сроки доставки.

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

Ограничиваются проверками отдельных полей. Самые дорогие баги здесь на стыке: адрес сохранился, а зона доставки и цена пересчитались неверно.

Запрещают дробь, дефис и буквы в номере дома, потому что так «правильнее». Реальные адреса такая валидация отсеет.

Забывают про права доступа. Подмена идентификатора адреса в запросе это классическая уязвимость IDOR, и тестировщик вполне может её найти.