Determine o que testar, defina seus casos de teste e priorize.
No post anterior, você aprendeu sobre estratégias de teste, o número de testes necessários para testar um aplicativo e como encontrar o melhor ajuste para ter mais confiança nos resultados, considerando seus recursos. No entanto, isso só nos dá uma ideia de quanto testar. Você ainda precisa determinar exatamente o que testar. Os três critérios a seguir podem ser úteis para entender o que esperar de um teste e saber qual tipo de teste e nível de detalhes são mais adequados:
- Cuide do seu caminho ideal. Essa é a história de usuário mais genérica ou principal do seu aplicativo, em que o usuário percebe um erro muito rapidamente.
- Decidir com cuidado o nível de detalhamento. Entre em mais detalhes se o caso de uso for vulnerável ou se um erro causar grandes danos.
- Priorize testes de nível inferior, como testes de unidade e integração, em vez de testes de ponta a ponta de nível superior sempre que possível.
O restante deste artigo aborda esses critérios e como eles se aplicam à definição de casos de teste.
O que é um caso de teste?
No desenvolvimento de software, um caso de teste é uma sequência de ações ou circunstâncias criadas para confirmar a eficácia de um programa ou aplicativo de software. O objetivo de um caso de teste é garantir que o software funcione conforme o planejado e que todos os recursos e funções funcionem corretamente. Testadores ou desenvolvedores de software geralmente criam esses casos de teste para garantir que o software atenda aos requisitos e especificações especificados.
Quando um caso de teste é executado, o software realiza uma série de verificações para garantir que produza os resultados desejados. Ao fazer isso, um teste cumpre as seguintes tarefas:
- Verificação. O processo de verificar minuciosamente um software para garantir que ele funcione sem erros. Determinar se o produto criado atende a todos os requisitos não funcionais necessários e alcança o objetivo pretendido é crucial. A pergunta que ele responde é: "Estamos criando o produto certo?"
- Validação. O processo de garantir que o produto de software atenda aos padrões necessários ou aos requisitos de alto nível. Isso envolve verificar se o produto real está alinhado com o esperado. Basicamente, estamos respondendo à pergunta: "Estamos criando o produto certo para os requisitos do usuário?"
Suponha que o programa não consiga entregar o resultado esperado. Nesse caso, o caso de teste será o mensageiro, ou seja, vai informar um resultado infrutífero, e o desenvolvedor ou testador terá que investigar o problema e encontrar uma solução. Pense nas verificações e ações como caminhos que o computador segue, independentemente do tipo de teste. Grupos de dados de entrada ou condições usados para a verificação são chamados de "classes de equivalência". Eles precisam ter um comportamento ou resultados semelhantes do sistema em teste. Os caminhos específicos executados em um teste podem variar, mas precisam corresponder às atividades e às declarações feitas no teste.
Caminhos de teste: tipos comuns de casos de teste
No desenvolvimento de software, um caso de teste é um cenário de execução de código em que um determinado comportamento é esperado e testado. Normalmente, há três cenários para formar casos de teste.
O primeiro é o mais conhecido, que você provavelmente já está usando. É o cenário ideal, também conhecido como "cenário ideal" ou "cenário ideal". Ele define o caso de uso mais comum do seu recurso, aplicativo ou mudança, ou seja, como ele deve funcionar para o cliente.
O segundo caminho de teste mais importante a ser coberto nos casos de teste geralmente é deixado de fora porque é desconfortável, como o nome pode sugerir. É o "caminho assustador" ou, em outras palavras, o teste negativo. Esse caminho é destinado a cenários que causam um comportamento incorreto do código ou que o fazem entrar em um estado de erro. Testar esses cenários é especialmente importante se você tiver casos de uso altamente vulneráveis que impõem um alto risco às partes interessadas ou aos usuários.
Há outros caminhos que você pode conhecer e considerar usar, mas geralmente eles são menos usados. A tabela a seguir resume essas informações:
| Caminho de teste | Explicação |
|---|---|
| Caminho de raiva | Isso leva a um erro, mas um esperado. Por exemplo, se você quiser garantir que o tratamento de erros funcione corretamente. |
| Caminho de inadimplência | Esse caminho cuida de todos os cenários relacionados à segurança que seu aplicativo precisa atender. |
| Caminho desolado | O caminho que testa o cenário no seu app não recebe dados suficientes para funcionar, por exemplo, ao testar valores nulos. |
| Caminho esquecido | Testar o comportamento do aplicativo com recursos insuficientes, por exemplo, causando uma perda de dados. |
| Caminho indeciso | Testar com um usuário que está tentando realizar ações ou seguir histórias de usuário no seu aplicativo, mas não concluiu esses fluxos de trabalho. Isso pode acontecer, por exemplo, quando o usuário interrompe o fluxo de trabalho. |
| Caminho ganancioso | Tentar testar usando grandes quantidades de entradas ou dados. |
| Caminho estressante | Tentar sobrecarregar o aplicativo de qualquer maneira até que ele pare de funcionar (semelhante a um teste de carga). |
Há vários métodos para categorizar esses caminhos. Duas abordagens comuns são:
- Particionamento de equivalência. Um método de teste que categoriza casos de teste em grupos ou partições e, como resultado, ajuda a criar classes de equivalência. Isso se baseia na ideia de que, se um caso de teste em uma partição revela um defeito, outros casos de teste na mesma partição provavelmente revelarão defeitos semelhantes. Como todas as entradas em uma classe de equivalência específica precisam apresentar um comportamento idêntico, é possível diminuir o número de casos de teste. Saiba mais sobre a partição de equivalência.
- Análise de limite. Um método de teste, também conhecido como análise de valor de limite, que examina os limites ou extremos dos valores de entrada para encontrar possíveis problemas ou erros que possam surgir nos limites de recursos ou restrições do sistema.
Prática recomendada: escrever casos de teste
Um caso de teste clássico escrito por um testador vai conter dados específicos para ajudar você a entender o conteúdo do teste que você quer realizar e, claro, executar o teste. Um testador típico documentaria os esforços de teste em uma tabela. Há dois padrões que podemos usar nessa fase para estruturar nossos casos de teste e, mais tarde, os próprios testes:
- Padrão organizar, agir, afirmar. O padrão de teste "organizar, agir, afirmar" (também conhecido como "AAA" ou "Triple A") é uma maneira de organizar testes em três etapas distintas: organizar o teste, realizar o teste e, por último, tirar conclusões.
- Padrão considerando, quando, então. Esse padrão é semelhante ao AAA, mas tem algumas raízes no desenvolvimento orientado a comportamento.
Os próximos artigos vão abordar esses padrões com mais detalhes, assim que abordarmos a estrutura de um teste. Se você quiser se aprofundar nesses padrões nesta fase, confira estes dois artigos: Arrange-Act-Assert: um padrão para escrever bons testes e Given-When-Then.
De acordo com todas as lições deste artigo, a tabela a seguir resume um exemplo clássico:
| Informações | Explicação |
|---|---|
| Pré-requisitos | Tudo o que precisa ser feito antes de escrever o teste. |
| Objeto em teste | O que precisa ser verificado? |
| Dados de entrada | Variáveis e valores. |
| Etapas a serem executadas | Todas as ações ou interações que você vai realizar nos testes. |
| Resultado esperado | O que deve acontecer e quais expectativas devem ser atendidas. |
| Resultado real | O que realmente acontece. |
Nos testes automatizados, você não precisa documentar todos esses casos de teste da mesma forma que um testador precisa, embora seja sem dúvida útil fazer isso. Você pode encontrar todas essas informações no teste se prestar atenção. Vamos transformar este caso de teste clássico em um teste automatizado.
| Informações | Tradução para automação de testes |
|---|---|
| Pré-requisitos | Tudo o que você precisa, organizando o teste e pensando no que é necessário para que o cenário do teste aconteça. |
| Objeto em teste | Esse "objeto" pode ser várias coisas: um aplicativo, fluxo, unidade ou componente em teste. |
| Dados de entrada | Valores de parâmetro. |
| Etapas a serem executadas | Todas as ações e comandos executados no teste, as coisas em que você age e o que acontece quando você faz certas coisas. |
| Resultado esperado | A declaração que você usa para validar seu aplicativo, as coisas que você declara no seu aplicativo. |
| Resultado real | O resultado do teste automatizado. |