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.