2.1 – Tipos
Os tipos de testes definem o que será testado no sistema e estes estão divididos de acordo com seu objetivo particular. Podemos destacar os seguintes tipos:
| TIPO DE TESTE | OBJETIVO |
|---|---|
| Teste de Requisitos | É um teste caixa preta que verifica se o sistema é executado conforme o que foi especificado. São realizados através da criação de condições de testes e cheklists de funcionalidades. |
| Teste de Regressão | é um teste caixa preta que testa se algo mudou em relação ao que já estava funcionando corretamente, ou seja, é voltar a testar segmentos já testados após uma mudança em outra parte do software. Os testes de regressão devem ser feitos tanto no software quanto na documentação. |
| Teste de Tratamento de Erros | é um teste caixa preta que determina a capacidade do software de tratar transações incorretas. Esse tipo de teste requer que o testador pense negativamente e conduza testes como: entrar com dados cadastrais impróprios, tais como preços, salários, etc., para determinar o comportamento do software na gestão desses erros. Produzir um conjunto de transações contendo erros e introduzi-los no sistema para determinar se este administra os problemas. |
| Teste de Suporte Manual | É um teste caixa preta que verifica se os procedimentos de suporte manual estão documentados e completos. Verifica e determina se as responsabilidades pelo suporte manual foram estabelecidas. |
| Teste de Interconexão | É um teste caixa preta que garante que a interconexão entre os softwares de aplicação funcione corretamente, pois, softwares de aplicação costumam estar conectados com outros softwares de mesmo tipo. |
| Teste de Controle | É um teste caixa preta que assegura que o processamento seja realizado conforme sua intenção. Entre os controles estão a validação de dados, a integridade dos arquivos, as trilhas de auditoria, o backup e a recuperação, a documentação, entre outros. |
| Teste Paralelo | É um teste caixa preta que compara os resultados do sistema atual com a versão anterior determinando se os resultados do novo sistema são consistentes com o processamento do antigo sistema ou da antiga versão. O teste paralelo exige que os mesmos dados de entrada rodem em duas versões da mesma aplicação. Por exemplo: caso a versão mude e os requisitos não, os dados de saída das duas versões devem ser iguais. |
| Teste de Execução | é um teste caixa branca que verifica os tempos de resposta, de processamento e o desempenho (performance), avaliando o comportamento do software no ambiente de produção e verificando se as premissas de desempenho são atendidas. Em um sistema que possui dez módulos diferentes e que foi desenvolvido por equipes diferentes, o teste de execução avalia o sistema como um todo, é como se o teste de execução fosse um “play” no sistema. |
| Teste de Estresse | é um teste caixa branca que avalia o comportamento do software sob condições críticas, tais como restrições significativas de memória, espaço em disco, etc., ou seja, coloca o software sob condições mínimas de operação. |
| Teste de Recuperação | é um teste caixa branca que a recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação como, por exemplo: Ao desligar o computador, queda de energia elétrica, entre outros. O teste de recuperação garante a continuidade das operações após um desastre. |
| Teste de Operação | É um teste caixa branca que avalia o processo e sua execução, desenhado para estabelecer se o sistema é executável durante a operação normal. É um tipo de teste muito específico, depende do software a ser testado um exemplo é o software de “Call Center”. |
| Teste de Conformidade | é um teste caixa branca que verifica se o software foi desenvolvido de acordo com padrões, normas, procedimentos e guias de TI. |
| Teste de Segurança | é um teste caixa branca que avalia a adequação dos procedimentos de proteção e as contra medidas projetadas, para garantir a confidencialidade das informações e a proteção dos dados contra o acesso não autorizado de terceiros. |
Muitos outros tipos de testes são aceitáveis, contudo é fundamental ter em mente os requisitos funcionais e não funcionais (garantia e utilidade) do negócio, para definir exatamente o nível de testes que se pretende estabelecer para uma determinada aplicação. Testar demais é tão ineficiente quanto testar pouco.