Qualidade de Software e Testes-1.pdf

Prévia do material em texto

Qualidade de Software e Testes - Conceitos Básicos e Glossário 
 
 
Sérgio Almeida Dias 
 
Pesquisar o site 
Engenharia de Software > 
Qualidade de Software e Testes - 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 dedecisã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: 
 
Em Testes de Sistema, envolvendo tempos de resposta, carga, stress, etc. Este tipo 
de teste não pode ser feito (corretamente) sem automação; 
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; 
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.