Introdução ao Teste

Clique aqui para obter mais informações sobre Teste e Avaliação.

Finalidade
Relação com Outras Disciplinas

Conceitos

Finalidade

A disciplina Teste atua em vários aspectos como uma provedora de serviços para as outras disciplinas. O teste enfatiza principalmente a avaliação da qualidade do produto, realizada através de várias práticas centrais:

Localizar e documentar defeitos na qualidade do software.
Avisar de forma geral sobre a qualidade observada no software.
Validar as suposições feitas nas especificações de design e requisito através de demonstração concreta.
Validar as funções do software conforme projetadas.
Verificar se os requisitos foram implementados de forma adequada.

Uma diferença interessante entre o Teste e as outras disciplinas do RUP é que a principal finalidade do Teste é localizar e expor os pontos fracos do software. O interessante é que, para obter o máximo benefício, ele precisa de uma filosofia geral diferente da usada nas disciplinas Requisitos, Análise e Design, e Implementação. A diferença sutil é que enquanto as outras disciplinas enfatizam a abrangência, o Teste enfatiza a deficiência. Um bom esforço de teste é direcionado por perguntas do tipo "Como esse software pode ser dividido?" e "Em que situações este software pode deixar de funcionar da maneira prevista?". O teste desafia as suposições, os riscos e as incertezas inerentes ao trabalho de outras disciplinas, tratando essas questões por meio de uma demonstração concreta e uma avaliação imparcial. O desafio é evitar dois extremos potenciais: uma abordagem que não avalie o software de forma adequada e efetiva, expondo seus problemas e pontos fracos, e uma abordagem que seja inapropriadamente negativa ou destrutiva. Com a adoção de uma abordagem tão negativa, talvez você nunca considere aceitável a qualidade do software, e provavelmente alienará o esforço de Teste de outras disciplinas.

Com base nas informações apresentadas em várias pesquisas e ensaios, o teste de software é responsável por 30% a 50% dos custos totais de desenvolvimento do software. Portanto, talvez seja surpreendente notar que a maioria das pessoas acredita que o software não é bem testado antes de ser fornecido. Essa contradição baseia-se em algumas questões essenciais.

Primeiro, o teste de software é bastante difícil. Não é possível quantificar as diversas maneiras como um programa pode se comportar. Segundo, o teste é normalmente realizado sem uma metodologia clara e, portanto, os resultados variam de acordo com o projeto e a organização. O sucesso é um fator ligado principalmente à qualidade e às habilidades dos indivíduos. Terceiro, as ferramentas de produtividade são usadas de forma insuficiente, tornando gerenciáveis os aspectos trabalhosos do teste. Além da falta de execução de testes automatizados, vários esforços de teste são conduzidos sem ferramentas que permitam o gerenciamento eficaz de Dados de Teste e Resultados de Teste abrangentes. Enquanto a flexibilidade de uso e a complexidade do software tornam o teste completo uma meta impossível, uma metodologia bem-concebida e o uso de ferramentas avançadas podem ajudar a melhorar a produtividade e eficácia do teste de software.

Em sistemas de "segurança crítica", nos quais uma falha pode causar danos a pessoas (como, por exemplo, controle do tráfego aéreo, direção de mísseis ou sistemas de assistência médica), um software de alta qualidade é essencial para o sucesso desses sistemas. Em um sistema MIS típico, seu grau de risco pode não ser imediatamente óbvio, mas é provável que o impacto de um defeito possa acarretar ao negócio que utiliza o software uma despesa considerável, devido a perda de receita ou possíveis custos legais. Nesta "era da informação", com o aumento da demanda por serviços eletrônicos pela Internet, vários sistemas MIS são agora considerados como de "missão crítica"; ou seja, as empresas não podem realizar as suas funções e sofrem grandes prejuízos com a ocorrência de falhas.

Uma abordagem contínua da qualidade, realizada no início do ciclo de vida do software, pode diminuir significativamente o custo de conclusão e manutenção do software. Isso reduz bastante o risco associado à implantação de software de má qualidade.

Relação com Outras Disciplinas

A disciplina Teste relaciona-se a outras disciplinas.

A disciplina Requisitos captura os requisitos do software, que representam uma das bases principais para a identificação dos testes que devem ser executados.
A disciplina Análise e Design determina o design adequado para o software. Essa é outra base importante para a identificação dos testes que devem ser executados.
A disciplina Implementação produz builds do software que são validados pela disciplina Teste. Em uma iteração, vários builds são testados, geralmente um por ciclo de teste.
A disciplina Ambiente desenvolve e mantém os artefatos de suporte usados durante o teste, como o Guia de Teste e o Ambiente de Teste.
A disciplina Gerenciamento planeja o projeto e o trabalho necessário em cada iteração. Descrito em um Plano de Iteração, esse artefato é uma base importante para definir a missão de avaliação correta para o esforço de teste.
A disciplina Gerenciamento de Configuração e Mudança controla a mudança dentro da equipe de projeto. O esforço de teste verifica se cada mudança foi efetuada corretamente.

Rational Unified Process