Um ecrã pode funcionar e, ainda assim, a alteração não resolver o problema que motivou o seu desenvolvimento. Pode aceitar dados que deveriam ser rejeitados, calcular um montante incorreto ou deixar uma operação a meio num sistema ligado. Por isso, os testes de aceitação baseados em regras de negócio não se limitam a verificar elementos visuais: avaliam se o processo produz o resultado esperado para as pessoas e para a organização.
A chave está em partir de decisões operacionais concretas e convertê-las em cenários que possam ser verificados com dados, resultados e evidências. Assim, as equipas de produto, negócio, QA e tecnologia partilham uma definição prática do que significa aceitar a alteração.
Verificar um ecrã não é validar uma regra
Um teste de interface pode confirmar que um botão aparece, que é possível escrever num formulário ou que é apresentada uma mensagem. Estas verificações podem ser necessárias, mas, por si só, não demonstram que uma política de negócio está a ser respeitada. Para isso, é preciso acompanhar a relação entre uma condição e a sua consequência.
Por exemplo, a questão não é apenas saber se um pedido pode ser enviado. Também é preciso saber que condições determinam a sua aprovação, o que acontece quando falta um dado e que estado devem receber os casos que exigem análise. A regra pode ser aplicada num ecrã, num serviço ou num processo manual posterior; a aceitação deve verificar o resultado relevante sem pressupor onde está implementada.
Uma regra útil para testar expressa uma decisão observável: perante determinadas condições de entrada, o processo deve produzir um resultado identificável. Se a regra depender de interpretação, convém esclarecê-la antes de redigir o caso. Um teste não deve ser o lugar onde se descobre pela primeira vez o significado de uma política.
Identificar regras, intervenientes, dados e resultados
Antes de escrever os cenários, reúna quem conhece o processo e quem o implementa. O objetivo é descrever que decisão é tomada, quem participa e que informações influenciam essa decisão. Não é necessário documentar todos os detalhes do sistema, mas as condições que alteram o resultado têm de ficar explícitas.
- Interveniente: quem inicia ou analisa a operação, como uma pessoa utilizadora ou alguém com perfil de supervisão.
- Condições: regras, permissões, estados anteriores e restrições que afetam a decisão.
- Dados de entrada: valores necessários para executar o cenário, incluindo os que podem estar em falta ou ser inválidos.
- Resultado esperado: estado final, ação permitida ou recusada, cálculo, notificação ou tarefa a gerar.
- Evidência: forma de verificar o resultado, por exemplo, através do estado registado, de uma resposta visível ou de uma atividade no sistema correspondente.
Convém registar as dúvidas e indicar quem é responsável por as esclarecer. Se uma regra tiver exceções, identifique quem as pode autorizar e como fica registada essa autorização. Não transforme uma suposição da equipa num requisito implícito.
Transformar regras em cenários claros e observáveis
Redija cada cenário com contexto suficiente para que outra pessoa o possa executar e avaliar o resultado. Uma estrutura simples é: dadas determinadas condições, quando é realizada uma ação, espera-se um resultado concreto. A forma importa menos do que a precisão: as entradas e as expectativas devem ser explícitas.
- Descreva uma situação de negócio reconhecível, não uma sequência de cliques sem finalidade.
- Indique os dados e o estado inicial necessários para reproduzi-la.
- Explicite a ação que inicia a decisão ou o processo.
- Defina o resultado a observar e onde o verificar.
Um critério como «o sistema trata corretamente o pedido» não pode ser aprovado de forma consistente. Em contrapartida, um critério verificável especifica que pedidos são aceites, quais são recusados ou encaminhados para análise e que estado fica registado. Se o resultado esperado admitir várias interpretações, o critério ainda precisa de ser trabalhado.
Evite misturar demasiadas regras num único cenário. Quando algo falhar, a equipa deve conseguir identificar o comportamento que não corresponde ao acordado. Ao mesmo tempo, não duplique testes que verificam o mesmo resultado com dados equivalentes sem acrescentarem uma cobertura diferente.
Cobrir limites e exceções sem multiplicar os casos
O caso habitual ajuda a confirmar o percurso principal, mas raramente é suficiente. As regras costumam produzir resultados diferentes num limite, perante um dado em falta ou quando se combinam condições. Comece por perguntar que dado poderia alterar a decisão e o que acontece imediatamente antes, no próprio limite e logo depois.
Dê prioridade às variações que alteram o resultado do processo: valores permitidos e não permitidos, permissões distintas, estados incompatíveis, duplicados ou informações incompletas, desde que correspondam às regras reais. Se várias condições forem independentes, pode escolher um conjunto representativo em vez de testar todas as combinações possíveis. Se uma combinação puder alterar a decisão, deve ser abrangida pelos testes.
Também convém distinguir uma exceção de negócio de um erro técnico. Um pedido recusado por uma política pode ser um resultado correto; uma interrupção que impede guardar o estado é outra situação. Acordar esta diferença evita rejeitar uma alteração porque uma regra foi aplicada como devia ou aceitar uma falha operacional como se fosse uma exceção prevista.
Validar percursos completos entre sistemas
Quando participam várias aplicações ou equipas, verifique o percurso de ponta a ponta, desde o acontecimento que inicia o processo até ao resultado de que a operação precisa. Não basta confirmar que um sistema enviou informações: é preciso verificar se o sistema recetor as interpretou e se o estado final é coerente.
Identifique os pontos de transferência, os responsáveis e os sinais observáveis. Por exemplo: o que acontece se o segundo sistema estiver indisponível? A operação é tentada novamente? Fica pendente para análise? Como se evita processá-la duas vezes? As respostas devem refletir o comportamento acordado, não capacidades presumidas. Se não for possível testar o percurso de forma integrada num ambiente disponível, documente que parte é validada separadamente e que incerteza permanece.
Um mapa simples do fluxo ajuda a distinguir as verificações que pertencem à aceitação dos testes técnicos de cada componente. A aceitação centra-se na consequência operacional; os testes de componentes e de integração fornecem outras evidências, mas não substituem a validação do resultado de negócio.
Acordar evidências, responsáveis e decisão
Antes da execução, combine quem prepara os dados, quem realiza cada cenário e quem decide perante uma divergência. A área de negócio deve confirmar que o resultado corresponde à regra; produto coordena o âmbito e as prioridades; QA pode facilitar a cobertura e registar resultados; tecnologia ajuda a diagnosticar o comportamento. As responsabilidades podem variar, mas não devem ficar implícitas.
Defina o que conta como evidência suficiente e como será registada: cenário, dados utilizados, resultado observado, estado de aprovação e eventuais ocorrências. Não é necessário recolher informações sensíveis que não contribuam para a verificação. Utilize dados representativos e autorizados, e prepare uma alternativa controlada quando não for adequado usar dados reais.
A decisão também deve ser explícita. Uma falha numa regra crítica pode impedir a aceitação; uma divergência menor poderá ser aceite com uma ação acordada, se as pessoas responsáveis tiverem autoridade para decidir. Em qualquer caso, registe o impacto, o responsável e o passo seguinte. Não esconda uma condição pendente sob um «aprovado» ambíguo.
Erros frequentes e lista de verificação
Os problemas mais comuns são critérios vagos, cenários centrados apenas no caso ideal, dados que não representam o processo e testes que repetem outras verificações sem validar uma nova decisão. Também é arriscado validar cada sistema isoladamente e presumir que o fluxo completo funcionará automaticamente. A solução não é acrescentar casos sem critério, mas rever que regra, exceção ou transferência ainda não tem evidência clara.
Antes da sessão de aceitação, verifique o seguinte:
- As regras e respetivas exceções foram confirmadas pelas pessoas responsáveis?
- Cada cenário tem condições iniciais, dados, ação e resultado observável?
- Estão abrangidos o percurso principal, os limites relevantes e as recusas esperadas?
- Os casos entre sistemas verificam o estado final e as falhas de transferência pertinentes?
- Está definido quem executa, quem fornece evidências e quem toma a decisão final?
- As divergências, os riscos pendentes e os acordos ficam registados?
Uma aceitação eficaz não procura demonstrar que tudo funciona em qualquer circunstância. Procura reunir evidências suficientes de que as regras relevantes são cumpridas em cenários representativos e de que as exceções importantes têm uma resposta acordada. Esta abordagem reduz ambiguidades e permite aceitar, corrigir ou adiar uma alteração com melhores fundamentos.