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 nos hardwares e softwares 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 em softwares, 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 softwares] é 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.
1. Como resolver
A tecnologia vem salvando a tecnologia e seus softwares. 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.
2. Medindo o erro
As métricas têm apenas uma regra.
“O número de bugs dentro de casa de uma 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.
