Ir para o conteúdo
SkillCort

7 min · 7 stepsTutorial de aplicação

Como pré-visualizar e testar a sua avaliação antes de entrar em produção

O erro mais caro numa avaliação é aquele que um candidato encontra. Uma chave de resposta errada, uma página que se arrasta ou um estímulo ilegível no telemóvel custam-lhe sinal que não consegue recuperar. Este tutorial é uma rotina de controlo de qualidade repetível que apanha esses problemas antes de o primeiro convite sair.

What you'll need

  • Um rascunho de avaliação montado no builder (secções, páginas, blocos)
  • Grelhas ou chaves de resposta associadas a todas as tarefas pontuadas
  • Um telemóvel ou uma janela de navegador estreita para a passagem em ecrã pequeno
  • 1–2 colegas disponíveis para uma curta execução piloto

Step 1: Abra a pré-visualização de candidato no cabeçalho do builder

Comece todas as passagens de controlo de qualidade em "Preview as candidate", no cabeçalho do builder. A pré-visualização apresenta a avaliação exatamente como um candidato a verá — as mesmas páginas, blocos, instruções e cronómetros —, pelo que tudo o que apanhar aqui é um problema real corrigido antes de lhe custar uma resposta.

Resista à tentação de passar os olhos pelo seu próprio conteúdo. Foi você que escreveu estas tarefas, por isso o seu cérebro vai preencher lacunas que um candidato não consegue preencher. Leia todas as instruções como se nunca tivesse visto a função e responda a todas as perguntas a sério, em vez de ir clicando. A ideia é viver a avaliação, não passear por ela.

Step 2: Percorra todas as páginas no computador, respondendo a sério

Vá página a página e complete mesmo cada tarefa: escreva as respostas de texto, preencha as entradas em tabela, carregue um ficheiro, grave o áudio ou o vídeo se a avaliação o pedir. Os tipos de item interativos falham de formas que uma leitura visual nunca revela — um carregamento que rejeita o formato de ficheiro óbvio, uma tarefa de código com um estado inicial confuso, um bloco de gravação que um candidato pode não ver.

Preste especial atenção às disposições de estímulo lado a lado. Confirme que o estímulo e a pergunta estão visíveis em conjunto, que os documentos longos rolam de forma independente e que nada obriga o candidato a memorizar o estímulo antes de responder. Um problema de disposição aqui altera silenciosamente o que a tarefa mede — da capacidade para que a desenhou para a memória de trabalho e a paciência.

  • Todas as instruções são inequívocas para alguém de fora da sua equipa
  • Carregamentos, gravações e blocos de código aceitam uma resposta realista
  • O estímulo e a pergunta leem-se em conjunto num só ecrã
  • Os campos obrigatórios e a navegação comportam-se como esperado em todas as páginas

Step 3: Repita o percurso num telemóvel

Faça a mesma pré-visualização num telemóvel ou numa janela de navegador estreita. Os candidatos nem sempre estão sentados a uma secretária, e as disposições que parecem bem num monitor largo podem esconder um estímulo, cortar uma tabela ou empurrar o botão de submissão para o fim de um deslocamento interminável num ecrã pequeno.

Se uma tarefa exigir mesmo um computador — um ambiente de código, uma revisão longa de documentos lado a lado —, diga-o explicitamente nas instruções da avaliação em vez de deixar que os candidatos o descubram a meio da tentativa. Uma frase a definir expectativas à partida é muito mais barata do que uma resposta frustrada e feita pela metade.

Step 4: Cronometre um ensaio realista face aos seus limites

Complete a avaliação a um ritmo de trabalho realista e compare o seu tempo decorrido com os limites totais e por página que definiu no builder. Depois acrescente margem: você já conhece o material, e um candidato a ler tudo pela primeira vez será significativamente mais lento do que você foi.

Verifique os limites por página individualmente, e não apenas o total. Uma página subestimada — normalmente a que tem a prova de trabalho mais rica — pode arruinar uma avaliação com tempos por outro lado bem calculados, porque a pressão do tempo numa única tarefa penaliza sobretudo os candidatos cuidadosos. Se uma página lhe pareceu apressada mesmo a si, alargue-a antes de mais alguém a ver.

Step 5: Verifique todas as grelhas e chaves de resposta face à sua tarefa

Abra cada tarefa pontuada e confirme que a sua configuração de pontuação corresponde à tarefa tal como está escrita — e não à tarefa como a esboçou há três edições. Nos itens de pontuação automática, verifique se a chave de resposta marca as opções corretas e se os valores em pontos são os que pretende. Lembre-se de que uma tarefa sem chave de resposta é pontuada automaticamente como null e fica à espera de revisão manual; não pontua silenciosamente a zero, mas fica por pontuar até alguém tratar dela.

Nas tarefas pontuadas por grelha, releia cada critério face ao enunciado da tarefa e confirme que uma boa resposta a este enunciado poderia mesmo demonstrar todos os critérios. Note que as grelhas congelam num instantâneo ao serem associadas, pelo que este é o momento de corrigir a redação — as edições posteriores na sua biblioteca não chegarão à avaliação publicada.

Step 6: Cumpra a lista de verificação de publicação

A lista de verificação de publicação é o último portão da plataforma: bloqueia Publish até a configuração obrigatória estar completa, assinalando coisas como configuração de pontuação em falta ou secções incompletas. Trate todos os itens que ela levantar, em vez de procurar o caminho mais rápido para um botão verde.

Trate a lista de verificação como um mínimo, não como um máximo. Verifica a completude estrutural; não consegue julgar se as suas instruções são claras ou se os seus tempos são humanos. Foi para isso que serviram os passos anteriores. Quando a lista estiver cumprida e as suas passagens manuais concluídas, está pronto para o piloto.

Step 7: Faça um piloto com uma ou duas pessoas internas

Antes de qualquer candidato ver a avaliação, peça a um ou dois colegas que a façam de ponta a ponta em condições reais — a ligação real de aplicação, os limites de tempo reais e as definições de segurança que tenciona usar, para que a experiência de consentimento e de verificação prévia também seja testada. Escolha pessoas que não ajudaram a construí-la; olhos frescos encontram o que os seus não conseguem.

Faça o balanço imediatamente, enquanto a experiência está fresca. Depois pontue as respostas deles segundo as suas grelhas, como verificação final de que a linguagem da grelha funciona em resultados reais e não apenas na teoria. Corrija o que o piloto revelar, volte a fazer a pré-visualização de tudo o que alterou e só depois envie os convites.

  • Onde é que as instruções pareceram ambíguas ou surpreendentes?
  • Que página pareceu ter mais pressão de tempo?
  • A verificação prévia e os avisos de segurança pareceram proporcionais ao risco?
  • As respostas do piloto puderam ser pontuadas com clareza segundo a grelha?

Pro tips

  • Faça controlo de qualidade depois de cada alteração relevante, e não apenas uma vez — uma alteração de uma linha numa tarefa pode invalidar uma chave de resposta.
  • Mantenha uma lista de verificação de qualidade partilhada por avaliação, para que uma segunda pessoa possa confirmar a passagem em vez de confiar que ela aconteceu.
  • Pré-visualize com as mesmas definições de segurança com que vai aplicar a avaliação, para viver você mesmo o ecrã de consentimento e de verificação prévia.
  • Calcule os tempos para quem lê pela primeira vez, não para o autor — você será sempre a pessoa mais rápida a fazer esta avaliação.
  • Se o piloto revelar um problema de redação na grelha, corrija-o antes de publicar; as grelhas associadas são instantâneos congelados.

Perguntas frequentes

A pré-visualização de candidato conta para alguma coisa ou cria registos?
Não. "Preview as candidate" é uma ferramenta do builder para si, não uma aplicação. Apresenta a avaliação exatamente como os candidatos a vão viver, para que possa testar à vontade sem afetar resultados nem convites.
O que acontece se eu publicar uma tarefa sem chave de resposta?
A sua pontuação automática é null, o que significa que precisa de revisão manual — não é pontuada como zero. Isso é seguro, mas se esperava que a tarefa fosse pontuada automaticamente, as respostas por pontuar vão acumular-se na avaliação. É a passagem de controlo de qualidade sobre as chaves de resposta que apanha isto antes do lançamento.
Posso corrigir uma grelha depois de a avaliação estar em produção?
As edições à grelha no seu banco não alteram uma avaliação em curso — a grelha associada é um instantâneo congelado, o que protege a consistência da pontuação para os candidatos que já estão a meio. É exatamente por isso que a verificação das grelhas pertence ao controlo de qualidade pré-lançamento.
De quantos testadores piloto preciso na realidade?
Um ou dois chegam, desde que sejam mesmo olhos frescos e a façam em condições reais. Não está a medir a capacidade deles; está a testar se as instruções, os tempos, a mecânica dos itens e a linguagem da grelha sobrevivem ao contacto com alguém que não construiu a avaliação.
A lista de verificação de publicação está verde — já terminei?
A lista confirma que a configuração obrigatória está estruturalmente completa e bloqueia Publish até o estar. Não consegue julgar a clareza, os tempos ou a qualidade da grelha — isso precisa dos percursos manuais e da execução piloto descritos neste tutorial.

For hiring teams

Lance avaliações que consegue defender

Veja como a pré-visualização de candidato, a lista de verificação de publicação e os controlos de aplicação da SkillCort transformam o controlo de qualidade pré-lançamento numa rotina em vez de uma correria. Marque uma demonstração e percorra-a em direto.