Cenários de Testes e Casos de Testes: É realmente importante saber a diferença entre eles?

No meu entendimento, uma das etapas mais relevantes e importantes para a execução e avaliação do produto que está sendo desenvolvido. É nela que descreveremos para roteiros todo o nosso conhecimento sobre o negócio do nosso cliente e teremos a fonte de referência para todas as etapas de testes.

Há formas de organizá-los, de defini-los, de criá-los.

Podemos chamar de Cenários de Testes e de Casos de testes – e em geral já teremos aqui a primeira discussão.

Qual a diferença entre Cenários e Casos? Nem digo pela literatura de conceito, digo no dia a dia, na rotina de trabalho. Basicamente temos uma instrução/indicação conceitual de que Cenários de Testes definem “O que” deve ser testado, enquanto os Casos de Testes definem “Como” – no caso o que seriam as entradas a realizar no sistema e as saídas esperadas. Logo, para mim não faz muito sentido eu me preocupar se estou gerando um cenário ou um caso de teste, me importo se estou gerando os insumos necessários para a condução de um teste capaz de me mostrar o nível de qualidade da aplicação.

Depois deste parênteses, voltamos…

Em que momento você pode começar a escrever os cenários de testes? Você consegue escrevê-los só se tiver a tela pronta? Você depende dela estar ao menos com protótipo aprovado para criar novos cenários?

E a atualização destes cenários, você precisa fazer caso tenha qualquer alteração de layout? Se alterar labels de campos, cores, comportamentos de botões, você precisa atualizá-los?

Isto não gera muito trabalho? Tem que sempre correr atrás para manter atualizados né.

Vamos então ao que indico ser uma boa linha de organização, definição e criação, com objetivo prático para termos o entendimento mais efetivo sobre o negócio do cliente, suas necessidades e uma execução pragmática de testes que nos dê visibilidades mais claras sobre situação e qualidade do software.

Começarei por um direcionamento bem importante e que pode realmente fazer diferença no entendimento e em como tocar em frente as definições de cenários.

Separe: Negócio do cliente e Comportamento de Tela.

Não crie cenários de testes que sejam dependentes de como é o funcionamento de tela. Não indique em seus cenários de negócio que deve clicar no botão “x” que tem a label “x” e que no resultado esperado ele deve mudar de cor, por exemplo. Coloque esta validação em cenários de comportamento de telas, em documento de padrão visual, valide isto na usabilidade.

Saiba para quem você entregará esta aplicação

Quem é o seu cliente? Quem é o usuário do seu cliente?

Conheça-os, saiba o seu perfil, busque informações sobre suas características em relação ao uso de tecnologia, como é sua rotina.

Dinâmicas para isto? Existem algumas variedades, “Personas”, “Mapa da Empatia”, “Jornadas do Usuário”. Não as detalharei neste post, mas podemos vir a falar delas em um próximo.

Identifique os objetivos do cliente com a aplicação

Entenda os objetivos de negócio do cliente.

Liste-os! Importante para que fique claro o que ele espera, de maneira macro. Aqui teremos sua primeira visão sobre os Cenários, estará no primeiro nível.

Pegando um caso real de exemplo, vamos pensar em um sistema de e-commerce. Quais seriam os objetivos de negócio dele para o cliente?

• Encontrar produtos
• Efetivar uma compra
• Receber o produto

Já podemos considerar que temos ao menos 3(três) cenários para testes.

Agora já entramos em um momento que podemos começar a cruzar as informações, pois já conhecemos os clientes/usuários e temos os objetivos principais.

Necessidades para atender cada Objetivo

Identificar as necessidades dos clientes sobre cada um dos objetivos. Como por exemplo,

Encontrar produtos categorizados, por promoções, através de notificações e alertas, ou então efetivar compras com diferentes meios de pagamentos, optar por garantias estendidas ou embalagens para presente, ter opções de formas de entrega, como acompanhar o status de seu pedido e até mesmo cancelar sua compra.

Só entre estas ações que listamos sobre suas necessidades chegamos a um número de 9(nove) cenários.

Exemplo de Objetivos X Personas – Necessidades em cards amarelos

Já está aumentando o nosso conhecimento sobre o que devemos entregar ao cliente e o que devemos ter validado ao final do projeto.

Avance nos detalhes

Dê o próximo passo conforme o nível de profundidade necessário. Chegue ao limite de informação, que esteja no ponto em que a quebra não influencie mais diretamente no negócio, ao ponto que ela não mude sua regra.

Vamos pegar o caso das formas de pagamento para o exemplo.

Há como aprofundar mais nele com relação a negócio?

Podemos efetivar compras com opção de pagamento por boleto, por cartão de crédito, por débito em conta.

Posso ter uma opção de entrega do produto no mesmo dia da compra, mas esta só será possível ao escolher a opção de débito em conta.

Com este exemplo e avançando nos detalhes, já criamos mais 4 cenários possíveis.

Faça o exercício e quebre os cenários para as outras necessidades.

Utilize ferramentas de Mapas Mentais, elas também ajudam a visualizar a quebra de cenários de negócio.

Siga adiante

Combine os detalhes das necessidades levantadas e liste mais cenários. Neste último nível do detalhamento estarão os seus cenários de testes voltados a negócio.

Encontrar produto em promoção e efetivar uma compra incluindo embalagem de presente e pagando com cartão de crédito.

Ser notificado da disponibilidade de um produto que marquei como favorito e efetivar a compra com pagamento por débito em conta para ser entregue no mesmo dia.

Acaba por aqui?

Dependerá do nível de informações que quiser incluir nos seus artefatos de testes.

Se desejar ainda descrever um pouco mais, chegando no “Como”, utilize alguma técnica das elencadas a seguir para isto, mas se possível utilize elas com uma automação de testes, pois lhe ajudará bastante devido o reaproveitamento de código que realiza diversas vezes a mesma ação com valores diferentes.

• Especificação por Exemplos;
• Tabelas de Decisão e de Equivalência;
• Em linguagem natural, no estilo de BDD (Behavior Drive Development).

Exemplo de Tabela de Decisão

Cenário: Registrar e-mail para ser avisado quando produto estiver disponível

Dado que detalhei o produto encontrado na listagem

E o produto não está disponível

Quando pressionar a opção “Avise-me quando chegar”

E preencher o campo de e-mail

E clicar no botão “Registrar“

Então deve ser exibir mensagem “E-mail cadastrado com sucesso!“

Exemplo de Cenário no estilo BDD

Este é um formato de organização que contribuiu bastante durante os projetos que atuei, onde obtive um maior entendimento do negócio, conseguia avaliar melhor a criticidade dos bugs e reportá-los de forma mais clara e objetiva para correção. Entre os benefícios, consegui minimizar o retrabalho com atualização dos cenários de testes, pois eles não ficam dependentes do comportamento de tela, estes são mantidos e atualizados em scripts padrões que são realizados para validações de componentes e telas.

Acredito que seguirei escrevendo, alguns assuntos já apareceram ao escrever sobre este, na medida certa irei falar mais sobre:

• Scripts padrões de comportamentos de tela;
• Como organizar a automação para estes cenários e scripts;
• Definição de níveis de testes e visibilidade da execução dos testes;
• …

Até mais!