Conceito: caso de teste, checklist e evidência no Jira
Ao gerenciar testes no Jira, o objetivo não é apenas “marcar como testado”, e sim deixar um registro verificável do que foi validado, em qual contexto e com qual resultado. Para isso, você pode representar testes de diferentes formas, conforme o setup do time:
- Issue de Caso de Teste: uma issue dedicada (ex.: “Test Case”) descreve o cenário, dados e passos. Boa para reutilização e rastreabilidade.
- Subtarefas de teste: subtarefas dentro de uma história/bug, cada uma cobrindo um cenário. Boa para times que preferem manter tudo “colado” ao item de entrega.
- Checklist: lista de verificações dentro da issue (via campo nativo, app ou padrão em descrição). Boa para validações rápidas e regressões curtas.
Evidência é o conjunto de informações que permite auditar a execução: data/hora, build/versão, ambiente, resultado, anexos (prints, vídeos, logs) e observações (incluindo desvios e links). O padrão de escrita e registro é o que garante consistência e comparabilidade entre execuções.
Escolhendo o formato (issue, subtarefa ou checklist) conforme o uso
Quando usar issue de Caso de Teste
- Você precisa reutilizar o mesmo teste em várias releases.
- Há necessidade de rastrear cobertura por requisito/critério de aceite.
- Os testes têm passos detalhados e evidências frequentes.
Quando usar subtarefas de teste
- O time quer que a execução esteja no mesmo card da entrega.
- Os cenários variam muito por história e não serão reaproveitados.
- Você quer distribuir execução entre pessoas mantendo o item principal como “pai”.
Quando usar checklist
- Validações são curtas e repetitivas (smoke, sanity, regressão rápida).
- Você precisa de visibilidade rápida do “o que falta testar”.
- A evidência pode ser centralizada em um comentário/execução única com anexos.
Decompondo critérios de aceite em cenários testáveis
Critérios de aceite (CA) costumam vir como frases de negócio. Para transformá-los em testes, decomponha em cenários cobrindo:
- Happy path: fluxo esperado sem erros.
- Negativos: entradas inválidas, permissões insuficientes, estados proibidos.
- Bordas (edge cases): limites de tamanho, datas extremas, arredondamentos, concorrência, timeouts.
Modelo prático de decomposição
Para cada CA, responda:
- Pré-condições: o que precisa existir antes (usuário, permissões, dados, feature flag, integrações).
- Dados de teste: quais valores serão usados (válidos, inválidos, limites).
- Ação: o que o usuário/sistema faz.
- Resultado esperado: o que deve acontecer (UI, API, banco, eventos).
- Observabilidade: onde coletar evidência (print, log, resposta HTTP, query, evento).
Exemplo: transformando um critério de aceite em cenários
CA: “Como usuário, quero redefinir minha senha para recuperar acesso.”
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
- Cenário 1 (happy path): solicitar redefinição com e-mail cadastrado e definir nova senha válida.
- Cenário 2 (negativo): solicitar redefinição com e-mail não cadastrado (mensagem genérica, sem vazar informação).
- Cenário 3 (negativo): token expirado/inválido ao tentar redefinir.
- Cenário 4 (borda): senha no limite mínimo/máximo permitido e validações de complexidade.
- Cenário 5 (borda): múltiplas solicitações em sequência (último token invalida anteriores, se aplicável).
Passo a passo: criando um Caso de Teste como issue no Jira
Use este fluxo quando seu time mantém casos de teste como itens próprios.
1) Criar a issue de teste
- Crie uma issue do tipo usado pelo time (ex.:
Test CaseouTeste). - No Resumo, escreva no formato:
[Módulo] - [Ação] - [Resultado]. Ex.:[Login] Redefinir senha com token válido. - Preencha campos que seu time usa para organização (ex.: componente, label
regressao, prioridade de teste, etc.).
2) Registrar pré-condições e dados de teste
Evite deixar dados “na cabeça” do testador. Registre explicitamente:
- Pré-condições: usuário existente, e-mail confirmado, feature flag ativa, etc.
- Dados de teste: e-mail, senha, token, payloads, valores de limite.
3) Escrever passos e resultados esperados
Escreva passos numerados e resultados verificáveis. Prefira resultados observáveis (mensagem, status code, alteração persistida, evento emitido).
4) Vincular ao requisito/issue de origem
Crie vínculo com a história/bug que originou o teste (ex.: “testa”, “relacionado a”, “bloqueia”, conforme padrão do time). Isso habilita rastreabilidade entre entrega e validação.
Passo a passo: criando subtarefas de teste por cenário
Use quando o time executa testes como parte da própria issue de entrega.
1) Dentro da história/bug, criar subtarefas
- Crie uma subtarefa por cenário (ex.:
Teste - Happy path,Teste - Token expirado). - No resumo, inclua o recorte do cenário:
[Teste] Redefinir senha - token inválido.
2) Padronizar a descrição da subtarefa
- Pré-condições
- Dados de teste
- Passos
- Resultado esperado
- Seção de execução/evidência (preenchida durante a execução)
3) Distribuir execução e manter evidência por subtarefa
Cada subtarefa deve conter sua própria evidência (anexos e registro de execução). Isso evita “um comentário gigante” misturando cenários.
Passo a passo: usando checklist para validar critérios de aceite
Use quando o time prefere uma lista de verificações dentro da issue.
1) Criar checklist a partir dos critérios de aceite
- Transforme cada CA em itens verificáveis e independentes.
- Inclua itens negativos e bordas, não apenas o fluxo principal.
2) Definir onde a evidência ficará
- Opção A: um comentário por item crítico (com anexos).
- Opção B: um comentário único de “Execução” com tabela de evidências (recomendado para auditoria).
- Opção C: anexos na issue e referência a eles na tabela (ex.: “Anexo #3”).
Como estruturar uma execução de teste com evidências auditáveis
Independentemente do formato (issue, subtarefa ou checklist), a execução precisa registrar contexto e resultado. O mínimo recomendado para auditoria:
- Data/hora da execução (e fuso, se relevante).
- Responsável (quem executou).
- Build/versão (ex.: número do build, tag, commit curto).
- Ambiente (ex.: QA, Staging, Prod; URL; região).
- Plataforma (web/mobile; navegador/OS; device).
- Resultado (Pass/Fail/Blocked/Not Run) e motivo quando não for Pass.
- Anexos (prints, vídeo, HAR, logs, resposta de API, query) com referência clara.
- Observações: comportamento observado, variações, links para bug, evidência complementar.
Boas práticas para evidências
- Prints com contexto: inclua URL, data/hora do sistema quando possível, e o elemento relevante visível.
- Vídeos curtos para fluxos com múltiplos passos ou problemas intermitentes.
- Logs e respostas: para API, anexe a resposta ou cole em
<pre>com dados sensíveis mascarados. - Referencie o anexo no texto: “Ver Anexo 2 (print_erro_token.png)”.
Padrão de formatação recomendado (tabela na descrição)
Para consistência, use um template fixo na descrição da issue/subtarefa. Abaixo um modelo que funciona bem tanto para caso de teste quanto para subtarefa.
Template de Caso de Teste (Descrição)
| Seção | Conteúdo |
|---|---|
| Objetivo | O que este teste valida, em uma frase. |
| Pré-condições | Ex.: Usuário ativo; e-mail confirmado; feature flag X ligada. |
| Dados de teste | Ex.: email=qa.user@exemplo.com; senhaNova=Qa@12345; token=gerado no passo 2. |
| Passos | 1. Acessar /forgot-password 2. Informar email válido 3. Abrir link recebido e inserir nova senha 4. Confirmar |
| Resultado esperado | 1. Mensagem genérica de envio exibida 2. Token válido aceito 3. Senha alterada com sucesso 4. Login com nova senha funciona |
| Riscos/Observações | Ex.: Não revelar se e-mail existe; token deve expirar em X minutos. |
Template de Execução (preencher a cada rodada)
Registre cada execução como uma linha (ou um bloco) para manter histórico.
| Execução | Data/Hora | Build | Ambiente | Plataforma | Resultado | Anexos | Observações |
|---|---|---|---|---|---|---|---|
| #1 | 2026-01-26 10:15 | build-8421 (commit a1b2c3d) | QA (https://qa.exemplo.com) | Chrome 121 / Windows 11 | PASS | Anexo 1 (print_sucesso.png) | Sem desvios. |
| #2 | 2026-01-26 14:40 | build-8423 (commit d4e5f6g) | QA | Chrome 121 / Windows 11 | FAIL | Anexo 2 (video_fluxo.mp4), Anexo 3 (log.txt) | Erro 500 ao confirmar senha. Bug criado: ABC-123. |
Exemplo completo: checklist + evidência centralizada
Suponha uma história com 5 critérios de aceite. Você pode criar uma checklist e uma execução auditável no comentário/descrição.
Checklist (itens verificáveis)
- [ ] Happy path: solicitar redefinição com e-mail cadastrado
- [ ] Happy path: redefinir senha com token válido
- [ ] Negativo: e-mail não cadastrado não revela existência
- [ ] Negativo: token inválido/expirado bloqueia redefinição
- [ ] Borda: senha no limite mínimo/máximo e regras de complexidade
Registro de execução (exemplo em <pre>)
Data/Hora: 2026-01-26 16:05 Build: build-8423 (commit d4e5f6g) Ambiente: QA (https://qa.exemplo.com) Plataforma: Safari 17 / macOS 14 Resultado geral: FAIL Itens: - Solicitar redefinição com e-mail cadastrado: PASS (Anexo 1) - Redefinir senha com token válido: FAIL (Anexo 2, Bug ABC-123) - E-mail não cadastrado não revela existência: PASS (Anexo 3) - Token inválido/expirado: PASS (Anexo 4) - Senha limites/complexidade: PASS (Anexo 5) Observações: erro 500 intermitente ao confirmar senha; reproduzido 2/3 tentativas.
Checklist de qualidade do próprio caso de teste (para evitar lacunas)
- O cenário está ligado a um CA ou requisito (link/vínculo)?
- Pré-condições e dados de teste estão explícitos e reproduzíveis?
- Há pelo menos 1 cenário negativo e 1 de borda quando aplicável?
- O resultado esperado é verificável (não subjetivo)?
- O template de execução inclui data/build/ambiente/plataforma/resultado/anexos?
- Falhas geram referência clara para bug e evidência anexada?
