Testes em softwares são necessários para diminuir bugs

Rapidez na realização dos testes de softwares não pode comprometer qualidade do que é entregue ao cliente, alertam profissionais em evento on-line.

 

No fim de agosto, o Tribunal Superior Eleitoral (TSE) divulgou as regras para o sexto teste de segurança das urnas eletrônicas, processo criado ainda em 2009 e que exige um exame detalhado de hardware e software da urna eletrônica. Até o fim de novembro, os investigadores terão que inspecionar os códigos-fontes dos sistemas e apontar eventuais bugs ou, numa linguagem bem popular, erros ou panes da plataforma.

 

Testes e qualidade de software, assunto em alta na capital do Brasil e no mundo todo, foi também o tema do recente DevTalk – evento on-line promovido pela Associação das Empresas Brasileiras de Tecnologia da Informação (Assespro-PR). De maneira mais detalhada, Paulo Gevaerd, da Beholder Company, e Everton Arantes, da Prime Control, apresentaram aos participantes conceitos que vêm assegurando qualidade e avanços.

 

“O tema [testes de software] é crítico. Afinal, é fundamental que os bugs sejam evitados e que cada vez mais os softwares apresentem qualidade e excelência, pois isso melhora a relação com os usuários, clientes e a própria rentabilidade da empresa desenvolvedora. Assim, ela evita retrabalhos e reduz a sustentação”, disse Lucas Ribeiro, presidente da Assespro-PR.

 

O teste do software é a investigação que fornece as informações sobre sua qualidade em relação ao contexto em que ele deve operar. Em um mundo cada vez mais digital e acelerado, o desafio dos testadores é entregar o programa “redondinho”, sem os tais bugs, que, na linguagem da informática, quer dizer um pouco mais que simplesmente um erro. Na literatura, um bug de software é conceituado como uma falha em um programa de computador/sistema que faz com que ele produza um resultado incorreto e se comporte de maneira não intencional. “Não existe uma solução milagrosa, embora ao longo dos anos a forma de se fazer os testes tenha mudado bastante. O grande desafio é entregar mais rápido e com qualidade”, destacou Everton. A saída, apontou Paulo, é a organização. “Se o processo de qualidade está implementado, existe uma maior chance de garantir essa qualidade”.

 

Na prática, é o cliente que vai perceber o bug, mesmo sem saber que se trata de um erro identificado pelos programadores. Por exemplo, sabe aqueles segundos entre o Menu e a transferência bancária do seu banco? Esse mínimo tempo é considerado uma eternidade para a programação e pode indicar uma (enorme) falha. “Na Web, esperar três segundos é normal. No aplicativo, isso é muito”, afirma Everton.

 

Como Resolver

A tecnologia vem salvando a tecnologia. Entre outras sugestões, baseados em suas experiências, Everton e Paulo citaram dois programas simples que podem ser usados para a automação de testes, além de automação de processo robótico também. O Robot Framework, definido por Everton como “uma das melhores e mais simples ferramentas para automação”, é aberto, extensível e pode ser integrado virtualmente a qualquer outra ferramenta para criar soluções de automação. Além disso, ele tem sintaxe fácil, com recursos que podem ser estendidos por bibliotecas implementadas com Python ou Java.

 

Outra opção apontada é o Cypress, um novo framework de testes de código aberto e de fácil configuração, que dispensa a necessidade de baixar ferramentas e bibliotecas separadas para configurar seu conjunto de testes. Sua curva de aprendizado é bem menor e seus scripts são escritos igualmente via JavaScript. “O Cypress é outra ferramenta que vem crescendo bastante”, destacaram os profissionais no DevTalk.

 

Medindo o Erro

As métricas têm apenas uma regra. “O número de bugs dentro de casa [da empresa de TI] precisa ser maior do que fora dela”, disse Everton. Isso quer dizer que se for para dar algum problema, que isso ocorra sem afetar a qualidade de vida dos clientes. “No caso da métrica interna, é para saber como está a qualidade dentro de casa. Na externa, preciso questionar: como está a qualidade para o meu cliente, para quem usa minha solução? É preciso comparação, ou não se tem uma base. Bugs por hora de desenvolvimento, por exemplo, por story point, bug/hora. Mas, você precisa saber se está melhorando ou piorando”, afirma.