Tags:

Utilizando tabela verdade no caso de teste

Inseridos no “mundo ágil” cada vez mais buscamos formas que facilitem e agilizem nossos processos nos projetos.

Uma dica interessante para organizar cenários de teste seria utilizar o conceito de tabelas verdades.

Sim, estou me referindo  aquela tabela que você aprendeu em tautologia nas aulas de lógica.

Exemplo de tabela-verdade
Representação de uma tabela verdade[1]

Tabela verdade é um tipo de tabela matemática usada em lógica para determinar se uma fórmula é válida. Cenários de teste podem ser criados em formato de tabela verdade com os parâmetros de entrada/configurações, que seriam nossas variáveis dessa tabela. Para a ação do caso de teste poderíamos fazer um paralelo com a fórmula aplicada, e o resultado esperado tem praticamente o mesmo significado que seria o que esperamos como saída para aquela “junção de informações”. Falando assim pode parecer um pouco complicado, mas na prática perceberá que o custo x benefício poderá valer a pena.

O formato

Os cenários aplicados em formato de tabela verdade facilitam a visualização do que precisaria ser validado.

Em um caso de teste convencional dividimos ações e resultados esperados, na tabela verdade de teste o conceito será o mesmo.

Eu divido a tabela verdade em 3 partes:

  • Massa de dados/Pré-Configurações: Será reunido tudo que preciso configurar ou preparar no ambiente de testes para executar minha ação. Esse pode ser um ponto que não é dada a devida atenção, no entanto, pode criar falsos positivos na execução dos testes. Levantar as configurações mínimas para uma determinada ação poderá evitar muita dor de cabeça no futuro. Isso porque uma falta de configuração pode deturpar o resultado esperado de sua ação. Dessa forma, poderá ser reportado um defeito equivocado devido a falta de  configuração ou perderá muito tempo até que chegue nessa conclusão, tempo precioso que muitas vezes não temos. É meu caro, testador também erra!
  • Ações: Assim como no caso de teste será descrito qual ação deverá ser realizada no sistema para validar determinada funcionalidade/cenário de teste.
  • Resultado Esperado: Para cada ação descrita será adicionado qual o resultado esperado para aquela ação.

O que é mais fácil de associar? Um passo a passo com muita informação ou algo mais enxuto?

Vamos mostrar um exemplo prático para facilitar o entendimento.

Exemplo

Imagine o caso de teste: Validar Cliente Cadastrado

O objetivo desse caso de teste é garantir a validação de uma parte da tela de cadastro de pedido de venda. Para fazer um cadastro de pedido de venda é necessário verificar se o cliente informado já está cadastrado no sistema, e só poderá concluir o cadastro do pedido para clientes cadastrados. Quais casos você validaria?

Levantei os seguintes cenários:

1) Cliente com tipo CPF já cadastrado – É esperado que os dados do cliente sejam retornados na tela.

2) Cliente com tipo CNPJ já cadastrado – É esperado que os dados do cliente sejam retornados na tela.

3) Cliente com tipo CPF NÃO cadastrado – É esperado que o cliente não seja encontrado – Cadastrar Cliente?

4) Cliente com tipo CNPJ NÃO cadastrado – É esperado que o cliente não seja encontrado – Cadastrar Cliente?

Transferindo essas validações para uma tabela verdade, teremos:

CasoTeste_TabelaVerdade

Veja que as configurações mínimas para executar o teste eu preciso de um usuário/senha para acessar o sistema e pessoas (física e jurídica), que são os clientes para executar minha ação, que é validar se o cliente está cadastrado.

Para cada tipo de Cliente é validado um cenário válido e inválido e o esperado é que mostre os dados do cliente quando cadastrado e quando não cadastrado o cliente não seja retornado.

Para o caso do cliente não cadastrado foi descrito “Cadastrar Cliente?” em forma de dúvida. Não constava nada sobre cadastrar o cliente que não existia nessa funcionalidade, poderia simplesmente não retornar nada. Tomo aqui a liberdade de chamar atenção para um ponto que muitos acabam pecando, a suposição. Sempre digo que não gosto de trabalhar com “achismos” precisamos ter certeza dos comportamentos esperados e não simplesmente supor que deveria ser dessa forma. Nos casos em que isso não está explicito no documento, validamos com o requisitos/P.O. do projeto com relação ao que é esperado para esse cenário. Assim, alinhamos a expectativa do comportamento do sistema e evitamos surpresas na entrega.

Mas voltando a tabela verdade, perceba que a ideia é desenhar essa tabela baseado nos campos chaves que utilizará na validação de cada cenário.

Outro ponto de atenção é que nesse formato existirão vários campos no formato S(Sim)/N(Não) ou V(Verdadeiro)/F(Falso) contemplando os cenários. Alguns campos poderão ser preenchidos de acordo com a base de dados, por exemplo, código do cliente ou fornecedor, me refiro aos campos pré-cadastrados que poderão ter variação de ambiente para ambiente. Nesse caso, poderá colocar algo genérico e o valor real poderá ser subsistido na execução.

Dificuldades

No começo poderá haver uma certa dificuldade em identificar em quais situações caberia utilizar uma tabela verdade e como começar.

E quanto a decisão de quais campos seriam colocados, qual melhor forma de colocar os cenários nessa matriz?

Bom, diria que para casos simples, validações de layouts, por exemplo, não seria necessário o desenho de uma tabela verdade. Nesse caso, seria mais custoso.

No entanto, para cenários mais complexos, por exemplo, validações que envolvem cálculos, cenários com varias possibilidades, já cairia muito bem em uma tabela verdade.

Quanto aos campos que serão colocados na tabela, uma dica seria levantá-los de acordo com os campos principais que validaria na tela tanto para input quanto output, seria um caminho para o começo da tabela verdade.

No entanto, conforme for utilizando mais no dia a dia essa prática, perceberá que a cada nova tabela verdade criada ela ficará melhor elaborada.

Benefícios

Alguns benefícios que poderiam ser listados em sua utilização são:

1) Facilitar a divisão dos cenários: Não só facilitar a divisão do cenários mas a visualização dos mesmos também. Simplifica o que é mais complexo.

2) Facilitar transformar os cenários em testes automáticos: tabelas verdade podem facilmente ser transformadas em testes automáticos, inclusive alguns deles a origem provem de tabelas. Escrever os casos dessa forma poderia já facilitar o processo de automação dos testes.

3) Facilitar a validação dos cenários: Principalmente na execução, nesse caso, como evidências de teste também. É muito mais fácil enxergar os cenários quando estão dispostos na tabela ao invés do formato convencional.

Conclusão

A utilização de tabelas verdades para os casos de testes mais complexos ou com muitas validações é uma boa alternativa para facilitar a construção e  organização dos seus testes.

Nessa estrutura, quanto a organização facilita tanto na escrita quanto na execução. Além disso, depois de estruturada, essa tabela ou planilha, poderá ser referenciada no caso de teste da ferramenta que utiliza.

Experimente aplicar em sua próxima sprint e me conte o que achou.

Referências

[1] http://diariosistema.blogspot.com.br/

Por ARIANE FERREIRA IZAC

Analista apaixonada por testes, dançarina, corredora e colecionadora de viagens! Filha de peixe (jornalista) peixinho (blogueira) é. Meu grupo no LinkedIn só poderia ser "Diário de uma paixão: Teste de Software"

Postado em: 22 de dezembro de 2016

Confira outros artigos do nosso blog

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Protractor – Testes automáticos end-to-end para aplicações em Angular

07 de dezembro de 2017

Jacqueline Costa

Testes em Node.js

04 de dezembro de 2017

Alan Cesar Elias

Deixe seu comentário