ARTIGO ORIGINAL
COSTA, Karla Monalize [1]
COSTA, Karla Monalize. Como Implementar Testes De Impacto Eficazes?. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 06, Ed. 04, Vol. 13, pp. 185-193. Abril de 2021. ISSN: 2448-0959, Link de acesso: https://www.nucleodoconhecimento.com.br/tecnologia/implementar-testes
RESUMO
A área de desenvolvimento de software possui, como um de seus pilares de construção, profissionais da qualidade de sistemas que fortalecem o produto e fazem com que ele seja bem-visto pelo mercado de atuação. Uma das dificuldades do cotidiano de um analista de qualidade é montar cenários de testes que tenham como finalidade, não somente garantir a correção de uma falha ou, a implementação de uma nova funcionalidade, mas também de abranger o sistema de ponta a ponta. O objetivo de realizar testes de impacto é proteger o software de execuções realizadas pelo usuário que não foram avaliadas e que podem se tornar as causas dos próximos bugs detectados. Esse estudo, traz a metodologia, para alcançar esse objetivo, em forma de processo de teste desenhado em etapas de estudo do sistema que, está sendo desenvolvido ou que, está passando por uma manutenção. A primeira etapa, é de mapeamento do sistema, onde o profissional avalia a sua arquitetura, a forma como foi desenhado e suas funcionalidades. A segunda etapa, é onde deve ser validado o contexto atual do software (evolução, correção, adaptação ou manutenção). Paralelo ao estudo do contexto, o profissional deve avaliar as técnicas de testes mais assertivas com a situação atual do sistema. O resultado da eficácia dos testes de impacto fica presente na união do mapeamento das funcionalidades com o conhecimento do produto e sua área de negócio, fazendo com o profissional consiga executar os testes, garantindo o alcance aos pontos mais críticos do sistema.
Palavras-chave: Qualidade, Sistemas, Testes.
1. INTRODUÇÃO
A área de atuação de testes de software está crescendo muito nas empresas de tecnologia, e consequentemente os processos de testes estão sendo reconhecidos e requisitados. Mas estudos relacionados ao tema vêm sendo tratados desde 1979, quando o conceito de teste de software ganhou visibilidade com o livro de autoria do cientista Glenford Myers, intitulado “The art of software testing” (A arte de testar software). Claro que, até as primeiras invenções tecnológicas passaram por testes, afinal, como saberiam os inventores se os seus feitos realmente atingiram o objetivo inicial se não tivessem sido testados? Hoje é difícil dizer que algo não foi testado, e isso não engloba somente o mundo dos softwares. Tudo o que consumimos, em algum momento de sua produção, passou pela fase de testes.
O que provoca grandes discussões nas equipes de desenvolvimentos tecnológicos é justamente a cadência das execuções de testes, como definir o processo dessas execuções dentro de uma equipe, quais as técnicas que devem ser utilizadas, como deve ser o ambiente submetido às execuções e, por fim, como combinar tudo isso com a realidade da equipe? Glenford Myers trouxe um dos primeiros conceitos de testes, tal qual ainda se encaixa nas novas metodologias. Myers (1979) definiu testes de software como um processo ou uma série de processos projetados para garantir que o código faz o que foi especificado para fazer, sendo assim um programa previsível e consistente para os usuários.
A qualidade dos softwares que inicialmente só era medida quando o programa estava desenvolvido por completo, teve seu processo evoluído e não muito tempo depois dos primeiros conceitos sobre execuções de testes surgirem, os processos de desenvolvimento foram sendo modificados e quebrados em partes. O teste não trouxe desafios somente para quem codifica um sistema, mas também mostrou que muitas especificações apresentavam imperfeições.
2. MAPA DO SISTEMA
Antes de qualquer estudo, é preciso ter em mãos o mapa do sistema onde serão executados os testes. O ideal nessa primeira parte do estudo seria que todos os sistemas tivessem uma documentação da arquitetura visual do sistema, com suas ramificações de botões, ações, funções, mensagens e qualquer detalhe que seja visual ao usuário. Geralmente são utilizadas ferramentas de gerenciamento de modelagem e design baseadas em UML (Unified Modeling Language) onde são criados diagramas que representam cada particularidade visual, como por exemplo, uma tela, um botão ou uma mensagem. As ferramentas de modelagem são ótimas para ir além da parte visual do sistema, pois nelas, é possível criar diferentes diagramas para qualquer parte do sistema.
Caso o sistema de atuação não tenha esse tipo de documentação arquitetural, busque outras fontes. Documentos que contenham regras de negócios também são ótimos esclarecedores de dúvidas nessa primeira abordagem. Nessa hora até mesmo um escopo de projeto que foi entregue ao cliente ajuda. O importante é ter uma fonte com a qual possam ser retiradas as dúvidas sobre determinadas funcionalidades e partes do software.
3. TIPOS DE MANUTENÇÃO DE SOFTWARE
Após o estudo do sistema e suas especificações, o responsável pela qualidade do software deve analisar o que será testado de acordo com a fase atual do ciclo de vida do software, gerando resultados ainda na etapa de manutenção que o sistema está para receber.
Sommerville (2007) trouxe em seus estudos os tipos de manutenção: evolutiva, corretiva e adaptativa. E Pressman (2006) complementou trazendo o conceito de manutenção preventiva ou reengenharia. Quando o assunto é engenharia de software esses são os conceitos de manutenção mais aplicáveis até hoje. Essa definição de manutenção de software possibilita que as empresas tenham uma nova forma de organização dentro das equipes que atuam com o desenvolvimento e produção dos sistemas, onde podem existir times dedicados por tipo de manutenção. Mas também existem os casos em que as equipes são separadas por especialidades (contextos) do sistema. Cada modo de separação tem suas vantagens e desvantagens, porém, para a qualidade (e para os responsáveis por ela) do sistema, a separação das equipes de desenvolvimento por tipos de manutenção simplifica a tratativa dos testes, já que cada equipe fica responsável por apenas uma fase do ciclo de vida do software.
Os tipos de manutenção de software definem e restringem muitos pontos dentro do sistema. Por exemplo, definem os processos e prazos de entrega, e restringem a qualidade por estudos e técnicas a serem utilizadas nas execuções de testes. A ideia de dividir as técnicas de testes por tipos de manutenções, quando o ciclo de vida do programa é monitorado por um analista de qualidade que conhece a melhor maneira de executar um teste para aquela fase específica, dobra a qualidade e o risco de entregar um sistema com erros é cortado pela metade.
3.1 TÉCNICAS DE TESTES PARA MANUTENÇÃO EVOLUTIVA
Segundo Sommerville (2007) a manutenção evolutiva é responsável pelas modificações do software que tem por objetivo maior adicionar funcionalidades. E se tem algo que um analista de qualidade de software gosta é testar novas funcionalidades.
Quando o software está sendo modificado e ganhando novas funções, a principal técnica de teste a ser aplicada é a técnica de teste funcional (também conhecida como teste de caixa preta). O teste funcional tem foco nas entradas e saídas, ou seja ao utilizar essa técnica o analista de qualidade tem atenção redobrada nos dados inseridos e emitidos pelo software. Durante o uso dessa modalidade de execução de testes, o analista utiliza como material de apoio o documento de especificação de requisitos de software (ERS), pois a partir dele é possível saber os dados que o sistema aceita e o que ele pode exibir de resultado para o usuário. O teste funcional combina com qualquer tipo de manutenção, contudo por ser uma técnica que usa como método a especificação de uma nova funcionalidade, ela se torna inevitável na evolução do produto.
Como é comum na manutenção evolutiva o software ganhar novas funcionalidades ou até mesmo ter sua interface visual modificada, outra técnica aliada nessa etapa é o teste de usabilidade. Ele é feito já na última fase do ciclo de vida de evolução, ou seja, na aceitação, e por esse motivo se torna uma técnica que pode ser aplicada também pelo usuário final do software. Essa prática é muito comum quando se trata da implantação de um novo sistema para um grupo de usuários, ou da homologação de uma nova versão de um sistema legado, que possui uma interface distinta ao modelo visual já conhecido pelos usuários do produto. É uma técnica mais exploratória, ou seja, é importante que, caso a fase de aceitação seja executada ainda pela equipe de desenvolvimento (e não pelo usuário final), o perfil do analista de qualidade deve ser bastante investigativo. O testador também deve ter domínio sobre a rotina dos usuários, para facilitar na intenção de encontrar falhas antes da entrada do sistema no ambiente de produção do cliente.
3.2 TÉCNICAS DE TESTES PARA MANUTENÇÃO CORRETIVA
Para Pressman (2006) a manutenção corretiva tem como objetivo reparar erros que não foram identificados na fase de teste. Esses erros podem ser bugs que já foram detectados em outras fases, e que, no entanto, não apresentavam um impacto muito grande no resultado esperado, não demandando urgência. Também podem ser encontradas falhas sobre comportamentos não avaliados na especificação do software e que trouxeram grande impacto para os usuários, e nesse caso a correção precisa ser urgente.
Na execução dos testes após uma correção é imprescindível que seja aplicada a técnica de teste de regressão. A principal característica dessa técnica é que ela é composta por um conjunto de cenários de testes onde todos eles devem ser executados garantindo o comportamento do software (já esperado pelo usuário final). Esse modo de execução utiliza como material de apoio, cenários já detalhados em outros ciclos de vida do software, e pode ser aplicado até mesmo por um analista de qualidade que não tenha muito conhecimento sobre o software, desde que ele siga o que já foi especificado. Na manutenção corretiva, o teste de regressão pode ser combinado também com o teste funcional, porém nesse caso, o teste funcional pode ser aplicado apenas sobre as funcionalidades que sofreram alteração, somente para garantir que a interface, o comportamento e o desempenho do software naquela determinada unidade continuam apresentando o resultado esperado pelo usuário, sem mudanças de regras de negócio.
3.3 TÉCNICAS DE TESTES PARA MANUTENÇÃO ADAPTATIVA
Pressman (2006) define a manutenção adaptativa como o ciclo de vida no qual é necessário realizar adaptações no software, para acomodá-lo às mudanças que o ambiente externo a ele está exigindo. Essas mudanças podem ser voltadas para as regras de negócio, constituição ou até mesmo para a legislação. Além dessas opções, podemos citar também como um agente de mudança para a manutenção adaptativa, as atualizações dos sistemas operacionais utilizados pelas máquinas dos usuários.
Para a manutenção adaptativa, uma técnica que convém ser utilizada é o teste estrutural, também conhecido como teste de caixa branca. Não é muito comum um analista de qualidade utilizar essa técnica, já que, dificilmente esse profissional tem acesso (e conhece) ao código fonte, e nesse caso a técnica é aplicada diretamente nos componentes do código pelo próprio implementador. O objetivo principal dessa técnica é testar a confiabilidade do programa conforme o que foi especificado, pois o implementador analisa unitariamente os componentes que foram alterados.
Um outro método que pode auxiliar e acrescentar garantia nas execuções dos testes após a manutenção adaptativa ser realizada, é o teste de segurança. A característica principal dessa técnica é de testar a vulnerabilidade do sistema, sendo assim é uma importante aliada para quando o programa sofrer alguma mudança complexa (na regra de negócio, por exemplo). Outras funções pertinentes a esse modo de execução é de, caso sejam detectados falhas de segurança, os mantenedores possam preparar medidas de contingência para as falhas encontradas.
3.4 TÉCNICAS DE TESTES PARA MANUTENÇÃO PREVENTIVA
Pressman (2006) trouxe para a engenharia do software o conceito de manutenção preventiva, que é o ciclo de vida em que são necessárias alterações na estrutura do produto a fim de facilitar os outros tipos de manutenções. Por exemplo, uma refatoração no código fonte, se encaixa nesse tipo de manutenção.
Para essa manutenção, uma técnica de teste que se encaixa perfeitamente e que já foi citada na manutenção adaptativa, é o teste de caixa branca. Sobretudo é necessário aplicar outras duas técnicas cuja principal característica é avaliar o desempenho do sistema mediante às mudanças.
A primeira técnica a ser citada para essa fase, é o teste de carga. O objetivo dessa técnica é testar os limites de tempo que o software leva para trazer as respostas das transações. Esses dados são avaliados e devem ser comparados com o desempenho do software antes de receber a alteração e assim o analista de qualidade avalia se o sistema manteve ou até mesmo melhorou (caso a melhora seja uma das metas da manutenção) o desempenho do produto.
A outra técnica não menos importante para o teste da reengenharia, é o teste de estresse. O teste de estresse também é conhecido como uma ramificação do teste de carga e por isso as duas técnicas se tornam complementares. Esse modo de execução se aplica na simulação de problemas fazendo com que o analista de qualidade possa avaliar o comportamento do sistema mediante as falhas. Por exemplo, um operador está emitindo uma nota fiscal em um software de gerenciamento de negócios industriais e o servidor cai no meio da operação. Os dados que já foram preenchidos são salvos (conforme a especificação do produto) para que o usuário continue o preenchimento ou ele deve iniciar a operação novamente? Se ele perdeu seus dados, não obedecendo a especificação, o analista de qualidade já pode considerar como uma falha do produto causada pela manutenção preventiva.
4. TESTES DE IMPACTO EFICAZES
A análise dos pontos mais críticos do sistema deve ser levada em consideração na construção da escrita de casos de testes, cenários e scripts de execução, e isso vale para qualquer tipo de manutenção. A implementação de testes de impacto é a soma de um cenário crítico com técnicas de testes complementares. Quando automatizamos um teste seguindo um caso de teste de um cenário crítico do software, devemos analisar alguns critérios. Primeiro, deve-se analisar o objetivo da automação, e em seguida o ciclo de vida do sistema no qual será utilizada. Se o objetivo é agregar agilidade em um teste de regressão de uma manutenção corretiva, será que não é possível agregar outra técnica de teste nesse desenvolvimento? Por exemplo, complementar a automação que será utilizada em um teste de regressão, com um teste de carga, é uma ótima maneira de adicionar qualidade em um só teste.
5. CONCLUSÃO
A combinação de técnicas de testes para a qualidade do software gera muitos benefícios que não estão inclusos somente na qualidade do produto. A própria análise de dois testes de técnicas diferentes pode gerar manutenções distintas ao programa, e isso não é benéfico somente para a equipe de desenvolvimento mas também para o cliente, afinal, tipos de manutenções diferentes podem ter custos diferentes também.
Quando o software é um sistema legado, ou seja, é um produto de manutenção com alto custo, o trabalho do analista de qualidade se torna ainda mais protagonista no desenvolvimento. Isso porque quanto mais legado é o sistema, mais complexo ele se torna, e com isso a intenção de encontrar falhas, bugs e erros antes do cliente deve ser primordial levando em consideração que o cliente está pagando caro pelo serviço. Para a equipe, quanto mais detalhes são encontrados na fase de teste do sistema que é legado, torna-se benéfico pois diminui a incidência de manutenções urgentes (aquele famoso “apagar incêndio”), deixando mais tempo para evoluir o produto.
A intenção de promover a combinação de técnicas de execuções de testes traz uma nova forma de trabalhar os dados e o conhecimento que o analista de qualidade tem com o produto. Muitas vezes a falha do profissional está na forma com que ele trabalha as informações e não por não ter as informações corretas sobre o produto.
REFERÊNCIAS
MYERS, Glenford J. The Art of Software Testing. 1.ed. Wiley, New York, 1979.
SOMMERVILLE, Ian. Engenharia de software. 8.ed. São Paulo: Pearson, 2007.
PRESSMAN, Roger S. Engenharia de software. 6.ed. São Paulo: McGraw-Hill do Brasil, 2006.
PAULA FILHO, W. P. Engenharia de software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2001
ROCHA, A. R. C. MALDONADO, J. C.; WEBER, K. C. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001.
[1] Graduada em Gestão da Tecnologia da Informação.
Enviado: Fevereiro, 2021.
Aprovado: Abril, 2021.
