Introdução ao teste de software

O que é testar?

Encontramos na literatura algumas definições sobre o que é a atividade de testar:

“Testar é analisar um programa com a intenção de descobrir erros e defeitos.” (Myers)
“Testar é exercitar ou simular a operação de um programa ou sistema. ”
“Testar é confiar que um sistema faz o que se espera que ele faça e não faz o que se espera que não faça. ”
“Testar é medir a qualidade e funcionalidade de um sistema. ”
“O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)

Objetivo dos testes

O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente estão sendo atendidas.

Erro, Defeito e Falha

• Erro (error): é uma ação humana que produz um resultado incorreto.

• Defeito (fault): A manifestação de um erro no software.
  • Também conhecido como Bug;
  • Se executado, o defeito pode causar uma falha.

• Falha (failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado)

Falha é um evento. Defeito é um estado do software, causado por um erro.

Por que defeitos ocorrem no software?

• Softwares são escritos por humanos;
• As pessoas não conhecem e não dominam tudo;
• As pessoas têm habilidades, mas não são perfeitas;
• As pessoas cometem erros;
• Tempo de desenvolvimento curto;
• Sem tempo para checar as atividades realizadas;
• Sistemas podem estar incompletos.

O custo da falta de qualidade e da correção de defeitos

Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manutenção de software, entre R$ 2,00 e R$ 3,00 são gastos com retrabalho.

• Talvez o software ou parte dele precise ser refeito, o que aumenta ainda mais os custos;
• Não se sabe, através de métricas claras e precisas, quais são as principais áreas de produção que geram retrabalho.

Existem alguns tipos de sistemas onde:

• As falhas causam prejuízos diretos, ou
• As falhas causam a perda de confiança do público (clientes e usuários).

A Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.

Por que testar é necessário?

• Porque é provável que o software possua defeitos;
• Para descobrir a confiabilidade do software;
• Porque falhas podem custar muito caro;
• Para demonstrar as conformidades com os requisitos;
• Para assegurar que as necessidades dos usuários estejam sendo atendidas;
• Para reduzir custos;
• Para avaliar a qualidade do software.

Não devemos testar

• Para provar que o software não tem defeitos;
• Apenas porque os testes estão incluídos no plano de projeto.

Mitos sobre o teste de software

O testador é inimigo do desenvolvedor.

• Todos fazem parte da mesma equipe e trabalham para o sucesso dos projetos. O papel do testador não é apontar erros do desenvolvedor e sim trabalhar em conjunto para agregar qualidade ao produto final.
• Os desenvolvedores jamais devem levar o cadastro de bugs de uma tarefa que desenvolveu como algo pessoal, assim como os testadores devem entender quando a equipe não priorizar um ou mais bugs que tenha encontrado.

A equipe de testes pode ser formada pelos desenvolvedores menos qualificados.

• Uma equipe de testes necessita de pessoas que conheçam os sistemas, técnicas de teste, conhecimento em diversos tipos de teste, além de competências como atenção, olhar crítico, organização, etc.

*Quando estiver tudo pronto, o sistema vai para teste.

• O ideal é que o teste seja envolvido mais cedo no processo de desenvolvimento. Quando antes os testes forem realizados, mais cedo os problemas serão encontrados e resolvidos.

Teste de software não exige muito intelectualmente.

• Se há apenas repetições de ações predefinidas, teste realmente pode não exigir muito do testador nesse aspecto. Mas é importante pensar em testes como uma forma de explorar, coletar informações e encontrar respostas a coisas que ainda não foram questionadas. E para alcançar esse nível de detalhamento é preciso pensar, observar e analisar muito o sistema a ser testado.

Se o software foi testado, então não pode ter bugs.

• Este é um dos mitos mais comuns entre clientes e gestores de projetos. Ninguém pode afirmar com absoluta certeza que um software está 100% livre de bugs, mesmo que tenha sido testado por um testador com capacidades magníficas.

Os testadores são os únicos responsáveis pela qualidade do produto.

• É uma atitude muito comum pensar que apenas os testadores (ou a equipe de testes) são responsáveis pela qualidade do produto. As responsabilidades dos testadores incluem a detecção de bugs para os responsáveis pelo projeto, e são os responsáveis que decidem se efetuam correções ou se dão o software como concluído.
• A qualidade do produto é um dever de todos os integrantes da equipe de desenvolvimento, e não apenas do testador.

Tipos de testes

Testes de segurança

A principal meta do teste de segurança é garantir que os dados ou funções de um sistema possam ser acessados apenas por atores autorizados a acessá-los. Todas as formas de ataque de acesso indevido devem ser simuladas.

Objetivos:

• Garantir que os dados do sistema estão protegidos adequadamente;
• Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados;
• Analisar as ameaças e vulnerabilidades, tanto físicas como lógicas;
• Assegurar que os mecanismos de controle contra acessos indevidos foram corretamente implementados.

Quando usar:

• Testes básicos de segurança devem ser aplicados a todos os softwares;
• Quando a informação que circula através do software for de importância fundamental para a organização.

Testes de performance

O teste de performance, ou de desempenho como também é conhecido, mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo de resposta do sistema.

Objetivos:

• Determinar o tempo de resposta das transações;
• Verificar se os critérios de desempenho estabelecidos estão sendo atendidos;
• Identificar pontos de gargalo no sistema;
• Verificar o nível de utilização do hardware e software.

Quando usar:

• Quando se deseja avaliar o tempo de resposta de uma funcionalidade do sistema ou de todo o sistema;
• Devem ser realizados quando ainda há tempo hábil de serem realizadas correções.

Testes funcionais baseados em requisitos

O teste funcional baseado em requisitos tem por meta verificar se o software executa corretamente suas funções, se a implementação das regras de negócio foi apropriada e se o sistema é capaz de sustentar sua correta execução por um período contínuo de uso.

Objetivos:

• Assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta;
• Verificar se os requisitos dos usuários estão implementados;
• Verificar se o sistema funciona corretamente após um período contínuo de utilização.

Quando usar:

• Qualquer sistema deve ter suas funcionalidades testadas;
• Pode ser usado desde a fase de especificação de requisitos até a fase de operação do sistema.

Teste de usabilidade

O teste de usabilidade verifica a facilidade que o software possui de ser claramente entendido e facilmente operado pelos usuários.

Objetivos:

• Verificar a facilidade de operação do sistema pelo usuário;
• Verificar a facilidade de entendimento das funções do sistema pelo usuário, através da utilização de manuais, on-line help, agentes e assistentes eletrônicos, etc.

Quando usar:

• Quando se deseja avaliar a complexidade de entendimento das telas e o fluxo de informação;
• Pode ser executado em conjunto com outros testes (funcionalidade, acessibilidade).