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