Porque testar é caro?

Bruno Braga on October 5th, 2013

imageEm algumas empresas o teste é sempre deixado para o final, e como uma grande parte dos projetos de desenvolvimento de software atrasam (segundo o Chaos Report), a fase de testes que já era curta, acaba reduzida mais ainda. As consequencias diretas são: número de erros em homologação / produção maior do que o esperado e insatisfação do cliente.
O desconforto com o cliente, se recorrente, pode gerar perda de negócio para ambos os lados. Nesse ponto alguma ação tem que ser tomada e para evitar novos erros é natural pensar: “no próximo projeto temos que ter mais tempo para testar”.

O próximo projeto chega e planejamos na fase de proposta/levantamento aquele esforço maior para teste. Todos os envolvidos imaginam que isso é bom e vai resolver os principais problemas com qualidade.
As negociações começam e o esforço de teste é visto como caro para o tamanho do projeto. Com a pressão de fechar o negócio, novamente parte do teste é cortado e pode ser cortado ainda mais se o projeto atrasar – o ciclo continua.

Porque isso acontece e como podemos tentar minimizar esse problema?

Neste cenário o teste acaba sendo visto como caro por vários motivos. Dentre os principais estão:
•    o esforço que a equipe de testes precisa para testar a aplicação;
•    a falta de planejamento do que realmente deve ser testado em detalhe e o que não deve;
•    o custo dos servidores necessários para montar o ambientes de teste integrado, incluindo o tempo necessário para configurar todas as aplicações dessa infra-estrutura dos testes;

Legal, já enumeramos alguns culpados pela fama de caro. Como toda fama esse status foi adquirido com o tempo, são anos de desenvolvimento de software… e se pararmos para pensar, é justamente nesse ponto onde estão os problemas. Não podemos pensar nos testes do dia de hoje da forma como ele era feito a anos atrás. É preciso quebrar o paradigma.

Porque falta tempo para testar?
Tempo é algo relativo. Mas em algumas empresas teste é sinônimo de colocar alguém na frente do computador e deixá-lo o dia inteiro navegando na aplicação “testando”. Mesmo existindo um script de teste (muitas vezes em planilha), o processo é muito manual e caro. E quando a aplicação mudar? Repetimos o teste todo de novo? Testamos novamente só alguns pontos usando nosso “tester”?
Além do esforço necessário, existem algumas perguntas difíceis de responder: ao final desse cenário de testes é possível olhar as várias versões da planilha e dizer facilmente quais requisitos foram testados e quais não foram? Qual a cobertura dos testes? Qual o percentual de erros por cada requisito? Qual funcionalidade apresentou mais problemas?
Bom, são muitas perguntas. O importante é perceber que ter processo e ferramentas adequadas é crucial para ser eficiente e reduzir o esforço de cada ciclo de testes. Isso consequentemente vai ajudar a reduzir o tempo e o custo.

A primeira dica para tentar melhorar esse cenário não é nenhuma novidade. A muitos anos existem várias ferramentas de testes funcionais no mercado que ajudam os testadores a não fazer tudo manualmente e automatizarem testes de regressão. A estratégia é concentrar os testes manuais em pontos específicos e usar testes funcionais para reduzir o esforço necessário já no segundo ciclo de testes. O pacote de testes chamado RTW (Rational Test Workbench) inclui funcionalidades para automatizar esses pontos, inclusive com suporte a testes para dispositivos moveis. Outra opção seria o uso do  Worksoft Certify que realiza testes funcionais para SAP e pode também ser utilizado para realizar um teste integrado de SAP com aplicações web sem escrever nenhuma linha de código – a ferramenta é 100% visual, facilitando o trabalho dos testadores.
O resultado de todos esses testes são reportados pelas ferramentas no RQM (Rational Quality Manager) que exibe um painel  com indicadores sobre cobertura e resultado dos testes.
Outra dica para reduzir o tempo dos testes é melhorar o planejamento, que é nosso próximo item. Vale lembrar que também é importante não deixar o teste só para o final do projeto.

É preciso planejar?
Com a correria do dia a dia, quase nunca conseguimos tempo para planejar (não só testes, mas planejar qualquer coisa). Mas sem planejar os testes perdemos a referencia de como cada parte do software deve ser testada. Isso cria um dilema: reservar tempo (aquele mesmo que foi cortado) para esse planejamento ou sair testando sem saber ao certo qual parte deve ser testada e qual não é tão importante nesse momento? Testar tudo pode gerar custos altos e talvez nunca termine em função de constantes mudanças no software. Em algumas empresas o jeito mais fácil que encontram para fugir desse dilema é não testar nada (em alguns casos) porque é “muita coisa” e confiar nos testes do desenvolvedor. Esse é o pior dos casos, mas na prática acontece e algum gerente “assume” os riscos.
Para evitar esse cenário, planejar é muito importante e ajuda a não perder tempo de execução testando tudo “atoa”.  É preciso manter o foco, e quem traz isso é o planejamento.

Aqui também podemos ir por dois caminhos:
•    planejar os testes na “mão” através de planilhas que não estão linkadas/rastreadas com o negócio (requisitos) nem com uma ferramenta de gestão de defeitos;
•    usar uma ferramenta de planejamento para agilizar esse trabalho dentro de um ciclo de vida de ALM (Application Lifecycle Management) mantendo toda a rastreabilidade e analise de impacto necessária (caso os requisitos mudem por exemplo) e permitir o report de defeitos automaticamente;

O RQM (Rational Quality Manager) já foi citado e é a ferramenta ideal para ajudar o Analista de Testes no planejamento e também no acompanhamento dos testes. Ela tem ainda o papel de integração com o RTC (Rational Team Concert) para report de defeitos.

Mais sobre o RQM: https://jazz.net/products/rational-quality-manager

image

Por que a infra-estrutura é cara?
Servidores dedicados para testar uma aplicação que envolve uma serie de integrações é algo caro, isso é um fato. Uma quebra de paradigma por exemplo pode ser usar uma cloud privada para agilizar a criação/configuração de uma infra-estrutura para testes, correto? Talvez, mas ainda sim é caro manter uma cloud privada para testes. Então precisamos de mais inovação, de quebrar um pouco mais o paradigma.
E se ao invés de ter uma infra-estrutura com máquinas físicas ou virtuais para esse ambiente de testes integrados você conseguisse reduzir o número de aplicações, reduzir o número de servidores e reduzir a complexidade? Isso com certeza iria reduzir o custo.
Um jeito fácil de fazer isso é construir uma aplicação que não se integra a nada. Mas esse não é o objetivo aqui ;) Podemos ter aplicações complexas com várias integrações e testar isso sem depender de uma infra-estrutura cara.
Isso pode ser feito com um software virtualizador de serviços. O papel desse software é simular as integrações que ainda não existam ou que existam mas são caras (infra-estrutura). Para fazer isso o virtualizador de serviços pode ouvir uma comunicação de rede entre as aplicações e “aprender” a se comportar como uma determinada aplicação real. Na hora de testar, ao invés de termos uma infra-estrutura cara, vamos ter um servidor simples para a aplicação que será testada e através da conexão com o virtualizador de serviços corporativo será possível executar os testes integrados sem o uso de servidores adicionais (incluindo MQ, web services, barramentos, etc).
Quem faz esse papel é o RTW (Rational Test Workbench) que além de virtualização já foi citado anteriormente pois inclui funcionalidades para testes Funcionais e de Performance.

Bom o assunto é longo e tem muitas ações que podemos tomar para reduzir os custos com testes. É bom lembrar que tudo que comentamos aqui tem mais ganhos do que só reduzir custos. Com as automatizações e virtualizações de ambiente é possível antecipar os testes e testar cenários que antes não eram testados.
Mas e você; já ouviu dizer que testar é caro e pouco eficiente? Espero que consiga tirar algumas ideias daqui e começar a pensar sobre isso.

Esse meu post foi originalmente publicado no blog da Rational Brasil.

Subscribe to this blog's RSS feed

Para alinhar o entendimento, devemos recordar que o IBM Rational Team Concert (RTC) faz parte da plataforma Jazz e é uma ferramenta com três vocações: – Gerência de Configuração – Gerência de Mudança – Integração Contínua Através de recursos colaborativos inspirados em redes sociais, ele tem se tornado a peça fundamental no ambiente de desenvolvimento […]

Continue Reading...

O que o RTC 3.0 pode fazer por você

Bruno Braga on November 29th, 2010

Para quem ainda não conhece, o IBM Rational Team Concert (RTC) é uma ferramenta para gestão do ambiente de desenvolvimento de forma colaborativa e pode ser usada tanto com desenvolvimento tradicional quanto com desenvolvimento ágil. O que a ferramenta faz na prática é combinar recursos de gerencia de defeito (bug tracking) com gestão de mudanças, […]

Continue Reading...

Esse blog estava meio parado desde que comecei a viajar muito e ficar sem tempo. Mas vou postar aqui alguns tópicos que postei no blog da IBM Rational para começar a movimentá-lo novamente =) O projeto Eclipse (eclipse.org) foi originalmente criado pela IBM em 2001 e tem desde então recebido cada vez mais apoio de […]

Continue Reading...

SPIDER on Rails no Demoiselle (projeto do governo)

Bruno Braga on February 2nd, 2010

Uma boa notícia: o Demoiselle – framework do governo (SERPRO) para desenvolvimento Java avaliou e divulgou em seu blog um post sobre a ferramenta SPIDER on Rails: http://sourceforge.net/apps/wordpress/demoiselle/2010/01/26/spider-on-rails-gerando-codigo-demoiselle/ O resultado da analise detalhada (ver link acima) e criação de um template para o Demoiselle foram bastante positivos e podemos destacar alguns trechos dessa analise: “Continuando […]

Continue Reading...

Mitos sobre geração de código

Bruno Braga on December 24th, 2009

Segue abaixo um artigo que escrevi no site do projeto SPIDER on Rails: O termo “mito” é, por vezes, utilizado de forma pejorativa para se referir às crenças comuns. E existe uma cresca comum que geração de código é algo ruim em projetos. Encarnando os MythBusters vamos tentar analisar objetivamente se esse mito é válido. […]

Continue Reading...

Twitter ativado

Bruno Braga on December 7th, 2009

Eu já havia criado a algum tempo mas resisti um pouco para postar no Twitter devido a correria e falta de tempo. Mas agora com um HTC Hero (android OS) ficou mais fácil e posso fazer atualizações de qualquer lugar. Segue o link: http://www.twitter.com/bgbraga Algumas pessoas as vezes me perguntam sobre o projeto J2EE Spider […]

Continue Reading...

World Community Grid

Bruno Braga on October 21st, 2009

Agora aqui no blog, na coluna da direita vou exibir um widget como esse: [dciframe]http://www.worldcommunitygrid.org/getDynamicImage.do?memberName=bruno.braga&mnOn=true&stat=1&imageNum=4&rankOn=true&projectsOn=false&special=true,130,190[/dciframe] Já participo do programa a alguns meses e para quem não conhece o World Community Grid (WCG) é uma comunidade mundial onde as pessoas podem ajudar a descoberta de curas para doenças como Influenza A, Câncer, Diabetes, Dengue, etc.. A […]

Continue Reading...

Smart Work e Sr. Ping

Bruno Braga on September 16th, 2009

Smart Work A IBM está lançando uma iniciativa chamada Smart Work que visa criar um ambiente de trabalho melhor para as pessoas e organizações, com mais produtividade, agilidade e colaboração. Na prática um dos pilares desta iniciativa é o desenvolvimento ágil. Veja alguns trechos da chamada: “O mundo dos negócios muda rapidamente, e somente serão […]

Continue Reading...

Case Study mundial de IBM Rational Team Concert

Bruno Braga on September 8th, 2009

A GlobalValue (GVS), já era referência no Brasil sobre IBM Rational Team Concert (RTC), e a poucos dias atrás concluímos mais um passo desse trabalho. O pessoal da IBM internacional gostou da nossa implementação e agora somos Case Study mundial de RTC. Eles disponibilizaram várias informações sobre nossa implementação no site www da IBM com […]

Continue Reading...