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

Campanha Ajude o Sr. Ping

Bruno Braga on December 3rd, 2008

A IBM está com uma campanha de marketing interessante onde o Sr. Ping (profissional de TI) vai viajar e perde o contato com sua equipe e seu projeto.
A idéia é que a cada dia o desenvolvimento de software se torna mais colaborativo e para manter tudo em ordem existe algo novo da brand Rational que pode ajudar. Para saber, veja a campanha:


http://www.viagemdosrping.com.br

Em breve vou postar mais detalhes sobre esse assunto…

Pangea – rede social sobre arquitetura de software

Bruno Braga on October 24th, 2008

Agora em outubro meu amigo Adriano Tavares da Squadra aqui de Belo Horizonte, junto com outros amigos da Squadra criaram o Pangea.
Segundo descrição do próprio grupo:

“Pangea é uma rede formada por profissionais e acadêmicos interessados no crescimento e evolução da arquitetura de software”.

http://pangeanet.ning.com

Se você trabalha com desenvolvimento de software, gosta de arquitetura, quer discutir, colaborar e aprender mais sobre o tema, não deixe de se cadastrar. Podemos aprender muito com as experiência e idéias de outras pessoas.

Alguns grupos dos quais participo:

- Monstros da Arquitetura de Software
- Domain-Driven Design
- O lugar certo para você aprender e praticar SOA

A rede hoje tem 93 membros e quanto mais gente participando melhor.

Exibir minha página em Pangea

Uma rede social com esse objetivo é muito melhor do que o orkut, né não? :P
Colabore!

Rational Team Concert – de olho também no legado

Bruno Braga on October 20th, 2008

O Rational Team Concert (RTC) foi o primeiro produto do projeto Jazz da IBM, que tem o foco em criar um ambiente mais colaborativo para o desenvolvimento de software – “People building great software, together” (slogan do projeto).
A primeira versão do RTC foi liberada dia 30 de junho e as primeiras impressões sobre ele são muito boas e podem ser encontradas facilmente em vários blogs.

Para quem nunca usou o RTC, ele possui fácil instalação (ao contrário de muitos softwares IBM), já trás embutido um controlador de versão e um controle de atividades similar ao JIRA (que é excelente). E além do foco colaborativo ele tem recursos fortes de Web 2.0.

Então o RTC está sendo uma boa resposta da IBM há algumas limitações do ClearCase (CC) / ClearQuest (CQ), que são softwares com mais de 10 anos. Apesar deu ter mostrado o lado bom do CC e CQ aqui no blog (post1, post2), muitas pessoas sabem que configurar e trabalhar com o CQ e principalmente o CC não é algo tão simples =)… é preciso alguém com um bom conhecimento sobre essas ferramentas.

Com o lançamento do RTC criou-se a dúvida: quem tem ClearCase, deve migrar para o RTC? E quanto a quem pretende usar o RTC e possui outros SCMs (Software Configuration Management) como o SVN e CVS?
A resposta sobre realizar a migração é depende.
Se estiver usando o CVS, certamente será necessaria a migração. Em compensação o RTC veio com suporte ao “legado” (se é que podemos falar assim) do SVN e ClearCase e eles ainda podem ser utilizados como o controlador de versão principal.
O único problema hoje é que o conector do RTC para o ClearCase / ClearQuest é apenas um “replicador” de dados. Ou seja: os arquivos criados no ClearCase são replicados para o controlador de versão do RTC. Então na prática os arquivos estão nos dois lugares.

Isso não é algo muito legal, e eu mesmo abri uma solicitação de melhoria em Agosto para o RTC delegar a responsabilidade de controlador de versão para o ClearCase em vez de replicar os dados, seria uma ponte real entre os dois softwares. A solicitação foi aprovada e acredito que será lançada nas próximas versões (existe uma discussão para ver se entra na versão 1.1 do RTC).

Mas qual a vantagem desse “bridge” ou conector entre o RTC e o CC, se o RTC já tem um controlador de versão?
Pelo que pude perceber da equipe dos projetos é que o ClearCase, ClearQuest e outros softwares da Rational vão receber influencias do Jazz e estarão cada vez mais alinhados com esse projeto. Então o controlador de versão do RTC continuará sendo distribuído como uma solução de fácil instalação e com recursos para a maior parte das equipes de desenvolvimento, e a integração com o ClearCase será uma opção mais robusta e com recursos não disponíveis no RTC como multisite e outros. Então o plano de migrar do ClearCase para o RTC hoje pode parecer fazer algum sentido por causa das limitações do conector disponível no RTC 1.0 (um replicador) e por aparentemente os softwares serem concorrentes, mas para o futuro talvez não seja a escolha correta dependendo do tamanho da equipe e dos recursos necessários. Manter o investimento no ClearCase e utilizar o conector ou bridge é a melhor no momento. A maior complexidade é justificável.

Em relação ao SVN depende da estratégia de cada equipe. O SVN é free. Não haveria perda de nenhum investimento ao migrar para o controlador de versão do RTC. O que pode ser feito é utilizar os dois juntos por um período de avaliação e depois realizar a migração dos dados para o RTC se for o caso, já que dificilmente o SVN terá mais features do que o controlador de versão do RTC e quanto mais softwares para “a mesma coisa”, maior a complexidade.

Nos próximos posts eu vou comentar algo sobre o Rational Quality Manager e Rational Requirements Composer que estão sendo desenvolvidos utilizando o Jazz.

Algumas imagens do RTC:

Rational Team Concert Rational Team Concert

Independente do processo de desenvolvimento de software adotado (RUP, desenvolvimento ágil, etc..), sua empresa certamente utiliza um software para fazer as gestão dos fontes de projetos. Entre os controladores de versão mais populares estão o CVS e SVN (gratuitos).  Atualmente eles são os softwares mais utilizados nesta categoria – certamente isso é impulsionados por projetos de software livre.
Talvez por este motivo, a maior parte das pessoas pouco sabe sobre outros softwares similares como o Rational ClearCase da IBM. Antes de mais nada, com certeza o objetivo deste post não é fazer propaganda, mas explicar (para quem quer conhecer) um pouco do ClearCase e a diferenças entre seus dois modos de projetos: Base e UCM. Para facilitar o entendimento, em alguns pontos do post, vou tentar fazer um paralelo com ferramentas mais populares – CVS, SVN.

Atualmente no trabalho divido minhas tarefas de Arquitetura de Software Java com suporte a instalação, configuração e utilização de ferramentas IBM Rational. Entre elas o ClearCase. Então vou dedicar uma parte dos meus posts a ferramentas IBM e o que elas podem agregar de valor em projetos.

Olhando do ponto de vista administrativo, o ClearCase possui N features e ferramentas que facilitam o gerenciamento de um projeto. Mas não vamos entrar nestes detalhes neste post. A idéia neste momento é olhar do ponto de vista de um usuário final (um desenvolvedor por exemplo).

Então, mãos a obra: conforme comentei o ClearCase permite criar dois tipos de projetos: Base e UCM.
Um projeto do ClearCase Base possui recursos similares ao SVN e CVS. Para esse “similar” entenda a presença dos conceitos e recursos básicos: check-in, check-out, branch, labels, etc…

Já no ClearCase UCM as coisas são um pouco diferentes. Além das funcionalidades do ClearCase Base, existem novos recursos e conceitos desconhecidos para muitas pessoas por estarem acostumadas somente ao mundo SVN / CVS, que são dois softwares excelentes e eu mesmo utilizo o SVN em meu projeto de Software Livre.

No ClearCase UCM (Unified Change Management) exitem três palavrinhas chave que fazem muita diferença: Stream, Rebase e Delivery. Elas vão nos forçar a trabalhar de uma outra maneira com o código fonte do produto.

Para explicar essas diferenças no momento de utilização da ferramenta vou fazer um paralelo entre dois termos: Branch e Stream.

Um branch a maioria de nós conhecemos. É uma ramificação no controlador de versão do fonte do nosso projeto (main). Essa ramificação é muito utilizada para realizar manutenções evolutivas e correções no software.
Vejamos a figura abaixo:

Como o branch força o trabalho da equipe em área separadas, ele pode evitar que o código parcial de uma manutenção evolutiva (que está sendo implementada a algumas semanas) vá por engano para homologação/ produção junto com a correção de um bug simples aberto e corrigido nas últimas horas.

Mas o branch não evita um problema comum do desenvolvimento de software empresarial (que geralmente não tem a figura de commiters): a quebra do build ou funcionamento interno (em desenvolvimento) do aplicativo. Se uma pessoa fizer algo errado e realizar o check-in, essa pessoa pode impactar o trabalho de outras pessoas, mesmo em projetos com testes unitários. Um software de integração continua não evita esse problema porque geralmente ele realiza o build do que já está no controlador de versão, e mesmo assim ele não consegue validar todos os tipos de problemas (como em XMLs). Então sempre há um jeito de atrapalhar o trabalho de outro desenvolvedor com um check-in equivocado =P

Para evitar isso o ClearCase UCM existe a opção de utilizar o que é chamado de desenvolvimento em paralelo que é um pouco diferente do conceito do CVS / SVN ou mesmo ClearCase Base.
No ClearCase UCM o cenário de qualquer projeto em equipe teria essas características:

  • cada desenvolvedor que conectar ao projeto, terá automaticamente um “branch” exclusivo para trabalhar – no UCM esse “branch” é chamado de stream;
  • o check-in de um desenvolvedor não causa impacto em outro desenvolvedor porque cada desenvolvedor trabalha na sua stream;
  • todo check-in é relacionado uma atividade então é possível relacionar o código com atividades do projeto;
  • entre outros…

Estes são apenas algumas características do ClearCase UCM, mas a partir delas já podemos entender como é diferente a maneira de utilizar. Vantagens? Vejamos:
Com streams separadas para os desenvolvedores um desenvolvedor não impacta no trabalho de outro. Após um desenvolvedor realizar vários check-ins de “código parcial” para a mesma atividade. Ao acabar de implentar uma determinada funcionalidade, ele fará um Delivery (entrega) da atividade. Nesse momento todos vão poder ver a implementação deste desenvolvedor através do que é chamado de Stream de Integração.
Mas calma, ainda não é possível baixar para a sua Stream a implementação de outro desenvolvedor. Isso acontece porque ainda sim, mesmo dizendo que terminou a atividade o desenvolvedor pode ter feito algo errado, e isso poderia quebrar o seu build. Então o fluxo da ferramenta agora é a validação da Stream de Integração (seja com ferramentas de integração continua ou testes funcionais) e depois a promoção de atividades liberadas pelo desenvolvedor na stream de integração para uma baseline. A partir desse momento qualquer pessoa pode baixar a última versão do código para sua stream (operação chamada de Rebase), afinal o que está na baseline é o fonte correto.

Alguns desses conceitos como baseline são conceitos de Configuration Management (CM) ou Gerência de Configuração, e é dai que vem o nome UCM do ClearCase – Unified Configuration Management. É uma ferramenta construída e baseada nas melhores práticas de CM. Não é atoa que muitas vezes é citada por consultores de CMMi ou MPS.br.

Para completar, segue alguns conceitos de termos novos (considerando o SVN / CVS) que vimos neste post:

  • Stream: em poucas palavras pode ser entendido como um branch integrado a atividades, e geralmente as stream são separadas por desenvolvedores e existe uma de integração – o que não acontece em branchs do SVN, CVS ou ClearCase Base;
  • Delivery: é a entrega do código de uma atividade para a stream de integração;
  • Rebase: representa a atualização da sua stream de desenvolvimento a partir de uma baseline;

Até a próxima!

Foi lançado hoje um buscador chamado cuil – http://www.cuil.com.

A qualidade da busca, velocidade e ranking das páginas ainda está pior do que o Google, além de estar indexando praticamente só termos em inglês por enquanto. Mas algo que eu queria que existisse a muito tempo no google está presente no cuil: a opção de refinar a busca por contexto.

A cada dia que passa existem mais e mais páginas na web e está cada vez mais difícil encontrar o que você quer no google por causa de alguns termos ambíguos. Exemplo: se você procurar “mouse” no google vem tudo quanto é tipo de coisa, animal, mouse de computador, mouse de desenho (mickey mouse), etc… Se você quer mouse de computador você teve no resultado da sua busca um monte de links “inúteis” que só te atrapalham a achar o que você precisa. E quanto maior a web e mais páginas indexadas mais difícil é encontrar o que queremos. Temos que ficar fazendo refinamentos da busca usando mais palavras, sendo que o correto era ter uma busca de contexto. Você busca “mouse”, ele trás os resultados e mostra também os contextos onde essa palavra se aplica para você “filtrar”.

Essa é a grande novidade do cuil na minha opinião. Se procurarmos por “mouse”, podemos usar as abas de contexto para refinar a pesquisa de acordo com o assunto.

Espero que essa feature seja implementada no google que com certeza ainda é o melhor.
Mas o empurrãozinho foi bem vindo =)