Artigo Engenharia de Software 3 - Gestão de Testes
Artigo da Revista Engenharia de Software edição 3.
Esse artigo faz parte da revista Engenharia de Software 3 edição especial. Clique aqui para ler todos os artigos desta edição
Verificação, Validação e Teste<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Estima-se que o custo decorrente da correção de um bug cresce bastante à medida que ele é descoberto em fases mais avançadas no processo de desenvolvimento de software. No entanto, ainda existe uma forte tendência nas empresas em negligenciar essa realidade e não dedicar o tempo mínimo necessário para a realização das atividades de teste de software.
As atividades de teste são muitas vezes realizadas de maneira pouco estruturada ao final do projeto, quando não existe mais solução para os problemas. Segundo Pressman, a atividade de teste seria um dos elementos críticos da garantia da qualidade de software e pode assumir até 40% do esforço gasto em seu desenvolvimento.
A qualidade é um atributo do software que deve ser introduzida ao longo do processo de desenvolvimento do software, haja vista que ela não pode ser imposta depois que o produto tenha sido finalizado.
Glenford Myers, no seu livro "The Art of Software Testing", destaca que teste de software é o processo de executar um sistema com o objetivo de revelar falhas. No entanto, as atividades de teste de software não se resumem apenas a isso. Teste de software é uma atividade estruturada e sistemática baseada em técnicas, ferramentas e processos formais, como veremos ao longo deste artigo.
A validação e verificação são atividades de apoio de um processo de garantia de qualidade de software. A motivação principal dessas atividades é prevenir e detectar os defeitos e minimizar os riscos do projeto.
Os defeitos podem ser introduzidos ao longo do processo de desenvolvimento do software. É necessário que eles sejam identificados o quanto antes dentro do processo de desenvolvimento, de preferência na própria fase onde foram inseridos, mas nem sempre isso acontece.
As atividades de validação e verificação são baseadas em técnicas de análise estática ou dinâmica dos artefatos (documentos, código fonte, código executável, etc) com o intuito de detectar os defeitos ou revelar falhas na própria fase onde eles foram inseridos ou em fases posteriores.
A verificação tem o objetivo de avaliar se o software está sendo desenvolvido conforme os padrões e metodologia estabelecidos no projeto. A verificação normalmente é realizada por meio da análise estática (revisões, inspeções, etc) dos artefatos (documentos, código fonte, etc) produzidos ao longo do processo de desenvolvimento do software.
A validação, por outro lado, tem o objetivo de avaliar a aderência, ou conformidade, do software implementado em relação ao comportamento descrito nos requisitos A validação normalmente é realizada por meio da análise dinâmica (execução de testes contra o código executável).
As atividades de testes são normalmente divididas <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />em níveis. O nível de teste define, de certa forma, a fase do processo de desenvolvimento do software na qual os testes serão realizados. Existem quatro níveis de testes, como pode ser observado na Tabela 1.
Nesta fase são testadas as menores unidades de software desenvolvidas (por exemplo: métodos de uma classe).
Nesta fase é testada a integração entre os componentes do sistema (por exemplo: classes, módulos, sub-sistemas, etc).
Nesta fase o sistema é testado como um todo com o objetivo de encontrar discordâncias entre o que foi implementado e o comportamento descrito nos requisitos.
Nesta fase o sistema é testado como um todo com o objetivo de encontrar discordâncias entre o que foi implementado e o comportamento descrito nos requisitos, sob o ponto de vista das necessidades do usuário final.
Tabela 1. Níveis de teste.
Os tipos de teste normalmente são definidos em função das características ou dimensões da qualidade que serão avaliadas no software. A escolha da característica da qualidade de um software é, às vezes, um processo subjetivo. No entanto, essa escolha normalmente é realizada com base nos riscos associados a um problema causado por uma falha em uma dessas características.
A norma internacional ISO/IEC 9126, publicada em 1991 e que na versão brasileira de agosto de 1996 recebeu o número NBR 13596, define qualidade de software como "A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas".
Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. São, portanto fatores relativos à qualidade do processo de desenvolvimento do produto e são percebidos somente pelas pessoas que trabalharam no seu desenvolvimento.
As necessidades implícitas são necessidades subjetivas dos usuários (inclusive operadores, destinatários dos resultados do software e os mantenedores do produto). As necessidades implícitas são também chamadas de qualidade em uso e devem permitir a usuários atingir metas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado.
A ISO/IEC 9126 (NBR 13596) fornece um modelo de propósito geral que define seis amplas categorias de características de qualidade de software que são, por sua vez, subdivididas em sub-características, como pode ser observado na Tabela 2.
O conjunto de funções satisfaz as necessidades explícitas e implícitas para a finalidade a que se destina o produto?