Caso de teste, cenário e script: três coisas que não são a mesma

Você abre a suíte de testes que herdou. Há uma pasta chamada "cenários" que contém arquivos com passos numerados, uma pasta "casos" que contém código de Selenium, e uma planilha intitulada "scripts de regressão" que na verdade descreve comportamento de negócio. Ninguém lembra por quê. Cada palavra aponta para algo diferente do que seu nome promete, e agora é você quem tem que adivinhar.

Isso não é um problema estético. Quando três conceitos distintos usam nomes trocados entre si, a suíte fica ilegível: você não sabe qual arquivo descreve uma intenção de negócio, qual define uma verificação concreta e qual é apenas código que aperta botões. A resposta curta é esta: caso de teste, cenário e script de automação são três camadas diferentes, e confundi las é a forma mais barata de acumular dívida técnica em QA.

01 · a camadaO cenário descreve uma situação, não uma verificação

Um cenário de teste é a descrição de uma situação de negócio que você quer cobrir. Responde à pergunta "qual condição do mundo real me importa". Não diz como verificá la nem com quais dados exatos: diz que história você está contando. "Um usuário tenta pagar com um cartão vencido" é um cenário. Ainda não é um teste executável; é uma intenção.

O cenário vive na linguagem do produto, não na do sistema. Por isso um analista de negócio pode lê lo e concordar sem saber nada do banco de dados. O padrão ISO/IEC/IEEE 29119-1 separa deliberadamente o nível da condição de teste (o que se quer exercitar) do nível do caso concreto que a materializa [1]. O cenário é a dobradiça entre o requisito e o teste.

O cenário não verifica nada. Ele enquadra o que vale a pena verificar.

A utilidade do cenário é de cobertura. Quando você lista cenários, está mapeando o espaço de situações que o produto deve suportar: cartão válido, cartão vencido, cartão sem fundos, rede caída no meio do pagamento. Um cenário pode dar origem a vários casos. É um nível de abstração acima, e perdê lo de vista é o que faz as suítes terem mil casos sem que ninguém saiba quais situações elas cobrem de verdade.

02 · o oráculoO caso de teste tem resultado esperado; o script não decide nada

Um caso de teste é a verificação concreta. Tem o que um cenário não tem: pré-condições, dados de entrada específicos e, sobretudo, um resultado esperado. Esse resultado esperado é o oráculo: a afirmação do que deveria acontecer para que o teste seja considerado aprovado. Sem resultado esperado não há caso de teste; há um passeio pela aplicação.

O ISTQB define o caso de teste precisamente por esse trio: valores de entrada, pré-condições de execução e resultados esperados [2]. Um caso é executável por um humano lendo passos, ou por uma máquina. E aqui entra a terceira camada, a que mais gente confunde com as outras duas.

O script de automação é código. É a implementação mecânica de um ou vários casos para que sejam executados sem uma pessoa apertando botões. O ponto crítico: o script não fornece o oráculo, ele o herda do caso. Um script que clica em coisas e navega telas mas não afirma nenhum resultado esperado não está testando nada; está automatizando um passeio. O resultado esperado vive no caso; o script apenas o comprova em alta velocidade.

Por isso misturar os nomes custa caro. Se você chama de "caso" um script sem asserções, seu relatório de cobertura mente: diz que você verifica algo que na verdade apenas percorre. Se você chama um caso de "cenário", perde o nível de negócio e já não consegue raciocinar sobre quais situações faltam. A terminologia não é burocracia: é o que faz as métricas da suíte significarem alguma coisa.

03 · a dívidaPor que a higiene terminológica se paga sozinha dentro de um ano

A confusão não dói no dia em que você escreve a suíte. Dói doze meses depois, quando outra pessoa (ou você mesmo sem memória do contexto) tem que mantê la. Uma suíte onde cenário, caso e script estão claramente separados se lê como um índice: em cima as situações, no meio as verificações, embaixo o código. Uma suíte onde os três nomes estão trocados se lê como um hieróglifo.

Há três dívidas concretas que nascem da mistura. A primeira é a dívida de cobertura: sem a camada de cenário visível, ninguém sabe quais situações de negócio ficaram sem teste, então elas aparecem em produção. A segunda é a dívida de oráculo: quando os scripts são chamados de casos, entra automação sem asserções e a suíte dá falsa confiança. A terceira é a dívida de manutenção: quando muda uma regra de negócio, você não sabe quais arquivos tocar porque os nomes não dizem em qual camada cada coisa vive.

A regra operacional é simples. Nomeie as pastas pela sua camada e não deixe um arquivo subir ou descer de nível sem renomeá lo. Um cenário nunca contém código. Um caso sempre contém um resultado esperado. Um script sempre herda seu oráculo de um caso e jamais inventa o seu por acidente. Se você respeitar essas três fronteiras, a pessoa que abrir sua suíte daqui a um ano poderá lê la sem arqueologia.

A palavra descuidada de hoje é o arquivo indecifrável daqui a um ano.

Quando você passar da teoria à prática e começar a converter casos em scripts, essa separação fica ainda mais rentável: a automação só escala se cada script souber exatamente qual caso implementa e qual oráculo comprova. Sem essa disciplina de nomes, automatizar é multiplicar a desordem em vez de reduzir o esforço.