Нормализация пользовательского ввода. Зачем это нужно, если есть валидация

В прошлом посте разбирали валидацию - проверку, что данные подходят для использования. Но валидные данные не равно стандартизированные данные. Вот где начинается нормализация.


👀 Зачем нужна нормализация когда есть валидация

Валидация ответит «данные валидны для использования», но не исправит их:
«89161234567» и «+7(916)123-45-67» оба телефона верные, и в базе создадут два разных аккаунта, но поиск по одному не найдёт второй

«Москва, ул. Ленина» и «г. Москва, улица Ленина» - один адрес, два разных написания

Нормализация решает эту проблему - приводит данные к единому виду до сохранения.


📌 Валидация обрамляет нормализацию с двух сторон
Данные которые передаём на нормализацию тоже должны соответствовать минимальным требованиям - быть валидны для обработки. Поэтому валидация происходит дважды:

Ввод пользователя
|
Базовая валидация: проверка, что данные пригодны для нормализации?
(не пусто, минимальная длина, тип данных)
|
Нормализация: привести к стандарту
|
Финальная валидация: данные пригодны для сохранения?
(формат, бизнес-правила, уникальность)
|
Сохранение в базу

🎯 До нормализации проверяем, что данные вообще пригодны для обработки

🎯 После нормализации проверяем, что результат соответствует требованиям системы


Можно ли сразу писать правила валидации под нормализованный формат?
Да, но только для простых полей. Например для email: вместо «просто проверь что есть @ и точка» пишешь правило «только lowercase, без пробелов». Тогда нормализация делает своё дело до валидации, и валидация проверяет уже «чистые» данные.

Но не всегда это возможно:
Телефон - пользователь может ввести «89161234567» или «+79161234567» или «8(916)123-45-67». Запретить все форматы кроме одного - плохой UX. Правильно: принять любой -> нормализовать -> валидировать итог

Адрес - невозможно написать правило которое покрывает все адреса страны. Поэтому и существуют внешние справочники вроде Дадата - они нормализуют данные.

ФИО - «Иван Иванов Иванович» и «Иванов Иван Иванович» оба правильные и нормализация нужна

🔴 Главный принцип: не наказывай пользователя за формат, если его можно исправить автоматически.


📌 Где происходит нормализация

На фронте (до отправки на сервер):
• Дает быструю обратную связь пользователю
• Снижает нагрузку на бэкенд
• Форматирование отображения в реальном времени

На бэкенде:
• Финальная нормализация перед записью в базу, так как бэкенд не доверяет данным с фронта


📌 Примеры нормализации на фронте

Простая без внешних сервисов:
• Обрезка пробелов: « Иван » -> «Иван»
• Регистр email: «IVAN@MAIL.RU» -> «ivan@mail.ru»
• Форматирование телефона: «89161234567» -> «+7 (916) 123-45-67»
• Удаление лишних символов из номера карты

Сложная (через внешние сервисы-справочники):
• Адреса - через Дадата / ФИАС
• ФИО - разбивка на имя, фамилию, отчество
• ИНН, ОГРН, реквизиты банков


🧩 Внешние сервисы - это справочники
Дадата, ФИАС, ГАР - это по сути справочники с API:
• Содержат эталонные данные (все адреса РФ, все ИНН, все банки)
• Фронт отправляет введённый текст -> справочник возвращает нормализованный объект
• Выбор из подсказок сам по себе является валидацией - пользователь не может ввести несуществующий адрес


🌿 Ловушки для QA
1) Бэкенд принимает только структурированный объект с ФИАС-кодом, если пользователь ввёл адрес вручную без выбора подсказки и нажал Submit, бэкенд вернёт ошибку
2) Нормализация на фронте и на бэкенде может различаться
3) Данные могут быть валидны, но не нормализованы - такие баги проявляются не сразу, а при поиске, сравнении и дедупликации
4) ФИАС-коды домов периодически меняются - ранее сохранённый адрес может стать невалидным
5) Debounce 300-400ms на запросы к Дадата - проверь поведение при быстром вводе и медленной сети
6) Если сервис-справочник недоступен, то поле ввода может заблокироваться или криво работать

Поставь 🔥, если полезно
#интеграции

А у вас как дела обстоят с оценкой задач на проекте?😅
А требования?

Делитесь рилс https://www.instagram.com/reel/DavefLgsFGv/?igsh=dTZ1b2xheGtydTRq и присоединяйтесь к аккаунту 💙

Краткий гид по методам оценки трудозатрат в QA. Сохраняйте, чтобы не гадать! 👇

1️⃣ PERT (3 точки): Формула E=(a+4m+b)/6. Сглаживает риски.
2️⃣ Декомпозиция: Дробление на этапы (кейсы, прогон, ретест) и суммирование.
3️⃣ Метод Дельфи: Анонимный опрос экспертов до консенсуса, без давления авторитетов.
4️⃣ Директивный: Срок диктует бизнес, команда подгоняет объем проверок.
5️⃣ Функц. точки: Оценка сложности сценариев с переводом баллов в часы.
6️⃣ % от разработки: Фиксированный процент от времени кодинга (напр., 30%).
7️⃣ COCOMO: Алгоритмический расчет по размеру проекта и коэффициентам.
8️⃣ По аналогии: Опора на опыт: «проверяли похожее за 2 дня».
9️⃣ Use Case Points: Прогноз по числу акторов и сложности сценариев.
🔟 Нормативный: Жесткие стандарты компании (напр., 30% бюджета на QA).
1️⃣1️⃣ ПВН: Оценка «на глаз» при полном отсутствии данных.

📚 Источник: https://www.software-testing.by/blog/sqadays15planirovanieiocenkatrudozatratnatestirovanie/

#qa #тестированиепо #тестировщик