Execução de Plano e Casos de Teste

1. Objetivo desta página

Esta página descreve de forma detalhada, prática e operacional como ocorre a Execução do Plano e dos Casos de Teste na DBSeller. Este é o momento em que o QA aplica, na prática, tudo o que foi definido nas etapas de Elaboração da Estratégia de Teste e Elaboração do Planejamento de Testes.

Aqui, o QA deixa de planejar e passa a executar, observar, validar, registrar e comunicar. Esta etapa representa a materialização do trabalho de QA e é determinante para a qualidade final da entrega.

2. Conceito de Execução de Testes

Executar testes não significa apenas “seguir um roteiro”. Execução de testes é uma atividade técnica e analítica que envolve:

Interpretação correta dos cenários

Observação do comportamento do sistema

Comparação entre resultado obtido e resultado esperado

Registro fiel do que ocorreu

Na DBSeller, a execução de testes deve ser disciplinada, rastreável e reprodutível.

3. Pré-condições para iniciar a execução

Antes de iniciar qualquer execução, o QA deve validar se todas as condições mínimas estão atendidas.

Checklist de pré-condições

Item	Descrição	OK
Funcionalidade disponível	Código implantado no ambiente	⬜
Ambiente correto	Ambiente conforme planejamento	⬜
Dados preparados	Dados necessários cadastrados	⬜
Plano revisado	Plano de teste atualizado	⬜
Cenários claros	Cenários compreendidos	⬜

Se qualquer item não estiver atendido, a execução deve ser interrompida.

4. Fluxo geral da execução de testes

[Plano de Teste Pronto]
          |
          v
[Executar Cenário]
          |
          v
[Comparar Resultado]
          |
          v
[Cenário Passou?]
      |            |
     Sim           Não
      |            |
      v            v
[Registrar Sucesso] [Analisar Falha]
                       |
                       v
               [Confirmar Bug]
                       |
                       v
                 [Registrar Bug]

Este fluxo se repete até que todos os cenários planejados sejam executados.

5. Execução passo a passo dos cenários de teste

5.1 Leitura do cenário

Antes de executar, o QA deve:

Ler o cenário completo

Entender o contexto

Validar pré-requisitos

Nunca execute um cenário parcialmente compreendido.

5.2 Preparação do ambiente e dados

O QA deve:

Acessar a rotina correta

Conferir permissões de usuário

Garantir que os dados correspondem ao cenário

Exemplo:
Para testar o relatório de dados da escola, confirmar se a escola possui cursos ativos, gestor vinculado e atos legais cadastrados.

5.3 Execução da ação principal

Nesta etapa, o QA executa exatamente a ação descrita no Quando do cenário.

Boas práticas:

Não pular etapas

Não adaptar o fluxo

Seguir exatamente o roteiro

5.4 Validação do resultado

Após executar a ação, o QA compara:

Resultado obtido

Resultado esperado

Diferença entre eles caracteriza falha.

6. Execução por tipo de teste

6.1 Testes funcionais

Objetivo:

Validar regras de negócio

Validar comportamento esperado

Exemplo prático:
Validar se o relatório de dados da escola exibe apenas cursos ativos.

6.2 Testes exploratórios

Objetivo:

Identificar comportamentos não previstos

Boas práticas:

Executar após testes funcionais

Registrar descobertas relevantes

Exemplo:
Explorar geração do relatório para escolas com grande volume de atos legais.

6.3 Testes de regressão

Objetivo:

Garantir que funcionalidades existentes não foram impactadas

Fluxo de regressão:

[Correção ou Melhoria]
        |
        v
[Identificar Impactos]
        |
        v
[Executar Cenários Regressivos]

7. Registro do resultado da execução

Cada cenário executado deve ter seu resultado registrado.

7.1 Status possíveis

Status	Descrição
Passou	Executado conforme esperado
Falhou	Divergência identificada
Bloqueado	Execução impedida
Não executado	Ainda não executado

7.2 Evidências

O QA deve registrar evidências sempre que possível:

Prints

Vídeos

Logs

Evidência garante rastreabilidade.

8. Análise de falhas e identificação de bugs

Quando um cenário falha, o QA deve analisar cuidadosamente antes de registrar um bug.

Fluxo de análise

[Cenário Falhou]
        |
        v
[Reexecutar Cenário]
        |
        v
[Validar Ambiente e Dados]
        |
        v
[Confirmar Falha]
        |
        v
[Registrar Bug]

Nunca registrar bug sem confirmação.

9. Registro de bugs

O bug deve ser registrado de forma clara, objetiva e reprodutível.

Deve conter:

Contexto

Passos para reprodução

Resultado obtido

Resultado esperado

Evidências

Bug não é opinião, é fato observado.

10. Atualização de status da task

Durante a execução, o QA deve manter o status da task atualizado.

Estados comuns:

Em testes

Com ajustes

Aprovado

Reprovado

Atualização correta evita ruídos de comunicação.

11. Reexecução após correções

Após correção de bug:

Reexecutar o cenário que falhou

Executar cenários relacionados

Avaliar necessidade de regressão

Correção sem reexecução não é validação.

12. Resultado esperado da execução

Ao final da execução, espera-se que:

Todos os cenários tenham status definido

Bugs estejam registrados corretamente

O sistema esteja validado conforme planejamento

13. Conclusão

A Execução do Plano e dos Casos de Teste é a etapa onde o QA exerce seu papel de forma mais visível e crítica.

É nela que planejamento vira ação, estratégia vira validação e qualidade vira evidência concreta.

Na DBSeller, executar testes é uma responsabilidade técnica que exige atenção, método e comunicação clara.