Developers da Play Store vão ter de permitir a eliminação de dados e contas nas apps Android
Abril 6, 2023Minimalista, mas desafiante. orange é um jogo com quebra-cabeças num universo cor de laranja
Abril 6, 2023Por Francisco Lopes (*)
Bom, na realidade, precisamos sempre de testar o nosso software se queremos otimizar os recursos e evitar prejuízos. No entanto, o mais importante é definir que tipo de análise vamos realizar ao nível de Quality Assurance e que processos são verdadeiramente necessários para o fim que procuramos. Pegando no ditado sobre figuras geométricas, permitam-me afirmar que todos os testes de software são necessários, mas nem todos os softwares necessitam dos mesmos testes.
De testes unitários a end-to-end, passando pelos de integração e manuais, cada tipo envolve esforço humano e tempo na criação do caso a avaliar, pelo que será mais acertado conhecer do que se trata cada um para entender qual o mais indicado ao software em causa.
É verdade que podemos aferir todo o tipo de cenários e é importante até simular o pior dos cenários, de modo a desenhar um melhor software e a prevenir prejuízos: de acordo com um estudo do Consortium for IT Software Quality, em 2022, as empresas nos EUA perderam 2.08 milhões de dólares por não realizarem processos de Quality Assurance adequados. Ainda assim, há casos em que não é necessário testar o software – pelo menos, da mesma forma como se avaliou outro. Tal como adaptamos as ferramentas utilizadas para trabalhar, também a análise desenvolvida deve ser realizada de acordo com a sua finalidade.
Os testes unitários verificam apenas um pedaço de código. Por isso, é preciso perceber se o esforço de escrever o processo de aferição é ou não maior do que o de escrever o próprio código. Além disso, se o código que queremos rever está apenas a resolver um problema temporário – quase como um “penso rápido” a colar o caso -, será mais vantajoso analisar a solução final a implementar depois disso, e não a resposta temporária.
Olhando para os casos em que queremos aferir diferentes sistemas em conjunto, os testes automáticos de integração serão a melhor resposta. Mas, mesmo nestes casos, é fundamental tomarmos atenção ao tempo dispendido a fazer todo o set up do processo de verificação. Pode ser mais relevante integrar aqui um teste manual, uma vez que a automação poderá responder com menos rigor ou, até, criar erros.
Sobre os testes manuais, convém referir que são mais úteis caso estejamos a rever um software do ponto de vista do utilizador, tanto ao nível da interface (UI) como da experiência (UX). O nível de detalhe a que conseguimos chegar é bastante mais elevado, uma vez que estamos focados num caso muito específico, o que permite desenvolver uma solução com maior qualidade.
Já os testes end-to-end, como o nome indica, reveem o processo de A a Z. No fundo, são vários testes de integração conjuntos, que permitem aferir o software com muito mais detalhe – mas, também pela dimensão, mais dispendiosos. A morosidade que exigem vai impactar a agilidade da equipa e, por isso, é particularmente importante avaliar a priori custos e benefícios destes processos de análise, para tomar a decisão mais equilibrada.
No fundo, devemos estar alerta para os custos e os benefícios que cada tipo de teste de software envolve. Cada caso é um caso – assim como as soluções que programamos e que, reforço, devem ser sempre analisadas: só através deste processo conseguimos antecipar dificuldades no uso do nosso software, podendo otimizá-lo e criar algo com mais qualidade.
Podemos cometer o erro de pensar que previmos todos os cenários, passando esta fase à frente ou encurtando os testes feitos, mas a pressa é inimiga da perfeição e a componente de imprevisibilidade no software pode ter consequências desastrosas para o nosso produto. A implementação desta análise, tanto através da mão humana como da automação, é fundamental para reduzirmos a probabilidade de erros críticos e de custos que poderiam ter sido evitados.
(*) People Lead & Expert Software Engineer na Zühlke
