Fonte: ComputerWorld, com tradução da CIO Magazine
Três anos atrás, o Station Casinos idealizou uma ótima promoção para atrair clientes: oferecer 25 dólares de jogo gratuito em máquinas caça-níqueis a partir de seus cartões de fidelidade eletrônicos. Funcionou como mágica, apostadores afluíram ao cassino em bandos. Era para ser uma boa estratégia de negócios.
Porém, em uma sexta-feira, logo depois de iniciada a promoção, quando os jogadores inseriram seus cartões nas máquinas, nada aconteceu. O grande número de pessoas tentando acessá-las? ao mesmo tempo em que o departamento de contabilidade rodava diversas aplicações financeiras? travou os servidores que armazenavam toda a informação promocional. Irados, jogadores atiraram seus cartões de fidelidade no chão e iniciaram um tumulto. Uma reação nada boa.
A origem do problema? Teste. Marshall Andrew, vice-presidente de tecnologia da informação e CIO do Station Casinos, diz que a empresa não previu uma resposta tão esmagadora à promoção. Portanto, a área de TI não testou o sistema para volumes de atividade tão grandes e, certamente, não enquanto outros programas estavam em funcionamento.
Não só o cassino deixou de ganhar dinheiro naquela sexta-feira, como desagradou clientes e precisou fazer outra campanha para se desculpar. Assim, a empresa convidou alguns clientes a voltar em outro fim de semana oferecendo, dessa vez, 50 dólares de jogo gratuito.
Moral da história: testar é essencial para desenvolver software de alta qualidade e garantir a tranqüilidade das operações financeiras. Não pode haver descuido, já que as conseqüências são terríveis. Negócios, e até mesmo vidas, correm risco quando uma organização não é capaz de testar software em busca de bugs e gargalos de performance adequadamente ou determinar se o programa satisfaz requisitos de negócio ou necessidades de usuários finais.
“O importante, quando você implanta um sistema, é assegurar que ele funcione”, observa Andrew, que fez mudanças significativas em sua organização de teste (conhecida como quality assurance, ou QA) desde então. Primeiro, ele mudou o próprio processo de teste. Antes, os desenvolvedores tinham muita liberdade para alterar código enquanto este estava sendo testado para manter o projeto avançando. Agora, há controles rígidos sobre o acesso dos desenvolvedores a código de teste.
Para preservar a sinceridade, Andrew fez com que o especialista em QA começasse a reportar ao grupo de analistas de negócio ao invés de ao grupo de desenvolvimento, cujo trabalho estava sendo avaliado. Em seguida, contratou mais especialista em QA? com treinamento em negócio? e envolveu-os no processo de desenvolvimento mais cedo, quando analistas de negócio estão criando documentos sobre requisitos, para que possam, então, desenvolver scripts de teste baseados em especificações de negócio bem no início do processo.
A lista a seguir, com melhores práticas para avaliar software e administrar uma organização de testes, foi compilada de entrevistas com empresas que têm demandas e padrões de teste rigorosos. Estas dicas vão além do mantra “testar no início e com freqüência”, aprimorando não só a capacidade de teste da organização de TI, mas também a qualidade do software que é liberado.
1.) Respeite seus testadores. Em muitas empresas, o teste é visto como um serviço elementar e, como resultado, nem sempre bem feito. Recrute profissionais detalhistas, metódicos e pacientes. Procure pessoas que também saibam codificar.
Seus desenvolvedores vão respeitá-las mais e elas podem codificar algumas de suas próprias ferramentas de teste. “Se a organização de desenvolvimento e a de garantia de qualidade não se respeitarem, não poderemos atingir nossas metas de alto nível de qualidade”, diz David Pride, vice-presidente da eBay encarregado de QA.
2.) Reúna no mesmo local testadores e desenvolvedores. Juntar desenvolvedores e testadores é um grande passo para aprimorar a comunicação entre dois grupos que, com freqüência, batem cabeça (afinal, testadores são pagos para descobrir falhas no trabalho dos desenvolvedores). A proximidade física “facilita as nuances do teste”, que são mais bem transmitidas através da interação pessoal do que por e-mail ou uma ferramenta de workflow de desenvolvimento de aplicação, acredita Pride.
3.) Monte uma estrutura de hierarquia independente. A função de teste não deve reportar a nenhum grupo que é avaliado por cumprir prazos ou manter baixos os custos de um projeto, segundo John Novak, vice-presidente sênior da cadeia de hotéis La Quinta. Fazer os testadores reportarem ao grupo de desenvolvimento é a pior opção de todas, alerta. Se os desenvolvedores estiverem atrasados ou tiverem dificuldade com código, ficarão tentados a deixar os testadores de lado. Novak tem testadores que reportam diretamente a ele. No Station Casinos, o time de teste reporta ao grupo de analistas de negócio de Andrew, para fomentar a comunicação e envolver testadores no ciclo de desenvolvimento desde o início.
4.) Dedique testadores a sistemas específicos. Na Barnes & Noble, um grupo de testadores enfoca sistemas de armazenamento, enquanto outros abordam sistemas financeiros e a base de dados que controla o estoque. Chris Troia, CIO da rede de livrarias, acredita que dedicar os testadores a um conjunto de sistemas aumenta seu entendimento de como estes devem funcionar e lhes dá expertise para identificar problemas que talvez não apareçam em um documento de teste formal. A eBay adota a mesma abordagem, mas vai além. A empresa conta com três grupos de teste distintos: um para funcionalidades do site, um para pagamentos e um para aplicações de data warehousing.
5.) Proporcione treinamento em negócio. Andrew, do Station Casinos, faz membros de seu departamento de teste trabalhar na recepção, no salão do cassino e em diferentes departamentos corporativos para aprender o jargão e entender melhor o sistema que estão testando. (A maior parte de sua equipe de TI de 125 pessoas nunca havia feito uma aposta em um cassino antes de entrar para a empresa.).
6.) Permita que usuários da área de negócio também testem. A maior parte do teste envolve exercitar sistemas e mexer com código, ou seja, trabalho técnico, e TI pode ficar tentada a deixar de fora usuários de negócio. É um erro. “Na La Quinta há sempre testadores vindo da comunidade de negócio”, observa Novak, para assegurar que os sistemas que TI está desenvolvendo sigam as especificações.
Para algumas aplicações, em especial as utilizadas em hospitais, fazer usuários testá-las é uma questão de vida ou morte. “O pessoal de tecnologia só vai até certo ponto”, diz Patricia Skarulis, vice-presidente de sistemas de informação e CIO do Memorial Sloan-Kettering Cancer Center. “Precisamos que os usuários se envolvam na avaliação das aplicações.”
7.) Envolva operações de rede. Nate Hayward, vice-presidente e diretor de gestão de qualidade da HomeBanc Mortgage, conta que, durante o teste, o grupo de operações de rede da empresa utiliza software (ServerVantage, da Compuware) para monitorar problemas de performance de servidores que poderiam advir do modo como o hardware ou o software são configurados. Envolver os especialistas de operações de rede nos testes também lhes dá a chance de ensaiar uma implementação antes que um sistema entre em produção, garantindo que a implementação real transcorrerá sem sobressaltos.
8.) Crie um laboratório que reproduza seu ambiente de negócio. Quatro anos atrás, o Station Casinos montou um laboratório de testes caro, semelhante a um mini-cassino, com máquinas caça-níqueis, terminais de ponto de venda e quiosques baseados na Web simulando os ambientes de computação das 13 propriedades da organização. Noventa por cento das aplicações que a empresa utiliza, incluindo aquelas baseadas em tecnologia sem fio, estão reproduzidas no laboratório. Para as 10% restantes – grandes ou complexas demais para terem uma réplica exata – Andrew criou um subconjunto mais enxuto com o objetivo de prever como vão se sair quando estiverem plenamente implementadas.
Se necessário, Andrew pede ajuda. Na implementação de sistema mais recente, ele recorreu aos laboratórios de teste da Microsoft para rodar modelos de simulação.
9.) Desenvolva testes durante a fase de requisitos. As empresas, normalmente, esperavam para fazer testes após a definição de requisitos e o início ou o fim da codificação. Uma escola de pensamento cada vez mais difundida diz que é possível testar com eficácia mesmo que os requisitos não tenham sido desenvolvidos totalmente. Fãs da “programação ágil” acreditam que se deve testar continuamente, do início ao fim do projeto.
10.) Teste o velho com o novo. A eBay usa uma ferramenta de análise estatística desenvolvida internamente para comparar defeitos descobertos por testadores no código que foi testado durante um ciclo de teste específico. A meta é garantir que software avaliado antes continue funcionando adequadamente quando novos recursos são acrescentados. Pride, o vice-presidente encarregado de QA, conta que a ferramenta de análise estatística detecta onde os testadores precisam acrescentar casos de teste ao projeto corrente e também ajuda a determinar a eficácia geral de testes de regressão atuais para futuros projetos de software. A eBay tem de refinar os testes continuamente porque alguns projetos novos podem conter a mesma funcionalidade de iniciativas anteriores.
11.) Aplique particionamento de classe de equivalência. “Trata-se de uma técnica matemática que os testadores podem usar para identificar requisitos funcionais adicionais que analistas e usuários da área de negócio talvez não tenham observado ou comunicado”, explica Magdy Hanna, chairman e CEO do International Institute for Software Testing. De acordo com a executiva, o particionamento de classe de equivalência dá aos testadores uma visão clara do número de casos de teste que precisam executar para exercitar adequadamente todos os requisitos funcionais de um sistema. A técnica permite, por exemplo, que o grupo de Pride determine todas as maneiras com que os 157 milhões de usuários da eBay podem usar sua plataforma de leilão online. O que é um belo cartão de visitas.
