ENGENHARIA DE SOFTWARE: TESTES E QUALIDADE DE PRODUTO Prof. José Manuel de Sacadura Rocha

Transcrição

1 ENGENHARIA DE SOFTWARE: TESTES E QUALIDADE DE PRODUTO Prof. José Manuel de Sacadura Rocha RESUMO Trata-se da qualidade no desenvolvimento do produto software principalmente com respeito à fase de testes do produto. Aborda as principais características dos testes de software e os respectivos conceitos, bem como da necessidade dos engenheiros e gerentes de desenvolvimento e projeto atribuir o tempo necessário e precioso à etapa de testes. Verifica-se que a qualidade de um produto de software se mede pela realização dos requisitos quanto às regras de negócio e funcionalidades exigidas pelos clientes, o que distingue a homologação de validação e testes de manutenção. Palavras-chave: Testes, Software, Homologação, Manutenção, Desenvolvimento, Implantação, Sistemas. ABSTRACT It is treated mainly of the quality in the development of the product software with regard to the phase of tests of the product. He approaches the main characteristics of the software tests and the respective concepts, as well as of the engineers' need and development managers and I plan to attribute the necessary and precious time to the stage of tests. It is verified that the quality of a software product is measured by the accomplishment of the requirements as for the business rules and functionalities demanded by the

2 customers, what distinguishes the validation approval and maintenance tests. Word-key: Tests, Software, Approval, Maintenance, Development, Implantation, Systems. INTRODUÇÃO O esforço de TESTES de software pode ser compreendido pela Regra 40/20/40 : 40% a 50% para Análise e Projeto; 20% para Codificação; 30% a 40% para Testes e Depuração. Uma pesquisa envolvendo engenheiros de software demonstrou que 31% deles dedicam cerca de 30% em média de seu esforço, em relação ao projeto total, com testes de software. Embora exista um crescente reconhecimento por parte da indústria de que Testes são imprescindíveis para o desenvolvimento de softwares com QUALIDADE, ainda aproximadamente 18% dos engenheiros afirmaram não dedicarem algum esforço aos testes ou apenas dedicarem o tempo de sobra do projeto. Isto significa que testes e depurações de software ainda são vistos por muitos profissionais como algo sem importância, parecendo, na melhor das hipóteses, como apêndice do projeto, não como uma etapa própria e importante do projeto. Assim, parece óbvio que a qualidade de um projeto de software pode ser amplamente questionada. Uma confusão bastante comum diz respeito à diferença entre TESTES e MANUTENÇÃO. De forma geral a proposta da disciplina de engenharia de software é que testes de software estão relacionados com a verificação do cumprimento de REQUISITOS estabelecidos e homologados na fase

3 de Iniciação do projeto (cf. modelo Unificado RUP). Depurações deste tipo, relacionadas com requisitos estabelecidos, podem acontecer e acontecem ao longo de todo o projeto de software, mas não se confunde com manutenção, já que aqui, em princípio, o que se procura fazer é adequação ao AMBIENTE MERCADOLÓGICO, LEGAL e TECNOLÓGICO em permanente mutação, depois da fase de Transição (RUP). Por outras palavras: Testes é parte de um projeto de software e referemse aos requisitos já estabelecidos, funcionais e não funcionais; Manutenções estão além do projeto de software e começam quando damos por acabado o projeto. Também devemos conceituar, agora, os termos HOMOLOGAÇÃO e VALIDAÇÃO. Homologação é efetuada pelo cliente/usuário no final da fase de Iniciação e Validação é efetuada pelo cliente/usuário para as versões de atualização entregues posteriormente à definitiva implantação. Logo, Homologação é a definição e o compromisso instaurado pelo Documento de Requisitos Homologação é a aprovação de requisitos. Validação é a verificação e aceitação de versões de produto para Testes ou mesmo Manutenções de aprimoramento técnico e mercadológico. Ainda que possa parecer um preciosismo da disciplina engenharia de software, a importância de separar esses conceitos pode ser entendida assim: 1. Deixar claro que Testes é parte integrante e importantíssima do projeto de software; 2. Que quando entregamos versões do produto software ao cliente devemos distinguir claramente o que é depuração no sentido de atender aos requisitos da

4 atualização do ponto de vista das necessidades de negócio ou aprimoramento tecnológico. REQUISITOS Pelo que se disse acima, fica claro que a qualidade de software é CUMPRIMENTO DE REQUISITOS. Os processos de comunicação humanos são extremamente suscetíveis de ruídos de comunicação. Levantamentos de dados servem para definir os requisitos do produto de software. Requisitos podem ser Funcionais e Não Funcionais. Requisitos funcionais são classificados em De Usuário, De Sistema e De Domínio (Sommerville). No formato-padrão de requisitos os de domínio já aparecem como restrições. Fazer algo além dos requisitos estabelecidos e homologados pelo cliente não configura mais qualidade, pelo contrário, muitas vezes acaba-se desenvolvendo o que não foi pedido e deixa-se de fazer o que está estabelecido. Se ao longo do projeto e CONSTRUÇÃO novas possibilidades do produto aparecem, devem-se redefinir os requisitos e formalizá-los com os clientes a partir de uma nova homologação. Por outro lado, a qualidade de software está também ligada à Prevenção, ou, em linguagem de engenharia de software, aos REQUISITOS DE DOMÍNIO. A importância de um requisito de domínio (funcional) é impedir não-conformidades e erros substanciais a partir das operações executadas pelos clientes/usuários. As restrições impostas nas funcionalidades e operações do sistema também precisam ser testadas. Assim, deve-se dar importância aos testes de software no sentido de observar o cumprimento dos requisitos

5 tanto do ponto de vista do que o software deve executar como igualmente aquilo que não deve executar, ou não deve deixar fazer. DEFAULT é exemplo de requisitos de domínio que funcionam como restrições e estabelecem parâmetros de prevenção. Estima-se que cada erro encontrado após a entrega do produto de software custe US$100,00, contra os US$0,10 na especificação. Talvez não dê para evitar 100% dos erros e inconsistências possíveis em softwares, mas deve-se trabalhar com a expectativa de que quanto maior o investimento em testes de depurações de softwares, maior será a qualidade, inclusive a prevenção de defeitos e operações de conseqüências imprevisíveis e irreversíveis. DESENVOLVIMENTO E TESTES Modelos de desenvolvimento de software procuram antecipar erros e corrigir defeitos do produto software. Entre as ferramentas ou mecanismos de Testes temos: PROTOTIPAÇÃO (Modelo Espiral), VERSÃO BETA (Modelo RUP), RELEASE (Modelo RUP), IMPLANTAÇÃO SEGMENTADA. PROTOTIPAÇÃO: O protótipo é um meio de mostrar aos usuários a definição do produto de software em tela para que o mesmo avalie se os requisitos foram compreendidos pelo engenheiro de software. O protótipo não é um produto acabado e, portanto, deve-se ter todo cuidado para que usuários e analistas não se deixem convencer de que o mesmo já é o produto final acabado, o que evitaria posteriores melhoramentos e depuração de

6 requisitos. O protótipo distingue-se de um Demo, por exemplo, exatamente porque este, ainda que seja uma parte de um produto, já executa todas as funções. Neste sentido, o modelo de desenvolvimento que concebe o protótipo como ferramenta de qualidade, o MODELO ESPIRAL (proposto por Pressman), é composto por ciclos onde os protótipos são usados para avaliação do usuário, análise de requisitos do engenheiro de software, decisão de continuar ou não o modelo proposto, novo desenvolvimento do produto e nova avaliação do usuário até a depuração e implementação do produto. VERSÃO BETA: No MODELO RUP (Processo Unificado Racional), os testes de software são marcos importantes da fase de Construção e Transição. Na fase de Construção TESTE BETA deve ser desenvolvido e um projeto de treinamento e depuração do sistema deve ser preparado. Basicamente as versões de teste beta do produto podem ser executadas em ambientes e momentos diferentes: uma primeira versão deve ser alvo de uma bateria de testes em ambiente de desenvolvimento; a segunda versão deve ser alvo de uma bateria de testes com base em bancos de dados reais emprestados do ambiente de trabalho dos usuários; na terceira versão os testes devem ser realizados pelo usuário em seu ambiente de trabalho a visão de terceiros é fundamental nesta etapa de testes. Na fase de Transição (RUP) o RELEASE do produto de software deve ser submetido à depuração do usuário e o plano de implantação definitiva do software deve ser executado. O

7 Release ainda é parte do processo unificado. Logo pertence ao projeto de software já elaborado. O Release é o estágio final de depuração em ambiente real e concreto de trabalho dos usuários. Ele serve de ensaio para a implantação do produto acabado mas ainda não é o produto acabado! -, a partir do qual se executa o treinamento final dos usuários e se define o CRONOGRAMA DE IMPLANTAÇÃO. IMPLANTAÇÃO SEGMENTADA: Apenas se deve ter cuidado para um princípio geral de implantação de sistemas: o cronograma deve prever que ainda depurações de requisitos podem acontecer nos primeiros momentos de pleno funcionamento do produto no ambiente operacional da empresa. Assim, o sistema deve ser implantado de forma total (ou modular se for constituído por vários programas) em um único lugar. Só depois de amplamente usado em um único lugar é que se deve estender a implantação para vários departamentos da empresa. Daí para frente o ciclo de vida deve se dedicar às manutenções de atualização mercadológica e tecnológica quando necessário o que não retira o compromisso dos profissionais de tecnologia com o produto e seus usuários. TÉCNICAS DE TESTES DE SOFTWARES Para serem eficazes, os testes devem ser cuidadosamente desenhados e planejados. Testes irreproduzíveis e improvisados devem ser evitados. Durante e após a realização dos testes, os resultados devem ser inspecionados pela comparação dos resultados previstos e obtidos. Preferencialmente testes devem ser efetuados por outros engenheiros de testes.

8 Existem basicamente duas maneiras de produzir testes: Testes de CAIXA BRANCA são aqueles que procuram identificar defeitos na estrutura interna, isto é, erros de programação em código algoritmo. Devem-se experimentar vários caminhos de execução testes de caminho. Devido à complexidade de uso do produto, pode ser difícil detectar defeitos estruturais em todas as rotinas internas do produto, pois existe um número praticamente infinito de possíveis combinações com loops. Mas cada caminho deve pelo menos uma vez ter sido executado nos testes de estrutura. Testes de CAIXA PRETA são os que procuram detectar falhas nas funcionalidades e não conformidades aos requisitos estabelecidos no documento homologado. A forma original dos engenheiros de testes trabalharem é coletar um conjunto de dados de entrada e verificar as saídas previstas de acordo com o projeto. A dificuldade é selecionar um conjunto de entradas ótimas, o que muitas vezes se faz pela experiência do engenheiro de testes. Ferramentas automatizadas para execução de testes de software utilizam conhecimentos heurísticos a partir desses conhecimentos de domínio dos engenheiros de testes de software. Nos testes de caixa preta os conjuntos de entradas devem contemplar elementos inválidos e verificar se as saídas ainda assim são as especificadas para o funcionamento de programa. TESTES DE INTEGRAÇÃO precisam ser efetuados quando a bateria de testes já foi efetuada em seus componentes individuais. Um sistema provavelmente apresenta conexão com outros componentes ou módulos, o que potencializa

9 substancialmente o esforço de testes de software, pois todos os caminhos de conexão precisam ser testados (se o que se espera que A provoque em B, C, D etc, e vice-versa, o que cada um destes componentes autoriza e atualiza nos demais). Neste caso pode-se testar essa integração com duas metodologias diferentes: TOP-DOWN e BOTTOM- UP. A primeira tarefa a fazer é definir o que seriam os processos de NÍVEL SUPERIOR e o que seriam os processos de NÍVEL INFERIOR (ou mais simplesmente quais os componentes ou módulos do sistema que são principais e quais os que derivam deles, os secundários). Esta tarefa também pode não ser muito fácil já que aquele componente de software que é Nível 1 para um usuário pode ser o Nível 2 para outro. De qualquer forma uma prioridade deve ser definida no teste. Depois, podese escolher ir testando dos níveis superiores para os inferiores em cascata (Nível 1 para o Nível 2 e assim sucessivamente) metodologia Top-down-, ou escolher o caminho inverso, metodologia Bottom-up. Para testar a integração em um produto de software as duas metodologias devem ser usadas exaustivamente. CONCLUSÃO A qualidade do produto software resulta tanto maior quanto maior for a dedicação aos testes, pois muitos erros estruturais, ou de Caixa Branca, estão relacionados à deficiência na compreensão das regras de negócio e, consequentemente, na homologação de requisitos, bem como à integração entre as várias funcionalidades do produto. Muitas

10 vezes ocorre que a integração entre componentes de software se dá através de módulos ou subsistemas que servem de interfaces. Os erros de interface são muito comuns em sistemas complexos (p.ex.,erp). Existem interfaces para parâmetros comuns, bancos de dados compartilhados, dependência ou encapsulamento de procedimentos e passagem de mensagens. Finalmente os engenheiros de testes e os testadores de forma geral devem ter presente que as operações diárias dos clientes/usuários levam os sistemas a desempenharem suas funções sob pressões em ambientes ou momentos de estresse. Nessas oportunidades o desempenho e a confiabilidade se dão pela capacidade dos softwares responderem sob carga total. Em determinadas circunstâncias a carga colocada no sistema excede o máximo previsto. Nestas circunstâncias a falha no sistema, previsível, não deve ocasionar a corrupção de dados ou perda de serviços considerados imprescindíveis (esta talvez seja uma forma de definir os níveis de importância dos componentes de software). Aqui os testes devem verificar a dimensão do estrago ocasionado pela carga excedente, projetando-se os produtos para que as falhas quando de situações reais de estresse sejam as mais brandas possíveis. BIBLIOGRAFIA PRESSMAN, Roger S. Engenharia de Software. 5ª ed. São Paulo: Makron Books, SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003.