>

Um esboço sobre o processo de Testes de Software

Estou voltando a este importante assunto depois de um longo tempo. O meu artigo Testes em desenvolvimento de Software apresentou de forma bem descontraída uma breve visão sobre testes de software.

Como o assunto é vastíssimo e existem ótimos livros sobre o assunto que eu estou citando nas referências, eu vou procurar neste artigo apresentar de maneira didática e introdutória os conceitos sobre qualidade e testes de software focando no modelo em V e nos níveis de testes.

De uma forma ou de outra , sempre efetuamos testes nos trabalhos que fazemos, mesmo que seja uma mera verificação visual, e,  isso é mais verdadeiro quando estamos envolvidos com desenvolvimento de software. Mesmo que você não tenha nenhum processo de desenvolvimento e nunca ouviu falar em técnicas ou processo de testes de software você testa o seu programa antes de entregar de forma intuitiva verificando se ele esta funcionando corretamente.

Hoje em dia não há negócio que não dependa de software para sobreviver. Com a crescente demanda por software, os prazos exigidos para entrega do produto foram ficando cada vez mais curtos, o ambiente ficou mais complexo, a exigência por qualidade é cada vez mais exacerbada deixando de ser um diferencial para ser um requisito básico.

Se você, quer como desenvolvedor quer como empresa, que trabalha com software, quiser sobreviver no mercado vai ter que entregar um produto de com rapidez e qualidade. Você tem que ser ágil , preciso e fazer um trabalho de qualidade.

Falar em qualidade de software pode fazer com que você fique perdido sem saber quais características um software de qualidade deve possuir.

Calma , alguém já teve esta preocupação e já relacionou o que seriam as características da Qualidade de Software. Estou me referindo a norma ISO/IEC 9126.(NBR 13596)

A ISO é uma rede de organismos nacionais de normalização de 157 países* e a sua secretaria central é baseada em Genebra, na Suíça.
O nome ISO, para evitar problemas de abreviações em diferentes línguas, vem da palavra “iso” em grego, que quer dizer igual. O nome oficial da organização é, na língua inglesa, "International Organization for Standardization".   *Fonte: site da ISO, acesso em maio de 2008.

IEC significa Electrical Commision e atua, juntamente com a ISO, na área da tecnologia da informação.

Uma norma ISO é um documento, estabelecido e aprovado por consenso, que provê, para uso comum, regras, guias e/ou características para uma atividade ou seus resultados, com o objetivo de alcançar o grau de excelência num dado contexto*.

A norma ISO/IEC 9126 relaciona um conjunto de características que devem ser verificadas em um software para que ele seja considerado um software de qualidade. Vejamos:

Característica Sub-Característica Verificação
Funcionalidade
satisfaz as necessidades ?

 

 Adequação Propõe-se a fazer o que
Acurácia

Gera resultados corretos ou conforme acordados?
Interoperabilidade É capaz de interagir com os sistemas especificados?
conformidade Está de acordo com normas e convenções  previstas em leis e descrições similares?
Confiabilidade
é imune a falhas  e estável ?

 

 Tolerância a falhas Qual a reação quando ocorrem falhas ?
recuperabilidade É capaz de recuperar dados após uma falha ?
Maturidade Qual a frequência das falhas ?
Usabilidade
é fácil de usar ?

 

 Operacionabilidade É Fácil de operar e controlar ?
Intelegibilidade É fácil de entender os conceitos utilizados ?
Apreensibilidade É fácil de aprender usar ?
Eficiência
é rápido e eficiente ?

 

 Tempo Qual é o tempo de resposta e de processamento ?
Recursos Qual recurso utiliza e por quanto  tempo ?
Manutenibilidade
É fácil de alterar e corrigir ?

 

 Modificabilidade É fácil modificar e corrigir defeitos ?
Estabilidade Existe grande risco quando se efetuam alterações ?
Testabilidade É fácil de testar após alterações ?
Portabilidade
é fácil de ser utilizado em outro ambiente ?

 

 Adaptabilidade È fácil adaptar a outros ambientes ?
Instalabilidade É fácil instalar em outros ambientes ?
Conformidade Está de acordo com os padrões de portabilidade ?
Capacidade de ser substituído. É fácil de ser substituído por outro software ?

Além disso a norma também estabelece os seguintes requisitos de qualidade:

a) Descrição do produto compreensível e completa para ajudar o usuário ou comprador em potencial na avaliação da adequação do produto a sua realidade e fornecer informações comerciais;
b) Documentação do Usuário de fácil compreensão, permitindo uma visão geral do produto e de todas as suas funções, identificando conhecimento necessário para uso da aplicação;
c) Identificação do tipo de interface com o usuário: interface gráfica, linha de comando, menu de comandos, janelas, etc.;
d) Instruções detalhadas sobre como instalar o produto, caso a instalação possa ser conduzida pelo usuário;
e) Possibilidade de verificar se a instalação foi bem sucedida;
f) Especificação de valores-limite para quantidade de registros e dados de entrada, como, por exemplo, precisão de casa decimal;
g) Operação normal, mesmo quando os dados informados estão fora dos limites especificados;
h) Consistência de vocabulário entre as mensagens e a documentação;
i) Função de auxílio (help) sensível ao contexto;
j) Mensagens de erro com informações necessárias para solucionar o problema;
k) Diferenciação de tipos de mensagem: confirmação, consulta, advertência e erro;
l) Clareza e padronização nos formatos de telas de entrada, relatórios e outras entradas e saídas;
m) Capacidade de reverter funções de efeito drástico;
n) Capacidade de recuperar dados após uma falha de hardware ou software, queda de energia ou erro fatal;
o) Alertas claros para o usuário das conseqüências de uma determinada confirmação;
p) Identificação dos arquivos utilizados pelo programa;
q) Identificação da função do programa que está sendo executada no momento;
r) Capacidade de interromper um processamento demorado.

Como você pode ver, fazer um software de qualidade exige muito trabalho; mas trabalho não é tudo, organização e trabalho dão um resultado melhor...

Digo isso por que você pode se matar de trabalhar e produzir um software de baixa qualidade. É por isso que foram definidos processos de desenvolvimento de software para que o trabalho seja feito de forma estruturada e organizada.

Se você já adota um processo de desenvolvimento de software como pode ter a certeza de que esta criando um software de qualidade ? 

Testando o seu software ...não é mesmo ???

Se você faz apenas um teste superficial ou um deixa para fazer o teste quando o produto estiver acabado pode ter surpresas desagradáveis, pois quanto mais tarde as falhas forem encontradas maiores os custos para sua correção.

Logo , se você quer produzir um software com qualidade a um custo baixo você tem que incorporar os testes de software ao processo de desenvolvimento de forma que eles sejam aplicados desde o início do ciclo de desenvolvimento.

Veja a seguir uma visão geral das atividades de teste durante o processo de desenvolvimento de software (é apenas uma sugestão);

Ciclo de vida Atividades de teste
Requisitos Gerar os cenários de testes funcionais;
Análise e Projeto Gerar casos de testes funcionais e estruturais;
Implementação Executar os casos de testes;
Manutenção Efetuar a verificação;
Aplicar testes nos pontos alterados;

Existem vários modelos que você pode seguir para implementar os testes de software ao seu processo de desenvolvimento de software mas meu foco neste artigo será o modelo em V.

De forma resumida podemos dizer que o modelo em V  se preocupa em realizar testes  durante todo o ciclo de desenvolvimento com o objetivo de encontrar erros o mais cedo possível.

Este modelo introduz a criação de testes de dados e cenários de teste durante o ciclo de desenvolvimento do software e trabalha com diferentes níveis de testes como : Teste de unidade, Teste de integração , Teste de sistema e Teste de aceitação.

Basicamente o ciclo de desenvolvimento do modelo segue a seguinte seqüência:

Especificação, requisitos, desenho, código, testes unitários, integração, testes, sistema, testes, aceitação, testes, especificação/desenho de código, testes unitários, requisitos, revisão, aceitação do sistema, testes de revisão, especificação/ desenho de código, testes de aceitação do sistema, desenho e revisão.

Temos a seguir um esquema simplificado representando o modelo:

Como podemos notar a base para os testes de software é o documento de requisitos do sistema (Casos de Uso) a partir dos quais são gerados os cenários de testes e dos quais derivam os casos de testes.

Podemos então afirmar que a técnica de testes a ser aplicada depende da metodologia empregada na especificação de requisitos.

A verificação - "Estamos construindo certo o produto."-  É feita para garantir que as funcionalidades especificadas e definidas no DRS estão sendo implementadas no software. Esta atividade pode usar os seguintes métodos:

A validação - "Estamos construindo o produto certo" - Garante que o software que foi construído atende os requisitos do cliente. Para realizar esta atividade podemos usar os seguintes métodos:

  1. Teste de Caixa Preta ou Funcional;
  2. Teste de Caixa Branca ou Estrutural;
  3. Teste de Caixa Cinza;
  4. Análise baseada em erros;

Uma proposta para um método de implantação do processo de teste de software usa como base os documentos descritos no esquema a seguir:

Fonte: Uma Metodologia para Teste de Software no Contexto da Melhoria do Processo. - 2008

A relação do processo de teste de software com o processo de desenvolvimento de software esta representando no esquema abaixo:

Fonte: Uma Metodologia para Teste de Software no Contexto da Melhoria do Processo. - 2008

A seguir iremos conceituar cada um dos níveis de testes citados:

Teste de Unidade

Conhecido como Teste Unitário. É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas ( pequenas partes ou unidades do sistema). O  alvo são os métodos dos objetos ou módulo/função ou mesmo pequenos trechos de código. O objetivo é encontrar falhas de funcionamento em uma pequena parte do sistema funcionando independentemente do todo.(wikipedia)

Os testes de unidade são feitos pelo próprio programador geralmente usando o método caixa branca ou funcional.

Teste de Integração

Na fase de teste de integração o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema verificando se as unidades testadas individualmente executam de forma correta quando integradas.

Tipos de teste de integração:

  1. Integração Não-Incremental que usa a abordagem Big-Bang;
  2. Integração Incremental onde o programa é construído e testado em pequenos segmentos;
  3. Integração Top-Down - de cima para baixo;
  4. Integração Botton-Up - de baixo para cima;

Teste de Sistema

O teste de sistema  tem como objetivo executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas. Os testes são executados em condições similares - de ambiente, interfaces sistêmicas e massas de dados - àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas de dados.(wikipedia)

No teste de sistema verifica-se o comportamento requisitado e a validação das funcionalidades especificadas pelo cliente.

Teste de Aceitação

O teste de aceitação é conduzido por usuários finais do sistema. Os testes são realizados, geralmente, por um grupo restrito de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. O teste baseia-e no método caixa-preta que visa demonstrar a conformidade  ou não com os requisitos.

Se o software for desenvolvido para ser usado por um número grande usuários faz-se uso de teste ALFA que é executado pelo usuário em um ambiente simulado e controlado nas instalações do desenvolvedor e do teste BETA que é realizado nas instalações do cliente.

Abaixo temos um esquema que representa os níveis de testes e os métodos de testes citados:

E ficamos por aqui, em outro artigo irei falar sobre os testes de unidade e o método caixa branca.

Ate o próximo artigo....

José Carlos Macoratti