Qualidade de software vai alÉm de testes
04/10/2006
Processos de melhoria de qualidade de software reduzem custos de projetos e garantem que o produto final atenderá às necessidades existentes no momento de sua concepção.
Quem conhece aquele jogo de salão chamado telefone-sem-fio sabe o quanto ele se assemelha ao processo de desenvolvimento de um software, do momento em que a solicitação é feita até quando a solução é entregue. Da mesma forma como, na brincadeira de criança, aquela frase ou palavra cochichada pelo primeiro participante se distorce até chegar ao último companheiro da fila, a demanda inicial de um software também é interpretada de diferentes formas em sua trajetória até o desenvolvedor.
Diferente do que muitas empresas ainda acreditam, testes por si só não são a solução para o problema. Especialmente se adotados simplesmente como uma das etapas no processo de criação do software, procedimento ainda muito comum entre desenvolvedores, que, aos poucos, começam a entender a importância de colocar em prática políticas de qualidade e alinhá-las aos processos de testes de soluções.
Essas práticas vêm ganhando um nível de profissionalização cada vez maior, impulsionadas por fatores como o aumento na busca pelo offshore, a instalação de fábricas de software no País e o crescimento de exigências regulatórias como Basiléia 2 e Sarbanes-Oxley. Como resultado, o que se vê é uma enxurrada de empresas, soluções e serviços que prometem automatizar e aprimorar esses processos.
Muitas companhias, porém, tardam em compreender a diferença entre testes e processos de melhoria de qualidade – e as vantagens e implicações para aqueles que os utilizam. “Testes e qualidade estão interligados. Ambos são necessários, mas são coisas diferentes”, decreta Adriano Alves, vice-presidente de tecnologia e serviços da Compuware para a América Latina. Carlos Alberto Caram, diretor-executivo da consultoria ISD no Brasil e América do Sul, concorda: “É um erro achar que a qualidade começa pelo teste.”
Especialista em maturidade de processos de software, especialmente aqueles estabelecidos pelo CMMI, do Software Engineering Institute (SEI), Caram explica que teste é apenas um dos aspectos de um programa de melhoria e qualidade. “O CMMI é garantia da qualidade de processos e produtos”, diz o profissional. “Zero de erro ninguém tem. O que as empresas estão buscando é reduzir esses índices”, afirma o diretor, lembrando que estas companhias precisam começar a investir em regras básicas de gestão do processo como um todo.
Tradicionalmente, o teste de software representa apenas uma das etapas – a final, na maioria dos casos – em seu processo de desenvolvimento. “Muitos desenvolvedores adotam os testes somente no fim do processo de desenvolvimento para ganhar tempo”, revela Alves, da Compuware. Ele explica que, em tese, implementar testes desde o início do desenvolvimento pode parecer mais caro, mas na prática, adotar um ferramental de testes automatizados pode significar mais agilidade e economia ao longo do processo.
Além disso, ainda há muitas organizações que têm nos testes o seu único processo de garantia de qualidade. O que elas não sabem é que o teste não é a solução para os problemas, conforme afirma Luiz Wolf, um dos sócios-diretores da Tech4B, empresa nacional especializada em melhoria de qualidade, desempenho e custos de tecnologia da informação (TI). Citando o especialista e desenvolvedor Michael Fagan, que há cerca de 30 anos, enquanto era funcionário da IBM, criou o processo de inspeção de códigos que levou o seu nome, Wolf diz que os testes respondem pela solução de apenas 20% dos problemas em um software.
Dói no bolso
Por mais exaustivos que tenham sido os testes, por si só, eles não garantem a qualidade do produto final, ainda que até assegurem o seu bom funcionamento. “A exemplo dos carros cerca de 40 anos atrás, muitas empresas ainda testam apenas o produto final”, compara Helio Katanosaka, outro sócio-diretor da Tech4B. “Nesse caso, quando um problema é detectado, o caminho até a sua fonte é longo e custoso.”
Paulo Sérgio Biscardi, diretor de marketing da Spread Sistemas, empresa especializada em avaliação de processos de desenvolvimento, acrescenta que ao deixar os testes para o final do processo, pode acontecer de o desenvolvedor nem lembrar com exatidão o que fez e quando. Quando isso acontece, refazer tudo é a única saída, ainda que seja dez vezes mais caro. Esse é um problema causado também pela falta de boas práticas, que invariavelmente sugerem a documentação de todas as etapas do desenvolvimento.
Caso não tenham sejam seguidos padrões de qualidade e boas práticas, localizar um erro ou um código que deva ser modificado pode tomar muito mais tempo do que se imagina. Exatamente por isso é que os especialistas são unânimes ao afirmar que quanto mais tarde um problema for identificado, mais caro ele custará à empresa.
Osmar Higashi, sócio da empresa de testes de software RSI, estima que um erro detectado na fase de concepção do software custa 1 dólar para ser consertado. “Nesta fase, estamos falando sobre uma alteração em um documento Word, por exemplo”, justifica o executivo. Quando passa à fase de desenvolvimento de código, esse valor sobe para 10 dólares e cresce exponencialmente conforme o processo evolui, superando facilmente o patamar de cinco dígitos uma vez que ele seja encontrado já com o software em produção. “Incluir processos de inspeção ao longo da cadeia de desenvolvimento é uma das formas de evitar que o erro alcance fases avançadas da produção”, sugere Caram, da ISD.
Para garantir que a solução atenda integralmente às reais demandas do negócio e saber, entre outras coisas, até que ponto ela funcionará sem ter seu desempenho comprometido, é preciso mais do que testes. É fundamental a implementação de processos de qualidade ao longo do processo produtivo. Isso porque se a ferramenta não cumprir o prometido, a companhia terá de fazer novos – e altos – investimentos para alterá-la e adequá-la. “A qualidade precisa ser foco desde o começo e é a área de TI que tem de ir até cada um dos diretores para evitar receber a informação errada”, sugere Gary Jerep, consultor da Quest Software, fornecedora de soluções de gerenciamento de aplicações.
“Ao contrário dos testes, os processos de qualidade ajudam não apenas a reduzir os erros presentes no produto final, mas a calcular a necessidade de processamento que um sistema pode demandar do hardware e o quanto uma empresa pode perder pela falta de disponibilidade ou baixo desempenho da solução”, acrescenta Wolf, da Tech4B. Ele conta que, em geral, a maioria das empresas só pára para calcular o prejuízo quando precisa contabilizar o retrabalho. “Hoje os clientes não nos vêem mais como custo, mas como forma de aumentar o seu faturamento. Inclusive porque os testes funcionais não trazem capacidades preventivas.”
Também a Borland, empresa de soluções para a criação de softwares, sente a mudança de visão dos clientes desenvolvedores. “Até pouco tempo, 100% dos clientes nos chamavam para ‘apagar incêndios’”, confidencia José Rubens Tocci, presidente da Borland Brasil. “Agora, muitos começam a se conscientizar sobre os ganhos que os processos de qualidade de software podem trazer ao negócio”, completa.
Enrique Nunez-Ruiz, gerente de vendas da Quest Software para a América Latina, explica que seus clientes começam a medir melhorias de desempenho e demonstrar pró-atividade na forma como contabilizam os resultados. “Nossas ferramentas ajudam a saber quando a solução começará a ter seu desempenho afetado”, destaca.
Quando parar?
Algumas organizações pecam ao enxergar processos de melhoria de qualidade como projetos pontuais, muitas vezes como mais uma modalidade de negócios que reduz o budget de TI. Ao contrário disso, a adoção desses processos pode – e deve – resultar em uma significativa economia de dinheiro e tempo. E é o que sugerem as companhias que já adotaram esse modelo de desenvolvimento.
No entanto, muitos diretores de TI questionam o momento certo de parar de investir no aprimoramento desse processo. “Testes custam dinheiro. Então a dúvida é quando parar de testar”, reconhece Jerep, da Quest Software. Segundo ele, as empresas não conseguem encontrar o meio termo para esses investimentos. “É sempre oito ou 80.”
Para todos os especialistas, sem exceção, não há hora de parar – os investimentos em qualidade têm de ser contínuos. “Qualidade não é projeto. É um processo”, opina Caram, da ISD Brasil. “Enquanto for preciso, é necessário investir”, diz o executivo, comparando esse aprimoramento ao de um atleta. “Na busca pelo aprimoramento contínuo, ele [o atleta] não pára de treinar.”
Caram lembra ainda que quanto maior o controle que uma empresa tiver sobre o seu processo de desenvolvimento, melhores serão os resultados que poderá obter dele. “Os atrasos em projetos custam muito caro, tanto para o fornecedor quanto para o cliente”, afirma. “Se o desenvolvedor souber, por exemplo, que não tem condições de entregar determinada demanda em um dado espaço de tempo, pode ser mais vantajoso recusar o projeto. Mas ele só vai saber disso se adotar boas práticas e processos de qualidade”, garante.
Alves, da Compuware, diz que melhoria de qualidade implica em investimentos sem fim. “Para perpetuar as melhorias os investimentos devem ser contínuos”, diz. “Qualidade não pode ser pontual. Tem de ser um processo”, faz coro Wolf. Segundo o executivo da Quest, desde que seja bem-feito, o investimento sempre renderá ganhos. “Se optar pela qualidade, o custo total sobre o investimento (TCO) tem de diminuir. Se não diminuir é porque o investimento não está bem-aplicado”, pontua.
Tocci, da Borland, diz ainda que investimentos em qualidade e no próprio CMMI devem ser feitos para o bem da empresa e não para o seu marketing. “Os investimentos não devem parar nunca. A habilidade vem da experiência, dos erros e acertos”, conclui.
No fim das contas, toda a discussão a respeito das vantagens de adotar políticas de testes e melhoria da qualidade de softwares levam a crer que o mercado está mais maduro no que tange o desenvolvimento de soluções. Especialmente entre aqueles que buscam economia de dinheiro e tempo e, para quem pretende, principalmente, competir internacionalmente.
Contra números não há argumentos
• Desenvolvedores gastam 50% do seu tempo encontrando e corrigindo erros – IDC
• 80% do custo de desenvolvimento são destinados à identificação e correção de erros – National Institute of Standards and Technology (NIST)
• 1 erro é gerado a cada 10 linhas de código escritas – Writing Solid Code, Microsoft
• Em média 12 horas são gastas para corrigir cada erro em um código – Writing Solid Code, Microsoft
• 54% dos projetos têm seus orçamentos estourados – The Standish Group
• A cada mil linhas de código são encontrados entre 20 e 30 bugs – Sustainable Computer Consortium
• Inspeção de software reduz entre 60% e 90% dos defeitos em software e 25% de seus custos de desenvolvimento – Michael Fagan Associates
• 56% dos erros encontrados depois da solução final ter sido entregue têm origem na fase de requisitos – Chaos Report
Fonte: COMPUTERWORLD
Copyright © 2008 - Spread - Todos os direitos reservados.
