Tipos de Testes de Software: quais devo fazer?

No universo do Teste de Software, a pergunta que fica é: “Devemos fazer todos os tipos de testes?” – A qualidade do software não é medida pela quantidade de testes que fazemos, e sim como são executados os testes.

Existem diversos testes que podemos fazer, mas devemos prestar atenção em qual usar e em que momento. Precisamos realizar os testes de acordo com a necessidade do projeto.

Tipos de teste de software

Os testes listados são, na minha opinião, os que sempre devemos fazer no software.

Teste Unitário ou Teste de Unidade

É focado em validar as menores partes do software. Validar se está atendendo ao que foi solicitado no projeto. Esse teste geralmente é realizado pelo desenvolvedor, por ter acesso ao código. Nesse teste será validado as entradas e a saídas (Input e Output) de dados (Ex: testar se o sistema está gerando o arquivo XLS de uma tabela, o desenvolvedor iria simular a entrada de dados e a saída).

Teste de Integração

Finalizado os testes de unidade, o teste de integração valida possíveis falhas após fazer a integração das unidades. Muitas vezes após a integração ser feita o sistema pode apresentar incompatibilidades, isso pode acontecer mesmo com as unidades terem passado no teste de unidade (Seguindo o mesmo exemplo já dado, o teste de integração irá validar a inserção de dados na interface e a geração do XLS. O teste valida se os dados inseridos estão sendo gerados no arquivo corretamente).

Teste de Regressão

Consiste no teste de cada nova modificação ou nova versão do software, é destinado a garantir que novos defeitos não venham a surgir em componente já analisados (Ex: O desenvolvedor atualiza a tabela adicionando mais uma coluna. Após essa atualização, o desenvolvedor valida se ela não irá gerar inconsistência no sistema, ocasionando a não geração do arquivo XLS).

Teste de Sistema

É aqui que a equipe de teste entra, validando o software como um todo. A versão que a equipe de teste irá usar é chamada de “Homologação”, é quando toda a construção, tanto Front quanto Back, já estão prontos. Lembrando que não é a versão final que será entregue para o cliente, pois depois dos testes poderá haver ajustes a serem feitos.

Teste de Aceitação

Esse teste é feito antes do software estar disponível, é destinado a verificar se o sistema atenderá as necessidades do usuário. Normalmente é o cliente realiza esse teste.

Teste de Usabilidade

Focada na experiência do usuário, o teste de usabilidade tem por finalidade conferir se as funcionalidades do sistema estão intuitivas e se o sistema é fácil de usar.

Antes de citar outros testes, existe um teste que é indispensável para o software: é o teste de segurança. Aí você me pergunta: “Poxa vida Bruno por que você não falou sobre teste de segurança lá em cima?”. Calma jovem Padawan, o teste de segurança é tão complexo que preciso dedicar um artigo somente para ele, e não quero deixar nada de fora.

Quais outros testes podemos fazer?

Muitos dos testes que existem são situacionais, e depende do que o software irá precisar.

Teste de Performance: é um teste destinado a validar o desempenho do software. Valida se os comandos dados respondem rapidamente.

Teste de Estabilidade: tem em vista o dia a dia do usuário. Focado em garantir que após o lançamento o software não terá perda de performance.

Teste de Stress: coloca o software no seu extremo, valida quantos usuários a aplicação irá aguentar simultaneamente.

Teste de Carga: verifica o desempenho do sistema quando está submetido a cargas variáveis ou transações, ou seja, verifica o limite de dados que o software pode processar.

Lembre-se jovem Padawan, que todos os testes citados nesse artigo são os que considero mais importantes e os que mais utilizamos aqui na Bitzen.

Sempre tenha em mente: “Não é a quantidade de testes que vai garantir a qualidade do software, mas sim a forma que executamos”.

Bruno Takano

Formando em Análise e Desenvolvimento de Sistema | Trabalha como Analista de Teste/QA na Bitzen Tecnologia.

Deixe um comentário

Your email address will not be published.