É desesperador para uma fábrica de software enfrentar a triste e cara realidade de ter que, sem mais orçamento, continuar dando manutenção em sistemas que foram entregues muitas vezes há meses, mas que ainda apresentam muitos bugs que precisam ser corrigidos.
Até hoje não conheci uma empresa que desenvolva sistemas que não tenha passado por isso e, o mais intrigante de tudo é que é totalmente possível evitar e eliminar essa situação. Mas, por que será que, mesmo nos dias de hoje, isso não acontece? Por que será que as empresas ainda sofrem e perdem tempo, dinheiro e tranquilidade com as intermináveis “manutenções” e correções de bugs de sistemas já consagrados? Será que os gerentes e diretores de tecnologia não contabilizam o quanto esses projetos custam ao longo dessas manutenções? O quanto o cliente acaba arcando com esses custos adicionais que, a princípio, não deveriam existir?
Vejo dois principais motivos para essa situação, em que um é consequência do outro: (1) síndrome do “economizo agora a preço de gastar mais depois” e (2) ausência de testes de software em cada uma das etapas de desenvolvimento. A falta de conhecimento a respeito do processo de teste de software e do quão essencial é sua aplicação em cada uma das etapas de construção de um sistema para se garantir qualidade é fatal e arrasta defeitos e indefinições ao longo do projeto que, com certeza terão de ser tratados com os sistemas em produção. Leiam-se consequências desse tratamento como dores de cabeça, mobilização de equipe extra para correções, custos com novas implantações, insatisfação de clientes e usuários finais, multas contratuais e, muitas vezes, o cancelamento do projeto ou sua total reconstrução.
E os custos disso tudo, que não são previstos no orçamento? E o quanto desse custo acaba sendo dividido com o cliente que, sem alternativas, precisa assumir parte dessa responsabilidade?
Como não é possível se evitar algo que já aconteceu, falemos então à respeito de como solucionar a situação. Mesmo com o sistema já entregue e operando em produção, a etapa de execução de testes precisa ser contínua, uma vez que defeitos detectados devem ser reportados, analisados, corrigidos, a funcionalidade retestada e, o mais importante, executar testes de regressão para garantir que novos defeitos não tenham surgidos devido à correção realizada. Agora, por que é que eles existem e são intermináveis? Simples: o que geralmente são corrigidos são os problemas, as falhas, e não seus causadores.
Usarei uma história hipotética como analogia para explicar melhor o processo de teste de software que, muitas vezes, pode ser mais complexo do que parece:
Uma casa foi construída sem um projeto bem definido, mas que, após alguns ajustes, reformas e reconstruções, ela ficou próxima ao desejo de seus idealizadores. Assim que os moradores a habitaram, perceberam que havia uma torneira no centro da parede da sala. Apesar de estranho e totalmente desnecessária, não atrapalhava tanto e acabou ficando por lá devido ao trabalho e custo para tirá-la após as incansáveis e intermináveis reformas já feitas anteriormente; ela ficaria escondida entre os móveis. Após um tempo, os moradores se preocuparam ao se depararem com um novo problema: a torneira estava vazando e danificaria rapidamente o lindo tapete e os móveis feitos sob medida para o ambiente. Reportaram o problema à construtora, alegando que precisavam de uma solução para que seus móveis e tapete não fossem danificados. Retirar a torneira da sala foi uma solução já descartada por todos, uma vez que ninguém tinha mais dinheiro para quebrar parede, retirar a torneira, rebocar, pintar e retocar chão e demais áreas com a reforma, ainda mais não recordando como os encanamentos haviam sido construídos. Qualquer mudança poderia causar muito mais problemas de vazamentos em outros cômodos da casa. Pensou-se então em resolver o problema: se os móveis e o tapete não podem ser molhados, basta colocar um balde sob a torneira que o vazamento não se espalhará. É uma solução rápida, barata e que de fato, evita que os móveis e o tapete da sala sejam molhados e danificados.
Você deve já ter imaginado que essa solução, apesar de simples, rápida e barata, resolveu um problema, mas não a sua causa, e que, pouco tempo depois o problema voltará ainda maior, pois o balde transbordará, molhando mais rápido os móveis e o lindo tapete da sala.
Um analista de teste experiente, diante da situação, com aplicação de técnicas de teste de software logo identificou que a causa do problema era o vazamento da torneira e que precisava ser solucionada o mais rápido possível. Ao especificar o problema devidamente, propôs ações simples que seriam tão baratas e rápidas quanto à solução do balde dada anteriormente: (1) fechar o registro, pois, apesar de não ter a planta da casa, é muito provável que exista e (2) chamar um encanador para trocar a válvula ou a borracha de vedação, pois a chance do vazamento ter ocorrido devido a isso é alta.
Em poucos minutos, o defeito na torneira foi resolvido, o vazamento cessado e o problema solucionado, no mesmo tempo e com os mesmos custos da primeira solução.
Em outras palavras, os bugs apresentados pelos sistemas em produção são resolvidos na maioria das vezes de forma análoga, cujas causas não são devidamente detectadas e reportadas e, consequentemente, novos defeitos, até mais graves, surgirão em pouco tempo, fazendo com que seja interminável o período de manutenção. A equipe de suporte e desenvolvimento geralmente não possuem conhecimento de regras de negócio para identificar as causas dos problemas rapidamente, mas sim possuem habilidades de transformar as soluções sugeridas em soluções implementadas e implantadas. A equipe de teste de software é a mais indicada para identificar relações entre causas e possíveis problemas, devido à sua habilidade de planejamento e criação de cenários de teste positivos e negativos dentro de um contexto, de uma regra, de um ambiente.
Sistemas que apresentam muitos bugs devem possuir uma equipe de teste atuando diretamente na fase de execução de testes contínua com o sistema em produção para (1) analisar falhas reportadas por usuários finais, (2) detectar causador(es) dessa(s) falha(s), (3) reportar o defeito devidamente, explicando o contexto e o que causou a(s) falha(s), (4) testar devidamente o defeito e (5) executar teste de regressão. Com essa atuação certeira, a tendência é ter um sistema cada vez mais estável, com a recorrência de falhas cada vez menor, com custo viável e terminável.
[Crédito da Imagem: Bug – ShutterStock]