Qualidade de Software e Testes (incompleto)

Conceitos Básicos e Glossário

Este artigo se apóia no modelo de qualidade de software proposto pela norma ISO/IEC 9126 e pelo modelo de testes de software da norma IEEE 829.

Mas antes de entrar no assunto, vamos a esta terminologia básica sobre qualidade de Software:
“Quando as Pessoas cometerem erros, introduzindo defeitos no software, que quando executado em determinadas condições se manifestarão sob a forma de falhas de processamento”
(definição adaptada por Paul Bergami[1])

Utilizo esta definição para começar a conversa, porque esta classificação erro/defeito/falha será útil ao longo do texto.

Quando falamos em testes de software e qualidade em geral é importante lembrar de alguns conceitos básicos:

  • Não existe 100% de qualidade (nem 100% de defeitos);
  • O custo para se encontrar novos defeitos em um software sobe exponencialmente na medida em que o número de defeitos diminui;
  • O esforço para se desenvolver a primeira versão de um sistema representa apenas uma pequena fração do esforço total de desenvolvimento deste sistema. Por isto, devemos estar muito atentos aos testes contínuos das manutenções que o sistema vai sofrer ao longo de sua vida;

É importante destacar que este texto não pretende ter valor acadêmico, mas servir como uma introdução ao tema da qualidade de software. Sei que algumas afirmativas deste texto carecem de fundamentação rigorosa, mas garanto que nada do que está colocado aqui é apenas uma opinião e sim o resultado de estudos formais e experimentos em campo. Infelizmente as fontes foram perdidas, pela maneira como este conhecimento foi adquirido e aplicado. 

O modelo de Qualidade da ISO 9126

Esta norma (ou família de normas, na verdade) descreve um modelo para qualidade de software, envolvendo a qualidade do processo (de desenvolvimento), as características de qualidade internas e externas do produto de software e a chamada "qualidade em uso", que consiste na qualidade apresentada pelo sistema nas condições reais de utilização.

Esta norma descreve as características de qualidade que podem ser identificadas em um software (veja artigo na Wikipedia). Esta norma deve balizar o seu planejamento de testes, já que nem todos os atributos de qualidade de um software precisam estar presentes em todos os software.

A norma IEEE 829 e o Processo de Testes

Esta norma do Instituto de Engenheiros Elétricos e Eletrônicos descreve o processo básico de teste de software e os artefatos necessários para a sua execução. Os artefatos definidos na norma são:
  • Plano de Testes: contendo os objetivos e metas globais do teste de software previsto;
  • Projeto de Testes: projeto detalhado que especifica como o Plano de Testes será executado;
  • Caso de Teste: descreve uma situação que deverá ser testada, derivada diretamente dos Casos de Uso do sistema;
  • Roteiro de Teste: descreve as ações que deverão ser executadas no software para que o Caso de Testes seja executado. O nível de detalhamento deste roteiro é influencia diretamente o perfil dos testadores que executarão os testes no sistema;
  • Registro (ou evidência) de Teste: registro dos testes executados, independentemente de terem sido encontrados erros ou não. Os registros devem conter informações sobre a massa de testes utilizada e o roteiro de testes executado. Um registro pode conter cópias das telas do aplicativo se isto for pertinente;
  • Relatório de Incidente: relatório descrevendo uma falha ocorrida durante a execução dos testes;
  • Relatório Sumário (ou executivo) de Testes: contém o resumo das condições de teste executadas, defeitos encontrados e tabulações estatísticas desejadas.

O por que uma norma é importante para isto? Uma norma deste tipo não inventa nada, mas consolida idéias e boas práticas já empregradas pelo mercado e/o pela comunicade acadêmica. Esta norma tem a vantagem de definir um jargão (ou nomenclatura) padrão e de evitar que alguém fique tentando inventar a roda.

Além disto, nunca conheci um processo eficiente de testes de sistema que não utilize um modelo semelhante a este. A exceção poderia ser a utilização de testes unitários agressivos e metodologias ágeis baseadas em TDD, mas mesmo neste caso eu tenho algumas questões não resolvidas. Veja o item Métodos Ágeis e TDD no final deste artigo.

Tipos de Testes

Nesta seção vou listar as classificações e técnicas de testes que mais encontrei em minha experiência nesta área. Vale, porém dois alertas: a criatividade para nomes de testes é infinita e; há muita controvérsia sobre o assunto.

Existe muita literatura sobre este assunto, propondo diferentes terminologias e classificações de testes. Existe, também, o interesse de vendedores de livros, de consultoria e de ferramentas. Esta é uma coletânea que eu considero moderada e que é suportada por uma parte significativa da comunidade.

Quanto à forma como são executados:
  • Testes de Caixa Preta: executados com o sistema complemente montado e utilizando as interfaces externas providas pela aplicação;
  • Testes de Caixa Branca: executado pelo desenvolvedor, com o sistema “aberto”, permite o teste de interfaces internas e em condições de configuração inexistentes quando o sistema está montado;
Quanto aos objetivos:
  • Testes de Funcionalidade ou testes funcionais, que verificam se os requisitos funcionais do projeto foram atendidos;
  • Testes de Sistema ou Não Funcionais, validam os requisitos não funcionais da aplicação;
  • Testes de Regressão, ou Regressivos: consiste em testar apenas as funcionalidades que não foram afetadas (ou não deveriam ter sido) pela nova versão do sistema: “Tudo deve funcionar como antes”;
  • Testes de Progressão, ou Progressivos: testes apenas das funcionalidades (ou requisitos não funcionais) especificados para a versão;
Quanto à fase do projeto:
  • Testes Unitários: aplicados pelos desenvolvedores, validam o funcionamento de componentes isolados do sistema. Atualmente este tipo de teste tem sido muito utilizado com automação de testes em frameworks como o JUnit;
  • Testes de Integração: realizados na fase de integração do desenvolvimento, tem como objetivo validar a integração entre as camadas ou componentes do sistema;
  • Testes Integrados: típicos testes de Caixa Preta realizados quando uma versão do sistema foi liberada;
  • Teste de Aceite, também chamado de Homologação, consiste nos testes realizados para validar os requisitos do Cliente e que condicionarão a aceitação da versão para entrada em produção;
Quanto às técnicas de testes:
  • Teste de Carga: consiste em levar o sistema todo ao limite de carga do software e da infra-estrutura, medindo a capacidade de carga total deste sistema. Este é um teste que precisa necessariamente ser automatizado;
  • Teste de Stress:  comumente confundido com o Teste de Carga, consiste em levar o sistema todo ao limite de ruptura (stress) para medir a sua capacidade de recuperação quando a carga total diminui;
  • Teste de Fumaça: consiste em um teste rápido, executando as principais funcionalidades do sistema, sem se preocupar com as condições de erro. O mesmo que teste do Caminho Feliz;
  • Teste de Configuração: consiste em executar o sistema nas diversas configurações de hardware e software básico previstos para a sua execução em produção;
  • Testes de Usabilidade: validam as condições de usabilidade do sistema, verificando mensagens emitidas para o usuário, clareza na comunicação do estado de execução da aplicação, navegação, dentre outras características, sempre sob a ótica do usuário;

Automação de Testes

A automação de testes costuma soar como panacéia para resolver a equação prazo/qualidade dos testes, especialmente para as pessoas que estão em cargos gerenciais de decisão.

De maneira geral, testes automatizados exigem scripts de testes, que costumavam ser difíceis de preparar e caros para manter. Fabricantes de ferramentas reduziram muito o custo de montagem dos scripts, especialmente através de técnicas de "aprendizado pelo exemplo", mas as dificuldades para se manter estes scripts a longo prazo contiuam relevantes e sem uma solução definitiva. Ao final, para que estes scripts sejam mantidos, é preciso mesmo uma visão sistêmica sobre eles e a programação direta nestas linguagens de scripts, não importa quais forem.

Por este motivo, eu formei uma opinião sobre a oportunidade de se utilziar testes automatizados:

  1. Em Testes de Sistema, envolvendo tempos de resposta, carga, stress, etc. Este tipo de teste não pode ser feito (corretamente) sem automação;
  2. Testes funcionais das condições básicas de execução (ou Caminho Feliz), visando manter estáveis as funções-chave do sistema durante o ciclo de desenvolvimento e/ou manutenção. Ou seja, foco em Testes de Regressão;
  3. Sistemas que controlam funções vitais, envolvendo risco de vida. Nestes casos, ainda que seja impossível chegar aos 100% de qualidade, temos que buscar tantos noves (99,999%) quanto seja possível. Neste contexto a automação entra como aliada na qualidade de execução dos testes e os custos são secundários;
Na vida real o difícil é identificar o terceiro caso. Quando estamos falando de um software de navegação de uma aeronave, ou um sistema de controle de uma UTI, é fácil. Mas o sistema de expedição de mercadorias em um depósito, é crítico? Quiais dos processos destes sistema seriam candidatos a este tratamento de qualidade?
Questões difíceis que ficarão sem resposta neste artigo. Vejam mais reflexões sobre isto em Engenharia de Software Guiada pelo Valor.

Links

[1] Paul Bergami, um bom amigo e que me produziu inúmeros insights: Blog, LinkedIn

Considerações Econômicas Sobre os Testes

Há uma frase popular no mundo da consultoria de que que Qualidade e Segurança não tem fim.

O desafio dos especialistas em qualidade é estabelecer as práticas de QA (garantia de qualidade, em português) que levem o sistema ao nível de qualidade suficiente para o contexto onde o sistema será executado.


Métodos Ágeis e TDD

Conclusões


Comments