Desenvolver um software não é uma tarefa lá muito simples. Envolve entender bem o que precisa ser feito, o objetivo da coisa e até os pontos sensíveis da ideia. Mas uma vez que o código da aplicação está pronto, acabou. Certo? Bem… Uma parte importantíssima do processo de desenvolvimento de uma aplicação é testá-la e garantir que tudo está funcionando conforme o esperado.
Para quem está codando se torna muito fácil enxergar apenas o “caminho feliz” das funcionalidades desenvolvidas e deixar passar alguns bugs despercebidos no caminho.
O teste de software serve justamente para tentar encontrar e resolver (até prevenir) as falhas que um programa possa apresentar para que, quando estiver disponível para o público, o comportamento do sistema seja o mais correto possível.
Tipos de testes
Os testes podem ser estáticos ou dinâmicos. Um teste estático é feito quando o sistema não está em execução. Esses testes vão desde uma análise visual do código buscando variáveis ou classes declaradas incorretamente até a análise do código por um software terceiro que procura por diversos code smells, por exemplo.
Um teste dinâmico é aquele que precisa que o sistema esteja em execução para que seja testado, onde se envia uma entrada e se espera determinada saída; são testes que validam o funcionamento do sistema.
Assim como separamos o teste de acordo com o estado da aplicação, também podemos separá-los de acordo à disponibilidade de acesso ao código.
Testes de caixa aberta (ou caixa branca) são aqueles feitos quando temos acesso ao código fonte e testes de caixa fechada (ou caixa preta) quando não possuímos acesso.
Por fim, os testes podem ser manuais ou automatizados. Os testes manuais são mais flexíveis e podem explorar mais casos além dos que foram planejados, porém são mais lentos e possuem um alto custo de execução.
Em contraposto os testes automatizados são mais rápidos e de mais fácil execução, possuindo um alto custo de criação e validando apenas os cenários especificados.
Testes por nível
Um software pode possuir diversos testes que irão envolver níveis diferentes de seus componentes, indo desde pequenas unidades de código até o sistema como um todo. Esses testes são desenvolvidos em função do estágio do ciclo de vida do software e são feitos para validar o desempenho e comportamento do software em diferentes estágios.
Antes de falar continuar, vamos repassar brevemente quais são os estágios do ciclo de vida de um software. De forma bem simples, temos:
Os seguintes testes validam diferentes níveis do sistema e são feitos de acordo com o estágio do ciclo de vida:
• Teste de unidade: procuram falhas em um único componente do sistema, funcionando independente do todo. Geralmente é o primeiro teste feito durante o desenvolvimento do sistema. São escritos por programadores e executados de forma automatizada.
• Teste de integração: busca validar a comunicação entre componentes do sistema em uma etapa mais intermediária do desenvolvimento, quando já existem componentes que interagem entre si. Também são escritos por programadores e executados de forma automatizada.
💡 Exemplo: classe Assinatura gere o plano de assinatura de um cliente e ela interage com a classe Boleto, que é responsável por emitir o boleto daquela assinatura.
• Teste de sistema: executa o sistema sob ponto de vista do usuário final, buscando falhas em relação aos objetivos originais. Pode ser executado através do navegador, um client rest ou qualquer plataforma que o usuário irá usar. Costuma ser feito por uma equipe de testes após a conclusão do desenvolvimento e auxiliado por um documento descrevendo todos os cenários de testes correspondentes aos requisitos do sistema.
• Teste de aceitação: bastante similar ao teste anterior, o teste de aceitação também executa o sistema sob a ótica do usuário final visando confirmar se o objetivo original foi atingido, mas ao invés de serem realizados por uma equipe especializada são planejados e executados por um grupo restrito de usuários finais do sistema. Esse teste que determina se o cliente aceita ou não o sistema que foi desenvolvido.
💡 Enquanto no teste de sistema uma equipe especializada valida se os contratos (requisitos) foram cumpridos, no teste de aceitação o cliente valida o desenvolvimento e confirma se aceita ou não o resultado apresentado.
• Teste de manutenção: também chamado de teste de regressão, procura garantir que as alterações em um código não afetam outros componentes que foram desenvolvidos em etapas anteriores do ciclo de vida. Após uma correção de bug ou alteração de um escopo, por exemplo, esses testes validam se todos os componentes que já estavam prontos permaneceram com o comportamento adequado. Podem envolver qualquer nível do sistema (unitário, interface, o sistema como um todo, etc).
Se juntarmos os testes com o ciclo de vida do produto temos algo assim:
Essa sequência é um compilado das minhas anotações de estudos sobre testes de software baseados em diversas leituras e, principalmente, no curso Teste de Software disponível na Udemy. E como ainda temos muito pano pra manga sobre esse assunto, vou deixar mais um pouquinho pra uma parte 2.
Nos vemos logo mais!
Top comments (0)