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