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.

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>