Desenvolvimento

Ξ 1 comentário

Os Testes nossos do dia-a-dia

publicado por Setembrino Lusa

Muitos dos profissionais de TI, e por conseqüência as organizações em que executam seus trabalhos têm percebido a importância e necessidade de se testar os sistemas, integrações e trabalhos que executam e desenvolvem.

A pouco tempo atrás o que se tinha como regra era o empirismo como forma de desenvolvimento de software, com o advento das metodologias iterativas e hoje, das metodologias ágeis, a necessidade de testes bem estruturados e planejados é muito mais visível, pois, qualquer artefato de um software deve poder ser repetido e o que pode atestar esta garantia são os testes.

Infelizmente esta percepção só tem aparecido com mais força agora devido ao aumento exponencial da complexidade das aplicações atualmente desenvolvidas, cuja funcionalidades não se resumem a gerenciamento de dados armazenados em uma única fonte de dados, como era anteriormente, mas o acesso além dos dados, como outras aplicações sendo executadas local ou remotamente, em tempo real ou com assincronicidade, tendo ou não intervenção humana na sua execução.

Com isso, desenvolvedores, analistas, arquitetos e todos os envolvidos no planejamento e desenvolvimento de projetos de software têm atentado para a execução de teste que garantam o funcionamento adequado das aplicações, softwares e sistemas em que estejam envolvidos.

Contudo, essa “descoberta” tardia se deve muitas vezes tardiamente, após o deploy feito prematuramente e aos “bugs” que aparecem misteriosamente na utilização do sistema pelo usuário final, ou quando o sistema é “colocado em produção”, acarretando um esforço gigantesco para colocar testes sobre algo já pronto e muitas vezes desconhecido pela equipe que deve agora gerar os testes. Ainda, a pior das situações é quando um sistema recém “posto em produção” afeta um sitio inteiro de outros sistemas, onerando uma parada total de um servidor, quando não de vários deles.

Como agir então quando se tem uma nova aplicação iniciando sua vida na empresa ?

Hoje existem metodologias direcionadas para testes, metodologias ágeis, metodologias não ágeis, contudo todas contemplam a disciplina de testes e propõem cenários para tal, como testes de performance, testes de regressão, testes unitários o mais cedo possível no desenvolvimento, etc. então, o que se deve utilizar em todas as situações é o bom senso e uma estratégia que garanta que sua aplicação será implantada e funcionará corretamente.

As estratégias de teste também tem surgido e se especializado muito rapidamente, assegurando a correta construção e manutenção dos sistemas. Contudo a correta utilização destas ainda é algo desconhecido do conhecimento comum, pois quando desenvolvedores se deparam com uma demanda por testes, sejam eles unitários, funcionais ou de performance, ainda ficam buscando respostas e conceitos circulando em volta do marco zero, sem avançar muito, e é neste ponto onde muitos acabam por desistir dos testes imaginando ser muito complexo ou que ninguém ainda sabe fazer, pois não acham conteúdo nem conhecimento facilmente.

Vamos analisar algumas estratégias e macetes para alguns dos testes mais comuns, abrangendo testes unitários, funcionais e de performance:

Em testes unitários no mundo ideal, deveria se atingir toda e qualquer linha de código escrita para que se tenha 100% de cobertura, contudo, com a correta construção de classes “mock”, ou classes de mentirinha, que emulam as respostas corretas e incorretas necessárias para que ao menos os métodos críticos de negócio sejam cobertos, já se tem um avanço significativo para a qualidade do código.

Em testes funcionais, também no mundo ideal, deveriamos cobrir cada funcionalidade na sua totalidade, prevendo e manipulando dados e cenários para que todas as situações e nuances fossem cobertas pelos testes, contudo com a devida atenção aos dados e pré-condições dos cenários críticos de negócio, aonde o “caminho feliz” seja totalmente coberto atentando e muito, mas muito mesmo para a união destes scripts funcionais por funcionalidade resultem em um teste geral de regressão, incremental a cada novo build, é possível garantir a qualidade de um sistema em construção. Ainda, o intuito dos testes funcionais é também, mas não totalmente excluir os testes manuais, pensar que teste funcional é somente substituir os testes manuais é um dos maiores erros que se pode cometer, pois em uma automatização de testes manuais esquece-se das nuances de um usuário HUMANO, que clica aonde ninguém imaginou que um usuário clicaria, que preenche a informação de maneira equivocada, que executa uma ordem de operações que analista nenhuma jamais imaginaria ser possível. Ou seja, testes manuais ainda são impressindíveis. Faça um teste, escolha sua melhor tela ou funcionalidade e peça para que um leigo a teste sem roteiro ou informação nenhuma, você provavelmente ficará com uma expressão de nunca ter visto aquilo acontecer no seu sistema.

Já em testes de performance, a complexidade fica mais evidente, contudo é algo como andar de bicicleta, só se faz bem com a prática e feito bem uma vez, nunca mais se esquece. Muitos criam testes para assegurar performance, como se estivessem criando scripts para teste funcional, um grande erro, para performance não interessa se a aplicação está com bug, falta alguma coisa, tem dados errados, calcula erroneamente seus cálculos, comunica ou não com outros sistemas etc., a única necessidade e pré-condição para se testar performance é lógica, ou seja, ligado/desligado, ou a aplicação está no ar, ou não está, qualquer outra situação DEVE ser mascarada, ou seja, deve garantir que o script gerado possa ser executado até o final.

Duas das técnicas mais utilizadas para o teste de performance são, a busca do ponto de ruptura do sistema, ou seja, executo os scripts com dados e acessos acima do normal para saber qual o momento que o sistema vai ruir, assim consigo garantir o aumento das capacidades de processamento, comunicação, armazenamento, etc. quando o mesmo sistema em produção se aproxima deste ponto. A segunda técnica é a de “ramp-up” ou rampagem, cujo script é executado com tempos e quantidades de usuários simultâneos definidos e crescentes em função do tempo a fim de se descobrir a configuração ideal do ambiente de produção, se a arquitetura do sistema atende ao número de usuários previsto para a utilização em produção, e ainda com uma avaliação mais cuidadosa, necessidades de aumento ou diminuição de hardware para suportar a quantidade de acessos quando o sistema “vier à vida”.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Com mais de 15 anos de vivência em Engenharia de Software, atuando desde o levantamento de necessidades até a finalização, entrega e manutenção de sistemas, consultorias, treinamentos e principalmente na melhoria contínua de processos e metodologias de produção de Soluções Computacionais. Graduado em Análise e Desenvolvimento de Software pela UNOPAR www.unopar.br de Londrina no Paraná. Pós Graduado em Engenharia de Software pela Unifil www.unifil.br também de Londrina no Paraná. Com grande experiência em Implantação, Consultoria e Treinamentos relacionados às IBM Rational em diversos segmentos com as metodologias Formal e Ágil. Forte atuação em projetos de Melhoria de Processos e Implantação em ALM - Ciclo de Vida de Aplicações, tendo atuado em diversas organizações por todo o Brasil, em ambos os setores privado e público. Publicação de um livro sobre Métricas em Projetos de Softwares que desmistifica a utilização das diversas técnicas e aponta as possíveis melhores abordagens de quando e porquê utilizar cada técnica durante as etapas de um Projeto de Software a fim de alcançar o maior resultado com o menor esforço em cada medição e conferência. (https://www.facebook.com/MetricasEmProjetosDeSoftware) Certificações IBM Certified Solution Designer - Rational Performance Tester - RPT IBM Certified Solution Designer - Rational Functional Tester for Java - RFT IBM Certified Solution Designer - RUP IBM Certified Deployment Professional - RPM IBM Certified Associate Developer - Rational Application Developer for WebSphere Software V6.0 - RAD Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 - SCJP

Setembrino Lusa

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.