Introdução

O ISTQB não prescreve um processo único. Descreve atividades comuns, sem as quais o teste tem menos chance de atingir seus objetivos, e deixa a adaptação para o contexto. Os fatores que mais pesam:

• modelos de ciclo de vida e metodologia do projeto;
• níveis e tipos de testes considerado;
• riscos de produto e de projeto;
• domínio de negócio;
• restrições operacionais: orçamento e recursos, prazos, complexidade, requisitos constrautias e regulatórios;
• políticas e práticas da organização;
• padrões internos e externos exigidos.

As atividades podem rodar em sequência ou de forma iterativa. Em qualquer projeto, podem se sobrepor, ser combinadas, rodar em paralelo ou ser omitidas. Em ágil, o teste acontece de forma contínua, dentro de cada iteração. O que fica estável é a pergunta que cada atividade responde.

O exemplo que atravessa o texto

Cenário hipotético. Um ERP financeiro SaaS vai gerar remessa CNAB 240 de pagamento a fornecedores para um segundo banco (Banco B). Seis semanas, três sprints, dois devs e dois testers. O banco exige homologação do arquivo e seu sandbox cobre só parte dos cenários. Risco central: arquivo rejeitado ou aceito em duplicidade.

As sete atividades

Os produtos de trabalho de todas as atividades formam o testware. Planejamento e monitoramento e controle atravessam o projeto inteiro: o plano é revisto a partir do que o monitoramento mostra.

1. Planejamento: quais objetivos, e qual abordagem?

Define os objetivos do teste e escolhe a abordagem que os atinge dentro das restrições e do contexto. A saída é o plano de teste. No mínimo ele aponta a base de teste (o material de onde os testes são derivados: requisitos, histórias, layouts, código) e os critérios de saída, também chamados de definição de feito. Um plano completo traz ainda escopo, premissas, partes interessadas, comunicação, riscos, abordagem, orçamento e cronograma.

No exemplo: objetivos: arquivo aceito pelo banco, zero duplicidade, sem regressão na remessa do Banco A. Abordagem baseada em risco. Critérios de saída: 100% das condições de risco alto executadas, nenhum defeito crítico ou alto aberto, homologação aprovada.

2. Monitoramento e controle: estamos no plano?

Compara o progresso real com o plano, usando as métricas definidas nele, e toma as ações necessárias para atingir os objetivos. Também avalia os critérios de saída: verifica a cobertura, avalia o nível de qualidade e decide se são necessários mais testes. Produz relatórios de progresso, contínuos, e relatórios de resumo, nos marcos. Relatório bom traz o que o público precisa para decidir.

No exemplo: na semana 4, 55% dos casos executados contra 70% previstos, e 62% das condições de risco alto contra 80%. Causa: sandbox fora do ar por dois dias. Ações de controle: priorizar a suíte de risco alto, alocar mais um tester por três dias e pedir ao banco uma janela dedicada.

3. Análise: o que testar?

Analisa a base de teste para definir e priorizar condições de teste, identificar as funcionalidades a cobrir e avaliar a testabilidade. A análise também procura defeitos na própria base: ambiguidades, omissões, inconsistências, imprecisões, contradições e afirmações supérfluas. Saídas: condições de teste priorizadas, ligadas por rastreabilidade aos elementos da base, e relatórios de defeitos da base.

No exemplo: a história US-09 ("título já enviado não reenvia") gera as condições CT-03 e CT-04. Na mesma análise aparece um defeito: o texto do layout do banco manda data em DDMMAAAA, e o exemplo do PDF usa AAAAMMDD. O defeito vai para o banco antes de existir uma linha de código.

4. Modelagem: como testar?

Transforma condições em casos de teste, priorizados, com apoio de técnicas como partição de equivalência, análise de valor-limite e tabela de decisão. Define os dados necessários, projeta o ambiente e identifica infraestrutura e ferramentas. O ambiente é projetado aqui; quem o constrói é a implementação. Casos de alto nível, sem valores concretos, são reutilizáveis entre ciclos.

No exemplo: o campo valor tem 13 posições inteiras e 2 decimais. Valor-limite: 0,00 (inválido), 0,01, 9.999.999.999.999,99 e 10.000.000.000.000,00 (inválido). Caso TC-03, de alto nível: "remessa com título já enviado e sem retorno de rejeição não gera segmento A".

5. Implementação: está tudo pronto para rodar?

Cria ou obtém o que falta para executar: procedimentos de teste priorizados, scripts automatizados, suítes, cronograma de execução, ambiente construído e verificado, dados preparados e carregados. É aqui que os casos de alto nível ganham valores concretos. Também confere e atualiza a rastreabilidade: toda condição tem caso? Todo caso tem condição?

No exemplo: validador de layout automatizado no pipeline; suítes smoke, risco alto e regressão Banco A; versão do validador fixada no ambiente.

6. Execução: o resultado real bate com o esperado?

Roda as suítes conforme o cronograma, manualmente ou com ferramentas. Registra IDs e versões do objeto de teste, das ferramentas e do testware; compara resultado real com esperado; analisa as anomalias antes de reportar; registra os resultados (passou, falhou, bloqueado); repete testes por correção, confirmação ou regressão. Saídas: status por teste, relatórios de defeitos e as versões envolvidas.

No exemplo: TC-03 falhou e gerou D-11 (duplicidade, crítico). TC-12 falhou e gerou D-14 (calendário sem feriados municipais). TC-09 também falhou, mas era falso positivo: o ambiente rodava o validador 2.2, com a regra antiga. Atualizado o validador, o teste passou. Não havia defeito no produto, e foi a versão registrada que permitiu descobrir isso.

7. Conclusão: o que entregamos e o que aprendemos?

Acontece nos marcos: fim de um nível de teste, de uma iteração, de uma release. Verifica se os defeitos foram fechados e registra como solicitações de mudança ou itens de backlog os que restaram. Cria o relatório de resumo, finaliza e arquiva ambiente, dados, infraestrutura e testware, e entrega o testware a quem vai mantê-lo. Analisa as lições aprendidas e usa o que aprendeu para melhorar a maturidade do processo.

No exemplo: um defeito de severidade média vira item de backlog. Validador, massa de dados e configuração do ambiente vão para a manutenção, reutilizáveis num futuro Banco C. Lições: validar as ambiguidades do layout com o banco antes da modelagem; incluir o calendário de feriados na base de teste desde o planejamento; reservar a janela do sandbox no cronograma.

Rastreabilidade: o que liga as atividades

Rastreabilidade é o vínculo entre cada elemento da base de teste e o testware associado a ele: condições, casos, procedimentos, suítes, resultados e defeitos. É estabelecido e mantido ao longo de todo o processo. Funciona nos dois sentidos. Da base para o testware, mostra cobertura: requisito sem condição de teste é lacuna. Do testware para a base, mostra por que cada teste existe: teste sem requisito é teste órfão.

No exemplo, a cadeia é: US-09 → CT-03 → TC-03 → suíte risco alto → ciclo 1: falhou (D-11) → ciclo 2: passou. Além de medir cobertura, ela serve para:

• analisar o impacto de mudanças: quando o banco esclarece o formato da data, a cadeia lista as condições e os casos a revisar;
• tornar o teste auditável: a evidência de que título enviado não reenvia é US-09 → TC-03 → log do ciclo 2;
• atender critérios de governança de TI: evidência por requisito, sem retrabalho;
• melhorar a compreensão dos relatórios: status por requisito (passou, falhou, pendente) em vez de contagem de casos;
• traduzir o aspecto técnico para as partes interessadas: "reenvio de título já enviado está bloqueado e verificado", em vez de "TC-03 passou";
• avaliar produto, processo e projeto: qualidade (1 crítico e 2 altos abertos), processo (D-14 aponta falha na base de teste) e projeto (62% do risco alto executado contra meta de 80%).

A cadeia pode viver numa ferramenta de gestão de teste ou num sistema próprio. A ferramenta é meio; o que importa é a cadeia existir e ser mantida.

Quem faz o quê

A gestão de teste responde pelo processo e pela equipe: planejamento, monitoramento e controle, conclusão. O papel de teste responde pela parte técnica: análise, modelagem, implementação e execução. Em times ágeis, a gestão pode ficar no próprio time.

Cinco erros comuns

• Plano sem critério de saída: ninguém sabe quando parar.
• Tratar toda anomalia como defeito: analisar antes de reportar evita falso positivo.
• Rastreabilidade em um sentido só: esconde os testes órfãos.
• Confundir modelagem com implementação: uma define como testar, a outra deixa tudo pronto para rodar.
• Pular a conclusão: lições e testware se perdem.