Ícone do site Prime Control

O que são cenários, scripts e casos de teste?

Se te pedissem para escrever um caso de teste, você saberia o que fazer? E um script de teste ou um cenário de teste? Vamos aprender o significado desses termos. Cada um se refere a algo que demanda um tipo de atenção e detalhe diferente. Quando os testadores aprendem o que eles significam, podem usá-los para descrever melhor a rotina de testes.

Diferenciando as 3 principais formas de documentação

Scripts de teste

É a forma mais detalhada de documentar um teste, o script. Quando os scripts de teste são mencionados, geralmente detalham linha por linha cada ação e dados necessários para rodar o teste. Um script tipicamente tem etapas que ajudam a entender como usar o programa, quais botões apertar e em qual ordem, como executar uma ação em particular no programa, etc. Esses scripts também incluem resultados específicos de cada etapa, como a verificação de uma mudança na interface. Em termos práticos, o exemplo seria:

Ação – Clique no botão X, Resultado – A janela fechou.

Quando um testador começa um novo trabalho, nem sempre ele sabe muito sobre o produto, a abrangência do negócio ou até mesmo sobre testes de software. Neste momento os scripts entram. Se o testador seguir cuidadosamente as instruções, inserir “abc”, clicar no botão de enviar, garantir que foi enviado e as informações salvas – essas instruções são uma boa base para entender a ideia de teste.

Existem alguns poréns a se considerar antes de dedicar muito tempo nos scripts detalhados. Os projetos de software ativos mudam constantemente, páginas são refeitas, a experiência do usuário muda e novas funcionalidades são adicionadas. Para ser mais produtivo com o tempo, os testadores precisam ter um esforço contínuo para atualizar os scripts. O problema disso é o tempo investido na atualização que poderia ser usado para rodar mais testes. Outro empecilho é que os scripts de testes são feitos para testar uma coisa específica repetidamente, fazendo uso dos mesmos caminhos e dados toda vez que o teste é executado. Isso significa que se tiver algum bug que não esteja no roteiro do script, ele não será encontrado, a não ser que o testador fuja do script. Testes com scripts não incentivam os testadores a serem criativos e nem habilidosos para encontrar bugs.

Casos de teste

A segunda forma mais detalhada de documentar o trabalho de um teste são os casos. Os casos de teste descrevem uma ideia específica a ser testada, sem detalhar os dados necessários e etapas exatas a serem executadas. Por exemplo, um caso de teste poderia ser “Testar se um código de desconto pode ser aplicado em um produto em promoção”. Isso não descreve quantos vão ser códigos ou como serão utilizados. A forma de testar este caso pode variar de tempos em tempos. O testador pode usar um link para aplicar o desconto, inserir um código, solicitar alguém do suporte ao consumidor para aplicar o desconto ou tentar outras formas criativas de encontrar o resultado. Os casos de teste proporcionam uma flexibilidade para os testadores decidirem de que forma eles pretendem completar o teste.

Esta flexibilidade dos casos é boa e ruim. Flexibilidade é benéfica quando o testador já é familiarizado com testes e com os detalhes do software que está sendo testado. Se o testador entendeu claramente o que já foi testado, o que foi modificado recentemente no programa e quantos usuários geralmente usam o programa, as estratégias de teste pode ser tanto usar os caminhos que os usuários normalmente usam ou formas mais inusitadas, para encontrar bugs escondidos.

Por outro lado, se os testadores não tiverem compreendido como o programa é usado, os riscos recentes e como avaliar esses riscos como um testador, eles podem não ter a informação ou habilidade necessária para realizar ações que podem encontrar bugs importantes.

Cenários de teste

O tipo menos detalhado de documentação é o cenário de teste. Um cenário de teste é uma descrição de um objetivo que o usuário pode encontrar ao utilizar o programa. Um exemplo seria “Testar se um usuário consegue deslogar do programa ao fechá-lo”. Tipicamente, um cenário de teste vai precisar de diferentes tipos de testes para garantir que o objetivo tenha sido bem testado. Utilizando o exemplo, o testador pode escolher fechar o programa pelo menu, fechá-lo pelo gerenciador de tarefas, desligar o computador ou como o programa reage quando fica sem memória e dá erro. Já que os cenários de testes oferecem pouca informação sobre como completar o teste, os testadores tem uma grande flexibilização para buscar uma solução.

Assim como os casos de teste, a flexibilidade dos cenários oferecem prós e contras similares. O conhecimento de causa e as habilidades em testes podem facilitar os testadores a transformar os cenários em ideias concretas, escolher a abordagem mais lógica e rodar os testes que podem extrair os problemas importantes. Este tipo de trabalho é um desafio para um testador habilidoso, mas pode ser difícil ou até mesmo impossível para um novato. Entretanto, se o novato estiver amparado em uma equipe, ele pode aprender o suficiente para conseguir.

E como escolher qual tipo usar?

A boa notícia é que não há necessidade de escolher apenas um. Os testadores fazem uso de todos, às vezes simultaneamente. Numa equipe, os testes serão divididos por habilidade e conhecimento. Tem alguma tarefa que precisa ser repetida regularmente e tem um testador disponível? Faça uso do script de teste. Uma ferramenta robusta como o TestComplete pode usar esses scripts para criar testes automatizados em vários dispositivos, plataformas e ambientes de forma rápida. Pensou em várias ideias que precisam ser testadas e tem um testador habilidoso disponível? Faça uso dos casos de teste. Agora, precisa pensar em ações mais abrangentes, tentar pensar em como o usuário vai agir? Crie alguns cenários de teste e coloque seus melhores testadores nesta tarefa. Todas essas formas de documentação são importantes, contanto que você entenda seus benefícios e limitações.

Featured image source and content reference:
https://blog.testlodge.com/writing-test-cases-from-user-stories-acceptance-criteria/

(Thanks to Steve Morgan and Brian Hamilton from TestLodge!)

Sair da versão mobile