Currículo análise é o processo de transformar um arquivo em campos estruturados: cargo, empregador, datas, formação e habilidades. Não existe um formato único que todos os geradores de currículo sigam, e é justamente essa ausência de padrão que define o trabalho de quem testa. Aqui mostramos por que a leitura de currículos é um problema de variação de layout e como organizar conjuntos de amostras que continuem úteis depois que o modelo de arquivo original mudar.
Por que não existe um padrão único de currículo?
Um currículo é um documento de apresentação, e quem o produz escolhe o que destacar. Ferramentas de edição, modelos prontos e preferências regionais produzem arranjos muito diferentes para o mesmo conteúdo: em uma coluna ou em duas, com seções na ordem que o autor preferir, com a experiência em tópicos ou em parágrafos corridos.
Nada disso é erro. O documento é feito para ser lido por pessoas, e pessoas se orientam por posição, negrito e agrupamento visual. Um leitor automático, por outro lado, recebe uma sequência de caracteres ou uma estrutura de texto e precisa reconstruir a organização.
Daí a consequência central para os testes: o alvo não é acertar um formato, é recuperar os campos certos apesar da variação de arranjo.
Que variações de layout precisam de cobertura?
A tabela abaixo reúne os arranjos que mais aparecem na prática e o que cada um costuma desafiar.
| Variação | Como se apresenta | O que costuma falhar |
|---|---|---|
| Duas colunas | Contato de um lado, experiência do outro | Ordem de leitura embaralhada |
| Seções fora de ordem | Formação antes da experiência | Extração que depende de posição |
| Experiência em parágrafo | Um bloco de texto corrido | Separação entre cargo, empresa e período |
| Habilidades em etiquetas | Palavras soltas em linha | Vínculo entre habilidade e nível |
| Cabeçalho com dados de contato | Telefone, correio e endereço no topo | Confusão entre campos de contato e de perfil |
| Tabela de formação | Linhas com instituição e ano | Perda da relação entre colunas |
Cobrir os seis arranjos acima com pelo menos um documento cada dá muito mais retorno do que cobrir seis variações do mesmo arranjo de uma coluna só.
Organizar por cenário ou por número?
Nomear as amostras por número é a decisão mais comum e a que envelhece pior. Um arquivo chamado de amostra três não diz nada sobre o que ele testa, e depois de alguns meses ninguém sabe se pode apagá-lo.
Organizar por cenário resolve isso. O nome descreve o arranjo, e o conjunto passa a ser uma lista de situações que a aplicação precisa reconhecer. Quando um defeito aparece, o nome do cenário indica de imediato qual documento o reproduz.
Uma boa convenção tem três partes: o tipo de arranjo, a característica que ele destaca e, quando fizer diferença, o idioma do documento. Assim, um cenário de coluna dupla com datas só de ano é diferente de um cenário de coluna dupla com período completo, e os dois convivem sem ambiguidade.
Por que a geração aleatória atrapalha a reprodução?
Dado aleatório é ótimo para explorar: variar a entrada a cada execução encontra defeitos que uma amostra fixa nunca mostraria. O problema aparece quando o mesmo dado é usado para verificar um resultado esperado.
Se a entrada muda a cada execução e o defeito se manifesta em uma entrada em cem, a falha é intermitente e não reproduzível. O time gasta horas discutindo se o erro existe, e o relatório automático perde credibilidade. A prática que resolve isso é separar explicitamente dois papéis: exploração com dado variável, verificação com dado congelado.
Amostras congeladas também servem de contrato. Quando alguém altera o extrator e o conjunto fixo passa a falhar, a mudança de comportamento fica visível e datada.
Como um conjunto de amostras envelhece?
Nenhum conjunto de documentos de teste permanece correto para sempre. Três movimentos corroem esses conjuntos com o tempo.
O primeiro é a mudança dos modelos de arquivo: uma ferramenta de edição atualiza o desenho padrão, e as amostras que imitavam o desenho antigo passam a representar um passado que quase ninguém usa. O segundo é a língua: um conjunto que só cobre um idioma deixa de refletir a base de usuários, e a adição de um idioma novo costuma revelar problemas de separação entre campos. O terceiro é o crescimento do próprio extrator: campos novos entram no produto e nenhuma amostra os exercita.
A resposta usual é uma revisão periódica com data marcada, em que cada cenário é classificado como ainda relevante, redundante ou obsoleto. Sem essa rotina, o conjunto cresce em número de arquivos e encolhe em cobertura efetiva.
Para quem desenvolve: casos e campos esperados
O desenho mais útil para testes de leitura de currículo é a tabela de expectativas por cenário. Para cada documento de entrada, registre quais campos devem ser extraídos, quais são opcionais e o que se espera quando o campo aparece de forma ambígua.
Três cuidados rendem bastante:
- Distinga ausência de falha. Um campo que não existe no documento não é um erro de extração; o caso precisa dizer isso de forma explícita.
- Teste a contagem de itens. Um documento com três experiências deve produzir três registros; contagens erradas são o defeito mais comum e o mais silencioso.
- Verifique o emparelhamento. Em listas, o risco maior não é perder um item, é juntar o período de um item com o cargo de outro.
Vale ainda guardar, para cada cenário, uma versão do resultado esperado. Assim a comparação é direta e a diferença entre o que mudou no extrator e o que mudou na expectativa fica evidente.
Onde entrar em contato com dados coerentes
Se o seu problema é gerar as fichas que alimentam o extrator, e não os documentos de entrada, o gerador de currículo e dados de emprego monta perfis completos com cargo, experiências em ordem, formação, habilidades e certificações. Usar fichas coerentes como destino esperado facilita separar erro de extração de erro de dado.
Vale combinar este texto com testes de formulário de contratação, que cobre o caminho inverso, do formulário para o banco, e com dados de currículo para teste, que apresenta a ficha inteira.
Próximos passos
Escolha cinco arranjos de layout que a sua base real apresenta e monte um documento para cada um, nomeando-os pelo cenário que representam. Depois, separe no seu pipeline os casos de verificação, que usam amostras congeladas, dos casos de exploração, que usam geração variável — e use o gerador de currículo para produzir os dados de destino desses casos.
Lembrete: os documentos e campos esperados mencionados aqui são amostras construídas para exercitar software. Elas não contêm currículos reais, não descrevem trajetórias de pessoas e não devem ser usadas para treinar decisões sobre candidaturas.