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