Skip to main content

Fluxo de Testes para Nova Funcionalidade

1. Entrada da demanda

O fluxo se inicia no momento em que a demanda é apresentada ao QA, normalmente durante alinhamentos iniciais ou refinamentos.

Nesse ponto, o QA ainda não testa, mas começa a construir seu mapa mental da funcionalidade.

O que o QA observa nesse momento

  • qual problema a funcionalidade resolve

  • qual módulo ou rotina será impactado

  • se é algo novo ou evolução de algo existente

  • quem é o usuário impactado

Esse entendimento inicial é fundamental para todo o restante do fluxo.

2. Análise de requisitos (construção do mapa mental)

Aqui o QA transforma a demanda em entendimento estruturado, conectando regras, fluxos e impactos.

O mapa mental do QA envolve

  • regras de negócio explícitas

  • comportamentos implícitos

  • exceções possíveis

  • dependências com outras rotinas

  • histórico de problemas semelhantes

O QA começa a se perguntar:

  • onde isso pode quebrar

  • o que já existe que pode ser afetado

  • quais dados estão envolvidos

  • quais estados da tela precisam ser considerados

Esse raciocínio é a base da estratégia de teste.

3. Definição da estratégia de teste

Com o mapa mental formado, o QA define a estratégia de teste específica da demanda.

Nessa etapa o QA decide

  • quais riscos são mais relevantes

  • quais tipos de teste serão priorizados

  • onde concentrar esforço

  • o que conscientemente ficará fora do escopo

A estratégia considera:

  • risco

  • tipo de sistema

  • prazo

  • impacto para o usuário

Essa definição evita testes genéricos e direciona o trabalho.

4. Aplicação dos tipos de teste

Com base na estratégia, o QA define quais tipos de teste serão aplicados, sempre considerando os testes padrão obrigatórios e os testes específicos da demanda.

Exemplos de aplicação

  • testes de aceitação para validar critérios

  • testes exploratórios para descobrir comportamentos não previstos

  • testes de integração para validar impactos entre rotinas

  • testes de regressão para proteger funcionalidades existentes

  • testes de usabilidade para avaliar experiência do usuário

Essa aplicação não é mecânica. Ela é adaptada ao contexto da funcionalidade.

5. Execução dos testes

Com tudo definido, o QA inicia a execução.

Durante a execução, o QA deve

  • validar cenários planejados

  • explorar variações não previstas

  • observar comportamento real do sistema

  • registrar evidências de forma adequada

  • reportar desvios encontrados

A execução não é apenas “seguir casos”, mas confirmar se o sistema se comporta como esperado no uso real.

6. Comunicação de resultados

Após a execução, o QA consolida e comunica os resultados.

A comunicação envolve

  • status da validação

  • bugs encontrados

  • riscos identificados

  • limitações de escopo, se houver

Essa comunicação garante alinhamento entre QA, Desenvolvimento e Produto.

7. Encerramento da demanda

O encerramento ocorre quando:

  • os critérios de aceite foram atendidos

  • os riscos estão mapeados e aceitos

  • os testes planejados foram executados

  • a decisão de liberação está suportada por evidências

Nesse ponto, o QA não apenas “finaliza a tarefa”, mas entrega confiança para a próxima etapa do fluxo.

O papel do conhecimento adquirido no fluxo

Todo o conhecimento documentado na wiki é aplicado neste fluxo:

  • conceitos de qualidade orientam decisões

  • estratégias direcionam esforço

  • tipos de teste definem abordagem

  • planos organizam a execução

  • evidências sustentam a liberação

Esse fluxo mostra que QA na DBSeller não é etapa final, mas parte ativa do ciclo de desenvolvimento.

Resultado esperado desse fluxo

Ao seguir esse fluxo, espera-se que:

  • riscos sejam identificados antecipadamente

  • testes sejam focados e eficientes

  • retrabalho seja reduzido

  • decisões sejam mais seguras

Esse é o modelo de atuação de QA adotado na DBSeller para novas funcionalidades.

Back to top