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