Vale a pena capturar cada passo de um teste de QA?

Um registro de QA tem dois leitores: o revisor que aprova o teste hoje e a pessoa que investiga uma regressão meses depois. Ambos precisam ver o que foi testado, com quais dados e qual foi o resultado. Nenhum dos dois precisa de uma captura de tela de cada clique.

Este post explica como estruturar um registro de teste manual e onde as capturas de tela acrescentam evidência, com o fluxo do Temposhot em um Mac.

Os exemplos usam um único caso de teste: TC-142, uma redefinição de senha em um site de staging. O teste tem 4 passos, e um registro somente com checkpoints dele tem 5 páginas. Gravar cada clique do mesmo teste gerou 11 páginas.

Defina um objetivo de teste

Cada caso de teste deve verificar um único comportamento. "O usuário consegue redefinir a senha com um link de e-mail válido" é um objetivo. "As configurações da conta funcionam" é um plano de teste, não um caso de teste.

Escreva o objetivo como uma frase que possa ser verdadeira ou falsa. A captura final mostra qual dos dois.

Separe objetivos que escondem dois testes

Um objetivo com "e" frequentemente esconde dois testes. "O usuário consegue redefinir a senha e alterar o e-mail" falha como um todo quando só uma parte quebra, e o registro não mostra qual. Divida em dois casos, cada um com seu próprio ID e registro.

Um objetivo restrito também mantém o registro curto. O TC-142 termina quando o usuário entra com a nova senha. Verificar que a senha antiga não funciona mais é outro caso, o TC-143, com estado inicial próprio.

Escreva o objetivo do ponto de vista do usuário

Um objetivo escrito do lado do usuário nomeia um resultado que o usuário vê. "O usuário consegue redefinir a senha com um link de e-mail válido" termina em uma tela: o painel após o login. Um objetivo como "O endpoint de redefinição retorna 200" termina em um log, e um registro de capturas de tela é o formato errado para ele.

Quando um caso combina os dois, mantenha o resultado visível como objetivo e anexe as linhas de log como texto. As capturas comprovam o resultado para o usuário, e o texto comprova o comportamento do sistema por trás dele.

Registre pré-requisitos e dados de teste

Liste o que precisa existir antes do primeiro passo, para que qualquer pessoa consiga repetir o teste:

Item	Exemplo
ID do caso de teste	TC-142
Build ou versão	O número da build testada
Ambiente	URL de staging, versão do macOS, navegador e versão
Conta	Função e nome da conta de teste, nunca um cliente real
Dados de teste	O pedido, arquivo ou registro usado pelo teste
Pré-condições	Flag de funcionalidade ativa, carrinho vazio, usuário desconectado

Use dados sintéticos. Registros de teste são compartilhados amplamente e guardados por muito tempo.

Comprove as pré-condições na primeira página

Uma pré-condição apenas escrita não pode ser verificada depois. A primeira página do registro deve mostrar o estado inicial na tela, como a página de login desconectada com a URL de staging visível. Assim, o revisor confirma o ambiente sem precisar perguntar.

Caixa de entrada vazia importa para o TC-142. Se um e-mail antigo de redefinição estiver na caixa de entrada, o testador pode abrir o link errado, e o registro mostra aprovação para um link que não estava em teste.

Use dados de teste claramente falsos

Dados sintéticos devem parecer falsos à primeira vista. Nomes como "QA Reset 01" e endereços em um domínio de teste deixam claro para qualquer leitor posterior que nenhuma pessoa real está envolvida. Nomes falsos realistas, como nome e sobrenome plausíveis, levantam dúvidas sobre se o registro contém dados de clientes.

Dados de teste óbvios também reduzem o trabalho de ocultação. Um registro sem dados pessoais não precisa de Blur, então o plano gratuito é suficiente, e as páginas mostram a tela inteira sem áreas cobertas.

Escreva os passos com checkpoints esperados

Cada passo recebe uma ação e, quando algo observável deve acontecer, um resultado esperado.

1. Abra a página de login. Esperado: link "Forgot password" visível.
2. Selecione Forgot password e digite o e-mail de teste. Esperado: mensagem de confirmação.
3. Abra o link de redefinição na caixa de entrada de teste. Esperado: formulário de nova senha.
4. Digite uma nova senha válida e envie. Esperado: login concluído, painel exibido.

Passos sem resultado esperado são preparação. Passos com resultado esperado são checkpoints, e checkpoints são onde as capturas devem ficar.

Torne cada resultado esperado observável

"Funciona corretamente" não é um resultado esperado, porque nenhuma captura de tela consegue mostrá-lo. Um resultado esperado nomeia algo visível: o texto de uma mensagem, um campo, um valor, o título de uma página. "Mensagem de confirmação: Check your email for a reset link" pode ser comparada com a tela palavra por palavra.

Se um resultado esperado não puder ser visto na tela, como o horário de entrega de um e-mail, registre-o como texto na descrição da página. A captura mostra a tela, e a descrição registra o valor.

Mantenha os números dos passos estáveis

Os números dos passos no caso de teste e os títulos das páginas no registro devem coincidir. Se o caso for editado depois e um passo for inserido, dê ao novo passo um sufixo como 2a, em vez de renumerar. Registros antigos continuam apontando para os passos certos, e uma busca de regressão por "passo 4" encontra a mesma ação em todas as builds.

Títulos são editados no Page Inspector, em Page title. Reescreva cada título provisório para que comece com o ID do caso e do passo, e depois adicione as linhas de resultado esperado e real em Description.

Separe passos de preparação dos checkpoints

O TC-142 tem preparação que o registro não mostra: abrir a caixa de entrada de teste, copiar o endereço de e-mail, aguardar o e-mail. Deixar essas ações de fora mantém o registro em 5 páginas. Se uma ação de preparação falhar, ela vira um resultado Blocked com página própria, e não uma lacuna silenciosa.

Um teste prático: se um passo não tiver linha "Esperado" no caso, ele não gera página. Se tiver, gera exatamente uma página.

Deve-se capturar cada passo de um teste de QA?

Não. Capture estes momentos:

• Estado inicial: comprova que as pré-condições foram atendidas.
• Cada checkpoint: mostra o resultado esperado ou inesperado.
• Resultado final: mostra se o objetivo foi atingido.
• Qualquer falha: a tela no momento em que divergiu, mais o passo anterior.

Capturas de cliques simples de navegação acrescentam páginas sem acrescentar evidência. Elas tornam o registro mais lento de revisar.

Com o Temposhot, você pode capturar apenas os checkpoints. Abra Action Capture (Command+3), selecione Configure e defina Mouse click capture para capturar apenas cliques com uma tecla modificadora ou para nunca capturar cliques. Depois, pressione Shift+Command+2 (o atalho de captura manual) em cada checkpoint. Selecione Start Action Capture, escolha Specific Window, execute o teste e selecione Finish capture. O Document abre com uma página por checkpoint.

Se você quiser todos os passos de um teste que falhou, volte Mouse click capture para capturar cada clique. Cada clique aceito salva a janela logo antes do clique. O guia do Action Capture lista os modos de captura.

Compare os dois modos de gravação

Os dois modos respondem a perguntas diferentes. Um registro somente com checkpoints responde "cada checkpoint mostrou o resultado esperado?". Um registro de cada clique responde "exatamente o que o testador fez?", o que importa mais quando um teste falha.

O plano gratuito tem um limite de 5 passos por execução do Action Capture. Um registro somente com checkpoints do TC-142 cabe exatamente em uma execução gratuita: o estado inicial mais 4 checkpoints. Uma execução de cada clique pausa após 5 passos e mantém esses 5; o Temposhot Pro remove o limite.

Configure uma execução somente com checkpoints

Configure Action Capture salva suas configurações no Mac, então a configuração de checkpoints permanece para a próxima sessão de teste. Volte a configuração antes de gravar um tutorial ou um relatório de bug.

Mark clicked area também se aplica aos passos adicionados com o atalho manual. Em um registro de checkpoints, a marcação aponta para onde o ponteiro estava parado, o que pode induzir o revisor ao erro, então ela permanece desativada.

Execute o TC-142 com o atalho

1. Capture o estado inicial

   Após a contagem regressiva, pressione Shift+Command+2 na página de login desconectada. Esta é a página 1.

2. Capture cada checkpoint

   Execute cada passo. Quando o resultado esperado deve estar na tela, pressione o atalho novamente. As páginas 2 a 5 são os 4 checkpoints.

3. Finalize

   Pressione Command+. ou selecione Finish capture. O Document abre com 5 páginas.

Checkpoints que desaparecem rápido

Alguns resultados esperados ficam visíveis por apenas alguns segundos, como uma mensagem toast após enviar um formulário. Pressione o atalho assim que a mensagem aparecer; o passo salva a tela naquele momento. Se a mensagem sumir antes do toque na tecla, repita o passo e mantenha a mão sobre as teclas.

Se um resultado aparecer rápido demais para ser capturado, escreva-o na descrição e capture a tela seguinte. "Esperado: toast Password updated. Real: toast visto, fechado após cerca de 3 segundos, painel exibido." Assim o revisor sabe que o toast foi observado e por que ele não está na página.

Testes que atravessam janelas

O TC-142 vai do navegador para a caixa de entrada de teste e volta. Quando a caixa de entrada abre em outra janela do navegador, um alvo Specific Window continua capturando apenas a primeira janela. Escolha Full Screen para um teste que usa várias janelas e feche tudo que não pertence ao teste antes da execução.

Troque de modo quando um checkpoint falhar

Quando o passo 4 falha, um registro de checkpoints mostra o resultado, mas não a entrada exata. Execute o teste novamente no modo de cada clique para registrar o caminho até a falha. Anexe essa segunda execução ao relatório de bug e mantenha a primeira como resultado do teste.

Registre resultados reais sem reescrever o histórico

O registro deve mostrar o que aconteceu, não o que deveria ter acontecido. No editor de Document:

• Dê a cada página o ID do passo e a ação como título, como "TC-142 passo 4: Enviar nova senha".
• Na Page description, escreva os resultados esperado e real em linhas separadas.
• Em um checkpoint com falha, desenhe um Rectangle (R) ao redor do valor errado e adicione um rótulo Text (T) com "Fail".

Não recorte o contexto que o revisor precisa, como a URL ou o rótulo da build. Use Framing apenas para remover janelas não relacionadas. Oculte dados pessoais com Blur (B, Pro) e nunca edite um valor para fazer um resultado parecer correto.

Regras de anotação para evidências

As anotações no Temposhot são não destrutivas: a captura de tela sob um retângulo ou rótulo permanece inalterada. Isso preserva a evidência, mas quem lê o PDF exportado vê apenas a página renderizada. Regras sobre o que uma anotação pode e não pode fazer mantêm a exportação confiável.

Escreva a descrição em formato fixo

Um formato fixo de duas linhas torna as descrições fáceis de percorrer em 5 ou 50 páginas. A primeira linha é "Esperado:" com o resultado esperado. A segunda é "Real:" com o que a captura mostra.

Para a página 5 do TC-142, a descrição diz "Esperado: login concluído, painel exibido. Real: banner 'Reset link expired', formulário de login exibido." O revisor confere a linha Real com a captura de tela de uma só vez.

Use este registro de execução de QA

• ID do caso de teste, objetivo, build, ambiente, testador, data.
• Pré-condições e dados de teste.
• Passos com resultados esperados.
• Capturas do início, dos checkpoints, do fim e das falhas.
• Resultado real por checkpoint.
• Status: Pass, Fail ou Blocked.
• Relatório de bug vinculado a cada falha.

Exporte o Document com Export PDF para anexar à ferramenta de gestão de testes, ou exporte páginas PNG em More export formats para evidência inline. Nomeie os arquivos com o ID do caso e a build, como TC-142_build-2026-08-27.pdf. O guia de exportação lista os formatos. Para comparar duas capturas da mesma tela entre builds, a ferramenta Compare Images destaca as diferenças localmente.

Configurações de PDF para um registro de teste

As configurações padrão de Export PDF servem para a maioria dos registros: A4, Landscape, página de capa, números de passo e de página ativados, descrições antes da imagem. A capa começa com o título do documento e a quantidade de passos, então um título como "TC-142 build 2026-08-27 Fail" coloca o resultado na primeira página. Personalizar as configurações de PDF exige o Temposhot Pro.

Com o Pro, equipes que imprimem em papel dos EUA mudam Paper size para Letter. Definir Image quality como Small file mantém um registro de regressão de 50 páginas pequeno o suficiente para ferramentas com limite de tamanho de anexo.

Defina o status a partir da evidência

Cada status exige evidências diferentes. Um revisor que vê um status sem as páginas correspondentes deve devolver o registro.

Organize os registros por caso e build

Um registro é encontrado depois pelo ID do caso e pela build, raramente só pela data. Mantenha uma pasta por caso, com uma subpasta por build, para que uma busca de regressão compare o mesmo caso entre as builds.

Os arquivos de imagem do Document recebem o nome dos títulos das páginas. Títulos que começam com o ID do passo produzem nomes de arquivo que ordenam na sequência dos passos e coincidem entre as builds.

Compare um checkpoint entre builds

Quando o TC-142 é aprovado na build de 2026-09-03 depois de falhar em 2026-08-27, abra os dois arquivos PNG do passo 4 em Compare Images. A visualização com controle deslizante ou de diferença de pixels mostra se só o banner mudou ou se o layout também se deslocou. Mantenha os dois registros; o registro com falha documenta a regressão.

Revise as evidências e aprove

Um revisor deve confirmar três coisas sem executar o teste: as pré-condições foram atendidas, cada checkpoint mostra o resultado declarado e o status final coincide com as capturas. Se o revisor precisar adivinhar, o registro precisa de mais um checkpoint.

O Temposhot armazena os Documents localmente e não oferece fluxos de aprovação. Anexe os arquivos exportados à ferramenta de gestão de testes ou ao ticket onde as aprovações são registradas.

A revisão do revisor, em ordem

Um revisor consegue conferir um registro de 5 páginas em poucos minutos lendo-o em ordem fixa. Primeiro, compare o título da capa e a página 1 com as pré-condições: build, URL e estado desconectado. Segundo, leia cada página de checkpoint e compare a linha "Real" com a captura de tela.

Terceiro, verifique se o status na capa coincide com as páginas. Um registro marcado como Pass com um banner de erro vermelho na página 5 volta para o testador. Um registro marcado como Fail sem relatório de bug vinculado também volta.

Blocked não é Fail

Um teste fica Blocked quando não consegue chegar a um checkpoint por um motivo fora do comportamento testado. No TC-142, uma indisponibilidade do staging que impede o e-mail de redefinição de chegar bloqueia o passo 3. O registro mostra o estado inicial e a última tela alcançável, com o motivo na descrição.

Marcar um teste bloqueado como Fail piora a taxa de falhas e envia um bug para a equipe errada. Marcá-lo como Pass oculta a lacuna. Mantenha Blocked como status próprio e execute o caso novamente quando o bloqueio for resolvido.

Do checkpoint com falha ao reteste

Uma falha segue um caminho fixo. O registro original permanece como está em cada etapa.

Fluxo de teclado para uma sessão de teste

Um testador que executa 10 ou 20 casos em uma sessão se beneficia de permanecer no teclado. As teclas abaixo cobrem a gravação e a primeira etapa de edição.

Retenção de registros no Mac

Os Documents permanecem no Mac que os gravou, e as sessões brutas ficam em Capture History até o limite de retenção. O limite padrão é de 30 sessões, ajustável de 1 a 500 em Settings > History. Um ciclo de testes intenso pode passar de 30 sessões em poucos dias, então exporte cada registro para a ferramenta de gestão de testes quando o caso for concluído.

Perguntas frequentes

Capturas de tela bastam como evidência de teste?

Para testes manuais de interface, elas são parte central da evidência. Adicione logs, saída do console ou dados de rede como texto quando a falha não for visível na tela. Veja evidência por captura de tela.

Testes automatizados também devem gerar capturas de tela?

Suítes automatizadas normalmente capturam telas quando uma falha ocorre. Para comparar capturas de tela automaticamente entre builds, veja teste de regressão visual.

Como registrar uma falha encontrada durante o QA?

Escreva um relatório de bug separado vinculado ao caso de teste. Veja como documentar um bug com capturas de tela passo a passo.

Quantas páginas um registro de teste deve ter?

Uma para o estado inicial, uma para cada checkpoint e uma para qualquer falha. O TC-142 tem 4 checkpoints, então um registro aprovado tem 5 páginas.

Uma página de checkpoint pode mostrar o ponteiro?

Sim. Ative Show cursor in shortcut captures em Configure Action Capture. Deixe desativado quando a posição do ponteiro não tiver significado para o resultado.

Transforme seus cliques em um guia passo a passo claro

Action Capture registra checkpoints por atalho ou cada clique, dependendo da execução. Baixe o Temposhot e anexe seu próximo registro de teste como um PDF ordenado.