Skip to main content

Estimativa de execução de testes

Esta página tem como objetivo ensinar, de forma prática, estruturada e replicável, como o QA deve realizar estimativas de tempo de QA para tarefas, melhorias, correções e projetos.

A estimativa de QA não é um chute e não é baseada apenas no tamanho da tela ou no número de campos. Ela é uma análise técnica de esforço, considerando risco, complexidade, impacto no negócio e profundidade da validação necessária.

Na DBSeller, todas as tarefas devem ser estimadas pelo QA, independentemente de executarem testes formais ou não. A estimativa é parte do planejamento e da gestão de qualidade.

2. O que é a estimativa de tempo de QA

A estimativa de tempo de QA representa o esforço necessário para garantir qualidade, e não apenas o tempo de execução mecânica de testes.

Ela engloba:

  • Análise da demanda

  • Planejamento de testes

  • Execução de testes funcionais

  • Execução de testes exploratórios

  • Validação de dados e regras de negócio

  • Registro de evidências

  • Registro e validação de bugs

  • Reexecução e regressão

  • Análise de resultados

Ou seja, QA não testa apenas. QA analisa, valida e sustenta a entrega.

3. Por que todas as tarefas devem ser estimadas

A estimativa de QA é obrigatória porque:

  • Permite planejamento realista

  • Dá visibilidade do esforço de qualidade

  • Evita subestimação do trabalho de QA

  • Sustenta prazos e decisões de entrega

  • Reduz pressão indevida no final do ciclo

Sem estimativa, QA vira variável de ajuste. Com estimativa, QA vira parte do planejamento.

4. Princípios da estimativa de QA

Antes de estimar, o QA deve internalizar alguns princípios:

  • QA estima risco, não apenas funcionalidade

  • Quanto maior a flexibilidade da funcionalidade, maior o esforço

  • Relatórios exigem validação de consistência e veracidade

  • Integrações aumentam esforço exponencialmente

  • Histórico de falhas importa

Esses princípios evitam estimativas irreais.

5. Leitura e análise da demanda

O primeiro passo é a leitura completa da task.

O QA deve identificar:

  • O que está sendo criado ou alterado

  • Quais módulos são impactados

  • Se existe comportamento semelhante no sistema

  • Se há documentos anexos (RM, layouts, regras)

Fluxo inicial:

[Receber Task]
      |
      v
[Ler Descrição Completa]
      |
      v
[Identificar Escopo e Impactos]

Nunca estimar sem leitura completa.

6. Identificação de fatores que impactam o esforço

A estimativa deve considerar múltiplos fatores.

6.1 Complexidade funcional

Nível Característica
Baixa Fluxo simples, poucas regras
Média Múltiplas regras e filtros
Alta Configuração dinâmica e exceções

Relatórios editáveis geralmente entram como complexidade alta.

6.2 Validação de dados e veracidade

Relatórios exigem validação cruzada:

  • Conferir se dados batem com telas originais

  • Validar filtros

  • Validar regras de exclusão/inclusão

Isso aumenta significativamente o esforço de QA.

6.3 Volume de cenários

O QA deve estimar:

  • Quantidade de cenários positivos

  • Quantidade de cenários negativos

  • Quantidade de cenários de exceção

Quanto maior o número de combinações, maior o tempo.

6.4 Tipos de teste envolvidos

Tipo de teste Impacto na estimativa
Funcional Médio
Exploratório Médio a alto
Regressão Médio
Dados/Relatórios Alto

7. Decomposição do trabalho de QA

A estimativa deve ser feita por blocos de atividade, nunca como um número único.

Blocos comuns:

  • Análise da demanda

  • Planejamento de testes

  • Preparação de dados

  • Execução funcional

  • Execução exploratória

  • Registro de evidências

  • Bugs e reexecução

  • Regressão

Fluxo:

[Task]
  |
  v
[Decompor Atividades]
  |
  v
[Estimar Cada Bloco]

8. Exemplo prático de estimativa – Relatório Editável de RH

Contexto resumido

Task: Relatório Editável de Recursos Humanos

Características principais:

  • Dois módulos (Escola e Secretaria)

  • Muitos filtros e combinações

  • Exportação PDF e CSV

  • Limite de pixels

  • Organização dinâmica de campos

  • Validação de veracidade dos dados

8.1 Decomposição da estimativa

Atividade Esforço estimado
Leitura e análise da task 2h
Planejamento e cenários 3h
Preparação de massa de dados 2h
Execução testes funcionais 6h
Testes exploratórios 4h
Validação de dados com telas 4h
Registro de evidências 2h
Bugs, reexecução e regressão 3h
Total estimado 26h

8.2 Justificativa da estimativa

O esforço é elevado porque:

  • Trata-se de relatório altamente configurável

  • Existe risco alto de inconsistência de dados

  • Múltiplas combinações de filtros

  • Dois contextos distintos (Escola e Secretaria)

  • Exportação com regras diferentes (PDF x CSV)

Essa justificativa deve acompanhar a estimativa.

9. Ajuste de estimativa durante a execução

Estimativas podem ser ajustadas quando:

  • Escopo muda

  • Novas regras surgem

  • Bugs críticos aparecem

Fluxo de ajuste:

[Estimativa Inicial]
        |
        v
[Execução]
        |
        v
[Escopo Alterado?]
     |           |
    Não          Sim
     |           |
     v           v
[Manter]   [Reestimar]

Transparência é essencial.

10. Uso das estimativas como aprendizado

Após a entrega, o QA deve comparar:

  • Tempo estimado x tempo real

Isso gera aprendizado para futuras estimativas.

Exemplo:

Item Estimado Real
Total QA 26h 28h

Diferenças devem ser analisadas, não ignoradas.

11. Boas práticas finais

  • Nunca estimar sem entender a demanda

  • Sempre justificar números

  • Estimar por atividade

  • Considerar risco e veracidade de dados

  • Usar histórico como referência

12. Conclusão

A Estimativa de Tempo de QA é parte essencial do processo de qualidade.

Ela protege o QA, o time e o produto, permitindo planejamento realista e entregas mais seguras.

Na DBSeller, estimar não é burocracia. É maturidade de processo.

Back to top