Elaboração de Estratégia de Teste da Task

1. Objetivo da Página

Esta página define o processo oficial de Elaboração de Estratégia de Teste da Task na DBSeller, sendo parte fundamental do Book Execução de Testes, dentro do capítulo QA – Elaboração.

O objetivo desta etapa é garantir que, antes da execução de qualquer teste, o QA tenha:

Compreensão clara da demanda.
Visão dos riscos técnicos e funcionais.
Definição consciente dos tipos de teste necessários.
Alinhamento explícito sobre o que será considerado sucesso.

A Estratégia de Teste da Task não é um documento burocrático. Ela é um instrumento de raciocínio e decisão, que orienta todo o trabalho de QA durante o desenvolvimento e após a entrega.

2. Quando a Estratégia de Teste da Task deve ser elaborada

A elaboração da estratégia ocorre após o refinamento da demanda e antes do início da execução dos testes, normalmente enquanto o desenvolvimento está em andamento.

Ela deve ser aplicada em:

Novas funcionalidades.
Melhorias relevantes.
Correções de bugs com impacto médio ou alto.
Demandas que envolvem regras de negócio, integrações ou múltiplos sistemas.

Demandas extremamente simples podem ter uma estratégia mais enxuta, mas nunca inexistente.

3. Visão geral do fluxo de elaboração

Fluxo macro da Elaboração da Estratégia de Teste:

Leitura e entendimento da demanda.
Identificação de contexto técnico e de negócio.
Mapeamento de riscos.
Definição dos tipos de teste.
Consolidação do resultado esperado.

Fluxograma conceitual:

[Receber Demanda]
        |
        v
[Leitura e Entendimento]
        |
        v
[Mapeamento de Riscos]
        |
        v
[Definição dos Tipos de Teste]
        |
        v
[Estratégia de Teste Definida]

Este fluxo orienta toda a atuação do QA até o início da execução.

4. Leitura da Demanda

4.1 Objetivo da leitura da demanda

A leitura da demanda tem como objetivo entender o problema que está sendo resolvido, e não apenas a solução técnica proposta.

O QA deve responder, minimamente, às seguintes perguntas:

Qual dor essa demanda resolve?
Quem é impactado?
O que muda no comportamento do sistema?
O que pode quebrar se algo sair errado?

4.2 Fontes da demanda

A leitura deve considerar todas as fontes disponíveis:

Card no Jira.
Documentação funcional.
Prints, vídeos ou exemplos enviados.
Discussões de refinamento.
Históricos de bugs relacionados.

4.3 Checklist de leitura da demanda

Tabela de apoio:

Item	Pergunta	Respondido?
Contexto	Entendi o problema de negócio?	Sim / Não
Escopo	Sei exatamente o que entra e o que não entra?	Sim / Não
Impacto	Identifiquei funcionalidades afetadas?	Sim / Não
Dados	Há impacto em dados existentes?	Sim / Não
Integrações	Envolve sistemas externos?	Sim / Não

Se houver respostas negativas, a estratégia não deve avançar sem esclarecimento.

4.4 Exemplo real

Demanda: Ajustar cálculo de taxa de seguro exibida na tela de simulação.

Boa leitura da demanda identifica:

Alteração visual.
Alteração de regra de cálculo.
Impacto direto em decisão do usuário.
Possível impacto em relatórios e contratos.

Aqui o QA já percebe que não é apenas um ajuste de front.

5. Mapeamento de Risco

5.1 O que é mapeamento de risco

Mapear riscos significa antecipar onde a demanda pode falhar e quais falhas geram maior impacto.

O foco não é testar tudo, mas testar o que realmente importa.

5.2 Tipos de risco considerados

Na DBSeller, o QA deve considerar, no mínimo:

Risco funcional.
Risco de negócio.
Risco técnico.
Risco de integração.
Risco de regressão.

5.3 Matriz de risco

Exemplo de matriz utilizada:

Risco	Impacto	Probabilidade	Nível
Cálculo incorreto	Alto	Médio	Alto
Erro visual	Médio	Alto	Médio
Quebra de API	Alto	Baixo	Médio
Regressão em fluxo antigo	Alto	Médio	Alto

O nível de risco orienta prioridade e profundidade dos testes.

5.4 Exemplo real

Na alteração de cálculo de taxa:

Risco alto de erro financeiro.
Risco médio de inconsistência visual.
Risco alto de regressão em simulações antigas.

Conclusão do QA: foco em validação de cálculo, cenários limite e regressão direcionada.

6. Definição de Tipos de Teste

6.1 Princípio básico

Os tipos de teste não são escolhidos por preferência, mas com base nos riscos mapeados.

6.2 Tipos de teste mais comuns

Teste funcional.
Teste de regressão.
Teste exploratório.
Teste de integração.
Teste automatizado.

6.3 Tabela de decisão

Risco Identificado	Tipo de Teste Prioritário
Regra de negócio	Funcional + Exploratório
Alteração crítica	Regressão
Integração	Teste de API
Fluxo repetitivo	Automação

6.4 Automação na estratégia

Durante a elaboração, o QA deve responder:

Este cenário vale ser automatizado?
Ele será reutilizado?
Ele é estável?

Se a resposta for negativa, o teste permanece manual.

6.5 Exemplo real

Na taxa de seguro:

Testes funcionais para novos cálculos.
Regressão manual focada.
Avaliação futura para automação do cálculo base.

7. Resultado Esperado

7.1 O que é resultado esperado na estratégia

Resultado esperado não é apenas o comportamento do sistema, mas o que se espera do processo de QA.

Inclui:

O que será validado.
O que não será validado.
O nível de confiança esperado.

7.2 Definição clara evita conflitos

Quando o resultado esperado está bem definido:

Evita retrabalho.
Evita discussões pós-teste.
Facilita Go ou No-Go.

7.3 Exemplo de definição

Para a task de taxa de seguro:

Resultado esperado da estratégia:

Garantir que o cálculo exibido corresponda exatamente à regra aplicada.
Garantir que simulações anteriores não sejam impactadas.
Garantir clareza da informação para o usuário final.

8. Relação com Execução de Testes

A Estratégia de Teste da Task alimenta diretamente:

Execução de Casos de Teste.
Execução de Testes Exploratórios.
Execução de Testes de Regressão.

Nada deve ser executado sem estar ancorado nesta estratégia.

9. Boas Práticas

Estratégia simples é melhor que estratégia inexistente.
Prefira clareza a excesso de texto.
Sempre registre decisões e exclusões.
Atualize a estratégia se a demanda mudar.

10. Conclusão

A Elaboração de Estratégia de Teste da Task é o ponto onde o QA deixa de ser apenas executor e passa a atuar como agente de qualidade.

Ela conecta negócio, técnica, risco e execução, garantindo que o esforço de teste seja inteligente, direcionado e eficaz.

Na DBSeller, esta etapa é considerada obrigatória para a maturidade do processo de QA e deve ser tratada como parte essencial da entrega, não como etapa opcional.