Как описать проверку длины поля ИНН для разработчика
Что проверяют
Умеете ли вы превратить «проверьте длину ИНН» в требование, по которому разработчик и тестировщик сделают одно и то же без уточнений. Следом обычно спрашивают про контрольную сумму и про то, где должна жить проверка: на форме, на сервере или в обоих местах.
Как отвечать
Начните с предметной области: ИНН юрлица состоит из 10 цифр, ИНН физлица и ИП из 12. Дальше опишите поле так, чтобы не осталось вариантов толкования:
- тип: строка из цифр, а не число. ИНН может начинаться с нуля (коды регионов с 01 по 09), и числовая колонка этот ноль потеряет;
- длина по контексту: для контрагента «ЮЛ» ровно 10, для «ФЛ» и «ИП» ровно 12. Если тип заранее не известен, допустимо 10 или 12, но не диапазон «от 10 до 12»;
- нормализация: что делать с пробелами по краям и внутри при вставке из буфера, обрезать или отклонять;
- момент проверки: на потере фокуса или при отправке, плюс обязательное дублирование на сервере с кодом ошибки и именем поля в ответе API;
- текст ошибки: точная формулировка и место вывода, например «ИНН организации состоит из 10 цифр»;
- контрольные разряды: у 10-значного ИНН последняя цифра контрольная, у 12-значного две последние. Они считаются по весовым коэффициентам и остатку от деления на 11, алгоритм лучше приложить ссылкой, чем пересказывать.
Закройте требование критериями приёмки с граничными значениями: 9, 10, 11, 12 и 13 цифр, пустое поле, буквы, пробелы, ИНН с неверной контрольной цифрой. Такой список тестировщик возьмёт как есть.
Где спотыкаются
Пишут «длина от 10 до 12 символов». Разработчик честно пропустит 11 цифр и формально будет прав.
Описывают только длину и только на клиенте. Запрос в API в обход формы положит в базу что угодно.
Смешивают формат и существование. Контрольная сумма ловит опечатки, но не доказывает, что такой ИНН выдан. Проверка по данным ФНС это отдельное требование со своим временем ответа и поведением при недоступности сервиса.