Determine o que testar, defina os casos de teste e priorize.
Na postagem 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, tendo em mente seus recursos. No entanto, isso apenas nos dá uma ideia do 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 para ver qual tipo e nível de detalhamento se encaixa melhor:
- Cuide do seu caminho da felicidade. Esta é a história de usuário mais genérica ou principal do seu aplicativo, na qual o usuário perceberá um erro rapidamente.
- Defina com cuidado o nível de detalhes. Entre em mais detalhes se o seu caso de uso for vulnerável ou em que um erro causaria muitos danos.
- Sempre que possível, priorize testes de nível inferior, como testes de unidade e integração, em vez de testes de ponta a ponta de nível mais alto.
O restante deste artigo explora esses critérios e como eles se aplicam à medida que você define 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 planejadas para confirmar a eficácia de um programa ou aplicativo de software. Um caso de teste visa garantir que o software opere conforme planejado e que todos os seus recursos e funções tenham o desempenho correto. Os testadores ou desenvolvedores de software geralmente criam esses casos de teste para garantir que o software atenda aos requisitos e às especificações especificados.
Quando um caso de teste é executado, o software realiza uma série de verificações para garantir que produz os resultados desejados. Ao fazer isso, um teste realiza as seguintes tarefas:
- Verificação. O processo de verificação cuidadosa do software para garantir que ele funcione sem erros. É essencial determinar se o produto criado atende a todos os requisitos não funcionais necessários e se ele atinge a finalidade pretendida. A pergunta é: “Estamos construindo o produto certo?”
- Validação. Processo de garantir que o produto de software atenda aos padrões necessários ou aos requisitos de alto nível. Ela envolve verificar se o produto real está alinhado ao esperado. Essencialmente, estamos respondendo à pergunta: “Estamos criando o produto certo para os requisitos do usuário?”
Suponha que o programa não entregue o resultado esperado. Nesse caso, o caso de teste será o mensageiro, ou seja, relatando um resultado insatisfatório, e o desenvolvedor ou testador precisará 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 verificação são chamados de "classes de equivalência". Eles devem ter um comportamento ou resultados semelhantes do sistema em teste. Os caminhos específicos executados dentro de um teste podem variar, mas precisam corresponder às atividades e declarações feitas no teste.
Caminhos de teste: tipos típicos 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 se basear nos casos de teste.
A primeira é a mais conhecida, que você provavelmente já está usando. É o caminho da felicidade, também conhecido como "cenário do feliz dia" ou "caminho dourado". Ele define o caso de uso mais comum de um recurso, aplicativo ou mudança, a forma como deve funcionar para o cliente.
O segundo caminho de teste mais importante a ser abordado nos casos de teste costuma ser deixado de fora por ser desconfortável, como o nome sugere. É o "caminho assustador" ou, em outras palavras, o teste negativo. Esse caminho segmenta cenários que causam um comportamento inadequado ou um estado de erro no código. Testar esses cenários é especialmente importante se você tiver casos de uso altamente vulneráveis que imponham um alto risco às partes interessadas ou aos usuários.
Existem outros caminhos que você pode conhecer e considerar usar, mas eles costumam ser menos usados. A tabela a seguir resume essas etapas:
| Caminho de teste | Explicação |
|---|---|
| Caminho frenético | Isso resulta em um erro, mas esperado. Por exemplo, se você quer garantir que o tratamento de erros funcione corretamente. |
| Caminho inadimplente | Esse caminho cuida de qualquer cenário relacionado à segurança que seu aplicativo precise atender. |
| Desolar caminho | o caminho que testa o cenário no aplicativo 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, acionando uma perda de dados. |
| Caminho indeciso | Teste com um usuário que está tentando realizar ações ou seguindo histórias de usuários 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 Greedy | Tentar testar usando grandes quantidades de entradas ou dados. |
| Caminho estressante | Tentar sobrecarregar o aplicativo por qualquer meio necessário até ele parar 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 é baseado 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 devem exibir um comportamento idêntico, é possível diminuir o número de casos de teste. Saiba mais sobre o particionamento 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: como criar casos de teste
Um caso de teste clássico escrito por um testador contém dados específicos para ajudar você a compreender o conteúdo do teste que deseja realizar e, é claro, executá-lo. Um testador típico documentaria seus esforços de teste em uma tabela. Há dois padrões que podemos usar neste estágio, que nos ajudam a estruturar nossos casos de teste e, posteriormente, nossos testes em si também:
- Padrão organizar, agir, declarar. O padrão de teste “organizar, agir, declarar” (também conhecido como “AAA” ou “Triplo A”) é uma maneira de organizar testes em três etapas distintas: organizar o teste, realizar o teste e, por último, mas não menos importante, tirar conclusões.
- Padrão dado, quando, então. Esse padrão é semelhante ao AAA, mas tem algumas raízes no desenvolvimento orientado por comportamento.
Os próximos artigos entrarão em mais detalhes sobre esses padrões, assim que abordarmos a estrutura de um teste em si. Se você quiser se aprofundar nesses padrões nesta etapa, confira estes dois artigos: Arrange-Act-Assert: A pattern for write Good Tests e Given-When-then (em inglês).
De acordo com todos os aprendizados deste artigo, a tabela a seguir resume um exemplo clássico:
| Informações | Explicação |
|---|---|
| Pré-requisitos | Tudo o que precisa ser feito antes da criação do teste. |
| Objeto em teste | O que precisa ser verificado? |
| Dados de entrada | Variáveis e seus valores. |
| Etapas a serem executadas | Tudo o que você fará para dar vida ao seu teste: todas as ações ou interações realizadas 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 maneira que um testador precisa, mesmo que seja sem dúvida útil. É possível encontrar todas essas informações no seu teste se você prestar atenção. Então, vamos converter esse caso de teste clássico em um teste automatizado.
| Informações | Tradução em automação de teste |
|---|---|
| Pré-requisitos | Tudo o que você precisa, organizando o teste e pensando sobre o que é dado para fazer o cenário do teste acontecer. |
| Objeto em teste | Esse "objeto" pode ser várias coisas: um aplicativo, um fluxo, uma unidade ou um componente em teste. |
| Dados de entrada | Valores de parâmetros. |
| Etapas a serem executadas | Todas as ações e comandos executados dentro do teste, as coisas em que você atua e descobrir o que acontece quando você faz determinadas coisas. |
| Resultado esperado | A declaração que você usa para validar seu aplicativo, as coisas que você declara no seu aplicativo. |
| Resultado real | Resultado do teste automatizado. |