Redução e Controle de Erros para as Atividades de Testes de Software Vivian Bella Ferreira Louzada (UNIP) vivianbella@electra.com.br RESUMO O artigo inicia o assunto abordando conceitos gerais sobre teste de software, inclusive quais são as técnicas existentes que promovem a atividade de teste em produtos de software. Sobre projeto de teste, o artigo aborda as falhas mais comuns que ocorrem nessa fase, ilustrando com os fatores críticos de sucesso para testes de software. Finalmente, o estudo menciona alguns métodos capazes de controlar a atividade de testes, envolvendo etapas como: ocorrência de erros, custos de testes, erros de previsão, erros de documentação, entre outros. Relata-se também o momento considerado ideal para encerramento dos testes de software. Palavras-chave: teste, projeto, software, erros. 1 - Conceito de Testes de Software O objetivo principal deste estudo é compreender os motivos pelos quais as atividades de testes não funcionam na prática como é proposto na teoria. O objetivo dos testes de software é revelar a presença de erros. A falta de testes gera defeitos e erros não revelados no momento ideal para correção dos mesmos, implicando em alto custo para correção [WEBER&MALDONADO&ROCHA01]. Os testes constituem uma fase dispendiosa e trabalhosa do processo de software. [SOMMERVILLE03] Os testes são indispensáveis para detectar os defeitos que ainda escapam das revisões e para avaliar-se o grau de qualidade de um produto e de seus componentes. [PÁDUA03] Segundo [MOLINARI03], alguns gerentes de projetos deixam a atividade de testes como a última fase, executando os testes apenas com o tempo restante para o término do projeto ou nem o fazem, se o custo não permitir ou se o tempo estiver esgotado. Desta maneira, um produto de baixa qualidade é enviado para o cliente, que, por sua vez, apostou muito no software e acredita que, sem erros, ele será a solução de seu problema. A falta de tempo e recursos, bem como a indisponibilidade de ferramentas adequadas para a realização dos testes, são os principais problemas enfrentados pelas equipes de teste. Por motivos como esse, sugere-se que seja definido um critério para testes, cuja finalidade é selecionar e avaliar casos de teste de forma a aumentar as possibilidades de revelar a presença de defeitos. [WEBER&MALDONADO&ROCHA01] A atividade de teste envolve as etapas de planejamento, projeto de casos de teste, execução e avaliação de resultados que devem ser conduzidas ao longo de todo o processo de desenvolvimento do software. Salienta-se que a ausência de planejamento das atividades de desenvolvimento é uma das causas da crise do software. [PRESSMAN01]
De acordo com [MOLINARI03], os conceitos vitais para entendimento de testes de software se resumem nas fases: Planejamento de testes Plano de testes Requerimento de testes Caso de testes Procedimento de testes Script de testes Ponto de verificação Testar versus Provar: De acordo com [PFLEEGER04], para provar que um programa está correto, a equipe de testes ou o programador considera somente o código e suas condições de entrada e saída. O programa é visto em termos das classes de dados e das condições descritas no projeto. Logo, a prova pode não envolver a execução do código, mas a compreensão do que está acontecendo dentro do programa. 2 Tipos de Teste Abaixo consta uma tabela com os principais tipos de teste envolvidos. Tipo de Teste Teste de Unidade Teste de Integração Teste de Sistema Teste Operacional Teste Negativo Positivo Teste de Regressão Teste de Caixa Preta Teste de Caixa Branca Teste Beta Teste de Verificação de Versão Teste Funcional Descrição Teste em nível de componente ou classe. É o teste cujo objetivo é um pedaço do código Garante que um ou mais componentes combinados (ou unidades) funcionem corretamente A aplicação tem que funcionar como um todo. Neste momento a aplicação tem de fazer aquilo que diz que faz Garante que a aplicação pode rodar muito tempo sem falhar Garante que a aplicação vai funcionar no caminho feliz de sua execução e vai funcionar no seu fluxo de exceção Um dos mais importantes testes. Para irmos para o futuro, temos de voltar ao passado, sempre. Toda vez que formos inserir uma característica nova na aplicação, devemos testar toda a aplicação. Afinal, podemos, ao consertar algo, quebrar outro Testar todas as entradas e saídas desejadas. Não se está preocupado com o código O objetivo é testar o código. Ás vezes existem partes do código que nunca foram testadas O objetivo é testar a aplicação em produção Toda vez que se libera uma nova versão da aplicação, existem condições mínimas que validam se a versão liberada está OK. Este teste é usado durante o processo de construção da aplicação. Pode querer testar às vezes apenas uma parte da aplicação Testar se as funcionalidades presentes na documentação
funcionam como especificado. Incluem-se aws regras de negócio. Verifica se a navegabilidade e os objetos de tela funcionam Teste de Interface corretamente, em conformidade com padrões vigentes (em nível de interface). Teste de Performance Verifica se o tempo de resposta é o desejada para momento de utilização da aplicação e suas respectivas telas envolvidas. Teste de Carga Verifica se a aplicação suporta a quantidade de usuários simultâneos requeridos. Teste de Aceitação do Usuário É um teste exploratório voltado para validar aquilo que o usuário deseja, tendo um objetivo claro: dar o aceite ou não. Teste de estresse Testar a aplicação em situações inesperadas. Teste de Volume Testar a quantidade de dados envolvidos. Teste de Configuração Testa se a aplicação funciona corretamente em diferentes ambientes de hardware e de software. Teste de Instalação Verificar se a instalação da aplicação (hardware e software) foi OK. Teste de Documentação A documentação existe? Mostra o que o software faz efetivamente? Falta algo na documentação? Teste de Integridade O objetivo é testar a integridade dos dados armazenados. Teste de Segurança Testar a segurança da aplicação nas mais diversas formas. Teste de Monitoração Testes funcionais que visam verificar o status e disponibilidade de diversas funcionalidades e da aplicação em si. Teste de Ameaça Semelhante ao de segurança, mas em escala maior em nível de falhas. Monkey Test Testa o aplicativo de forma aleatória e inesperada. Teste de Módulo Teste de um módulo, porém em nível menor. Semelhante ao de unidade, porém, mais abrangente. [Tabela 1 Adaptada de MOLINARI, Leonardo. Testes de Software, 2003] 3 - Projeto de Teste Testar, conforme [WEBER&MALDONADO&ROCHA01], é examinar o comportamento do produto por meio de sua execução. Teste de software é o processo de executar um programa com o objetivo de revelar a presença de erros. Contribui para aumentar a confiança de que o software desempenha as funções especificadas. Teste é um conjunto de atividades que pode ser planejado antecipadamente e realizado sistematicamente. [PRESSMAN01] Ainda segundo [PRESSMAN01], um bom projeto de teste deve iniciar junto com a programação e acompanhar todo o processo de desenvolvimento. A cada etapa pode-se aplicar diferentes técnicas de avaliação. O ideal seria existir uma equipe independe para executar esta função, mas caso não seja possível um projeto de teste bem elaborado pode auxiliar e garantir uma qualidade elevada no software. Segundo [MOLINARI03], alguns problemas comuns no planejamento são: Indefinição dos requisitos;
Recursos da ferramenta de teste foram desprezados no planejamento; Prazo curto; Planejamento de fraco conhecimento (tratando-se de testes ou do negócio); Planejamento pouco abrangente ; Planejamento com baixo acoplamento; Planejamento de risco alto (Requisitos a serem testados são de alto risco à medida que qualquer bug será de alta prioridade). Alguns defeitos comuns no projeto de desenvolvimento, conforme [WEBER&MALDONADO&ROCHA01], são: defeitos de origem humana, erros localizados em linha de códigos raramente executados, tradução incorreta de informações, entre outros. Na figura abaixo podemos verificar a demonstração do projeto de teste durante o desenvolvimento do software de forma espiral. O teste se inicia na codificação, com o teste de unidade, após esta avaliação é necessária a verificação da integração entre os módulos, ou seja avaliar o projeto desenvolvido, em um terceiro momento a validação, conferindo se os requisitos foram atendidos, e finalmente o teste do sistema como um todo, para total segurança. Engenharia de Requisito Projeto Código S R D C U Teste de Unidade I Teste de Integração V Teste de Validação ST Teste de Sistema [Figura 1 PRESSMAN, Roger. Engenharia de Software, 2001.] 3.1 - Falhas no projeto de teste As falhas ocasionadas nos testes podem ter início no planejamento deste teste, ou na falta de comunicação entre a equipe de teste e os desenvolvedores. No caso do planejamento, podemos considerar a falta de uma equipe de teste, ou na estrutura do projeto de desenvolvimento, pois o teste deve fazer parte do projeto inicial. 3.1.1 - Falhas na comunicação A comunicação existente entre as equipes de desenvolvimento e de teste deve ser clara e objetiva. Um dos grandes problemas encontrados é o fato dos seres humanos não ser favorável a avaliação constante do seu trabalho, na área de desenvolvimento de software este problema se agrava pelos diferentes métodos de programação, lógica e conceitos utilizados. Alguns profissionais acreditam ser verdadeiros artistas de determinado aplicativo ou linguagem, dificultado uma forma padrão de teste e avaliação.
3.1.2 - Falhas de documentação Um projeto bem desenvolvido deve ter uma documentação significativa e representativa de todas as etapas e fases, não gerando dúvidas para nenhum dos membros envolvidos. Caso esta não seja uma realidade, a avaliação do mesmo será dificultada pela falta de informação. O próprio desenvolvimento do projeto ter falhas decorrentes desta documentação, pois se os requisitos, as integrações, os equipamentos necessários a boa execução do software não estiverem claras, o resultado final poderá ser prejudicado. No caso específico de teste, como será possível avaliar um código sem ter a documentação do que este projeto deve fazer. A avaliação dos componentes fica limitada a funcionalidade dos mesmos, mas não será possível verificar a integridade dos resultados esperados. 3.1.3 - Falhas na escolha do método aplicado em cada fase Caso o projeto de teste esteja planejado e previsto, é necessário que a equipe responsável conheça os métodos de teste mais adequados para cada fase do desenvolvimento. A falta deste conhecimento pode ocasionar resultados inadequados, prejudicando a qualidade esperada. 3.1.4 - Falhas decorrentes do hardware ou bancos de dados (ambiente) A avaliação do ambiente onde este software dera ser executado é outro grande fator a ser considerado. Um teste local para um aplicativo que deverá ser executado em rede, não irá avaliar o desempenho do mesmo e também a integridade dos dados que estarão sendo manipulados, podendo até mesmo esconder falhas no código em execução, pois os ambientes em redes requerem cuidados específicos, de acordo com os aplicativos utilizados e os equipamentos de hardware. Outra grande falha encontrada está relacionada ao banco de dados, no ambiente de teste existe um banco de dados que pode estar viciado. O correto é sempre que possível utilizar uma cópia do banco de dados real, para avaliação dos resultados e também de desempenho. 4 - Fatores Críticos de Sucesso para Testes de Software Resultados Previstos A equipe deve saber a finalidade da revisão, e o que deve ser testado. Responsabilidades As responsabilidades devem ser atribuídas de forma clara entre todos os participantes. Direitos Individuais As opiniões e os sentimentos devem ser consideradas características dos indivíduos, não do grupo. Participantes A equipe deve contar com testadores internos e externos. Processo Estruturado Os procedimentos devem ser estáveis, bem definidos. O Moderador Deve ser hábil e treinado em testes. Os Registros Devem ser avaliados e devem estar em relatórios próprios. [Tabela 2 Adaptado de HETZEL, 1988 The Complete Guide to Software Testing] Destes sete fatores, os primeiros três são os mais freqüentemente violados. O que se espera da revisão e da colaboração de todos os participantes deve ser definida claramente. É importante os
indivíduos preservarem suas opiniões. Talvez a maneira mais correta seria considerar as revisões efetuadas pelo grupo de forma geral. Estes agentes devem ser definidos no projeto do desenvolvimento do software. 4.1 Resultados de Teste que devem ser revisados, conforme [HETZEL88]: Plano de Teste Especificações do teste de desenvolvimento Procedimentos de teste Especificações de teste Casos de Testes Relatórios de Testes Inventários De acordo com [PFLEEGER04], um caso de teste é uma escolha específica dos dados de entrada a serem utilizados para testar um programa. Um teste é um conjunto limitado de casos de testes. Erros de Teste, de acordo com [MOLINARI03], são erros encontrados no teste que não foram reportados por alguma razão. 5 Controlando as Funções de Teste 5.1 Testando o Teste De acordo com [HETZEL88], testar é uma função delicada de suporte, pois fornece informações precisas. Sem informações deste porte, a gerência não é capaz de avaliar o progresso do desenvolvimento do software ou de avaliar os problemas de forma correta. Testar os métodos de teste fornece uma base para o controle do projeto, é duplamente crítico controlar os testes de forma eficaz. Testar os mecanismos de teste fornece a informação que serve como o gabarito para controlar a função testada, sendo assegurado, desta forma, que o teste esteja sendo executando corretamente. Elementos-chave para o efetivo controle de testes: a. Ocorrência de erros, falhas de projeto e falhas no custo Além a seguir e a analisar freqüências do erro, é recomendado analisar o impacto e os custos. Os determinados erros e falhas têm o impacto principal e custam muito mais para corrigir ou recuperar. Outros têm poucos impacto e inconveniências menores. Ao analisar o desempenho dos testes, o objetivo é detectar e impedir falhas. As contagens simples da freqüência não podem mostrar as tendências corretamente. Seguir custos estimados supera o impacto direto. b. Análise de problemas Os imprevistos devem ser analisados para responder a diversas perguntas básicas e para suportar a fase determinada. Algumas questões que podem ser respondidas que acordo com as análises de problemas são:
Se o(s) erro(s) foi(ram) localizado(s)... Se não houve(ram) erro(s) localizado(s)... Como o erro foi encontrado? Por que não foram encontrados erros? O que foi feito incorretamente? Como poderão ser impedidos? Quem fez errado? Por que não foi detectado antes? Como poderia ter sido impedido? [Tabela 3 Adaptada de HETZEL, Bill. The Complete Guide to the Software Testing, 1984] c. Testes de Custo de Falhas Além de analisar freqüências de erros, é recomendado também analisar o impacto e os custos dos erros em relação ao desempenho do software. Determinados erros e falhas têm forte impacto e custam muitos para corrigir ou recuperar. Outros têm poucos impacto e não são muito representativos. Ao analisar o desempenho dos testes, o objetivo fundamental é detectar e impedir falhas. As falhas sendo corrigidas antes de acontecerem previnem custos maiores do que aqueles orçados. d. Testes durante as fases do projeto Faz parte do conceito de controle de testes seguir as fases do trabalho de testes para a gerência do projeto, o acompanhamento traz um resultado muito útil. As fases em análise ocorrem fora do projeto e os resultados são relatados como linha de base para os desenvolvedores. O acompanhamento inicia-se conhecendo-se o que deve ser testado e quais resultados esperar. Posteriormente, deve-se conhecer os resultados já emitidos e as barreiras de testes, dependendo do fluxo da informação. Esses resultados fornecem base para análise das atividades de teste. As informações necessárias para testar as fases do projeto são: - Trabalho do projeto de teste - Análise da especificação do caso de teste - Disponibilidade dos casos de teste - O que foi testado - O que não foi testado - Quais as versões do software foram testadas - Até quando testar. e. Documentação de teste Um aspecto do controle da atividade de testes é documentação. O ciclo de vida do desenvolvimento é caracterizado pelos desenvolvimento de cada fase do trabalho. Na mesma maneira, o ciclo de vida de testes pode ser definido e controlado pelos trabalhos produzidos durante cada uma das atividades de teste. A documentação de teste é totalmente ignorada em muitas empresas. Os padrões para escrever o projeto ou para relatar resultados de teste são desiguais. Em muitas organizações a documentação de teste não é produzida simplesmente. Em outras, as documentações de teste são criadas conforme a prática. A documentação de teste deve conter: - Plano de testes
- Especificação do teste do projeto - Especificação de casos de teste - Métodos para testes - Teste de itens - Histórico de testes - Relatório de erros O primeiro elemento que controla o teste de função deve localizar eficazmente erros, falhas no projeto e falhas no orçamento. Isto envolve a captura da informação nos problemas detectados durante o teste e então a análise dessa informação ajuda de modo que as tendências e os eventos significativos sejam reconhecidos. 6 Quando encerrar os testes Conforme [PFLEEGER04], se há muitos defeitos em um componente, queremos encontrá-lo o quanto antes, durante o processo de teste. Entretanto, se encontrarmos um grande número de defeitos no início, provavelmente, ainda existe um grande número de defeitos que não foram detectados. De qualquer maneira, os resultados apurados tornam difícil saber quando parar de procurar por defeitos durante o teste. É necessário estimar o número de defeitos remanescentes, não somente para saber quando interromper a procura, mas também para obtermos um grau de confiança no código que está sendo produzido. O número de defeitos também indica o provável esforço de manutenção necessário, se os defeitos forem deixados para serem detectados depois que o sistema for entregue. CONCLUSÕES Conforme as referências citadas, concluo que algumas empresas desenvolvedoras de software, seja de pequeno, médio ou grande porte, não deslocam profissionais para a atividade de teste do produto de software. Muitos gerentes de projeto acreditam que a fase de testes é um sinônimo de custos desnecessários, envolvendo engenheiros de testes que fazem as mesmas rotinas dos usuários, quando a aplicação está na fase de produção. Dependendo da atividade desenvolvida pelo software, é muito arriscado colocá-lo em produção sem uma bateria de testes exaustivos. Imaginemos um software que possa gerenciar qualquer aparelho da área médica, que necessite precisão em suas respostas. Caso aquela aplicação não tenha sido testada exaustivamente, muito provavelmente erros na resposta poderão ocorrer e, conseqüentemente, falhas médicas. Na verdade, são erros no software que, por confiança dos profissionais, acarretam em erro médico. Esse é apenas um exemplo muito próximo da nossa realidade. Podemos contar com, praticamente, mais de 25 tipos de testes que podem ser aplicados no produto de software. De todos esses tipos, sabemos que não são todos que envolvem necessariamente profissionais de fábrica de testes. Caso eles sejam aplicados, os erros e custos futuros serão certamente minimizados.
REFERÊNCIAS BIBLIOGRÁFICAS [HETZEL88] HETZEL, Bill. The Complete Guide to Software Testing. John Wiley & Sons, Inc, 1988. [MOLINARI03] MOLINARI, Leonardo. Testes de Software. Editora Érica, 2003. [PÁDUA03] PÁDUA, Wilson de. Engenharia de Software Fundamentos, Métodos e Padrões. LTC, 2001. [PFLEEGER04] PFLEEGER, Shari Lawrence. Engenharia de Software Teoria e Prática. Prentice Hall, 2004. [PRESSMAN01] PRESSMAN, Roger S. Software Engineering A Pratctitioner s Approach Mc Graw Hill, 2001. [SOMMERVILLE] SOMMERVILLE, Ian. Engenharia de Software. Editora Makron Books, 2003. [WEBER&MALDONADO&ROCHA01] WEBER, Kival Chaves. ROCHA, Ana Regina Cavalcanti da. MALDONADO, Jose Carlos. Qualidade de Software Teoria e Prática. Prentice Hall, 2001.