Cometemos um dos maiores pecados no mundo da Web 2.0: deixamos nosso blog sem atualizar por 9 meses. É tempo demais, e por isso pedimos desculpas a quem tenha tentado obter informações novas no período, vamos procurar publicar os posts com uma frequencia descente. Aliás, nesses nove meses, a Lingua Portuguesa mudou e frequencia não tem mais acento…

Sentado a beira do lago em uma bela tarde de domingo, ouvi um grito. Corri e com toda força que o bom Deus me deu consegui salvar o picto (nativo celta) da terrível besta. Foi tudo tão rápido. Quando me dei por conta, a fera já havia mergulhado para as profundezas. Vi a ponta da cauda da criatura, deveria pertencer a um imenso réptil, uma serpente marinha.

São Columbano, Escócia, séc. VI

Um grande dilema que todo Testador enfrenta, mais cedo ou mais tarde, é o que fazer quando se depara com um defeito irreproduzível, ou seja, uma ocorrência inesperada de um software cuja manifestação não conseguimos repetir.

Alguns Testadores fingem que não viram nada, afinal registrar o ocorrido é quase a mesma coisa que dizer que viram a ponta da cauda do monstro do Lago Ness, o Chupa-cabra ou um disco voador. Os outros profissionais, uma vez informados, ficam com aquela expressão de incredulidade, e com opiniões que vão do “Você fez alguma coisa errada” ao “Você sonhou isso em cima do teclado”. É realmente incomodo e entendo perfeitamente porque tantos se calam.

O Gerente de Teste também tem um grande inconveniente ao registrar o defeito irreproduzível, pois quando os testes forem finalizados, mesmo os mais exaustivos, o defeito pode continuar lá, invisível, como uma temível ameaça pairando sobre o sistema e seus usuários, um tic tac abafado. Todos gostariam de se livrar dessa desconfortável estatística.

Recentemente, uma falha sem precedentes se manifestou em um sistema com 11 anos de produção em um grande banco brasileiro. Tratava-se de um programa sem manutenção há anos e considerado totalmente estável. O defeito, a vulnerabilidade, ficou latente por muito tempo, esperando apenas por um contexto que provocasse o colapso. Talvez alguém tenha visto a ponta da cauda do monstro, porém faltou coragem ou liberdade para tomar a ação necessária.

Uma empresa em que não se tem a liberdade de dizer o que se viu ou o que se pensa, em que não existe abertura para o dialogo, em que os erros são punidos ao invés de entendidos e corrigidos, é uma organização de alto risco. Está cega, surda e muda. E os bugs não perdoam.

Acredito que temos que ter a coragem e o profissionalismo de discutir o assunto livremente e nos prepararmos para evitar esse tipo de ocorrência, registrá-la e tratá-la caso ocorra.

Evite os Defeitos Irreproduzíveis

Evitar como? Aperfeiçoe o seu plano de teste de forma a incorporar os testes exploratórios que muitas vezes são realizados fora do planejamento. Não finja que eles não são feitos, ao contrário, formalize-os e incorpore-os. Envolva a equipe, todos devem contribuir, perceber que o plano pertence ao grupo e se comprometer com esse planejamento.

Planeje o que vai ser feito e faça o que planejou.

Não teste sozinho. Você já deve ter assistido muitos filmes de suspense e de terror. O que acontece com um membro que se separa do grupo de amigos? O monstro ataca! O mesmo ocorre com os defeitos irreproduzíveis. Ter alguém da equipe para olhar junto o problema pode esclarecer a situação e torná-lo reproduzível.

Sim, muitos defeitos irreproduzíveis podem ser causados por má interpretação, falta de preparo para lidar com determinadas situações e novas tecnologias. Treinamento, troca de experiência entre os profissionais e capacitação continua são as formas de mitigar esses riscos.

Cansaço é outro fator. Prazos apertados fazem com que a jornada de trabalho invada as horas de descanso, fins de semana e feriados. De vez em quando, dar um gás no final do projeto é necessário, porém quando a exceção se torna a regra, podemos colocar em cheque a qualidade do trabalho da equipe de teste, a qual precisa de concentração e criatividade, ou seja, precisa estar descansada.

Registre os Defeitos

Não se omita. Utilize ou crie um campo no seu registro de defeitos para marcar se não é possível reproduzir a ocorrência.

Gere evidências. Imprima a tela, fotografe com o celular, chamar um colega para ver a tela, melhor ainda se for o programador incrédulo. Vale tudo para registrar o fato e não passar por lunático.

Trate o Problema

Não varra a sujeira para debaixo do tapete. A dificuldade de reproduzir o defeito normalmente está relacionada a um conjunto de fatores que não ocorrem juntos com freqüência, mas que geram um efeito devastador quando isso acontece.

Vou dar alguns exemplos bastante triviais da ocorrência de defeitos que momentaneamente foram considerados irreproduzíveis:

1 - Relatório Travou a Aplicação

Ao acionar uma função de envio de relatório por e-mail o software parou de funcionar. Após ser reiniciado, voltou a funcionar novamente. O log da aplicação mostrava toda a navegação pelas funções, até o momento em que o relatório iniciou a ser gerado e parava aí. O componente de geração de relatórios era de um fornecedor renomado, usado por diversos outros sistemas na empresa e por inúmeras organizações no mundo. O servidor de banco de dados não apresentou nenhum problema. O serviço de envio de e-mail estava no ar. O processador e a memória não chegavam a 50% de utilização. O disco rígido não estava tão vazio assim, mas havia 1 Gb de espaço e o relatório ocuparia no máximo 400 Kb. Testaram dezenas de vezes o mesmo roteiro, em diferentes horários, sem conseguir reproduzi-lo.

O problema era que outro servidor estava com o drive de gravação de DVD quebrado e um operador copiou um conjunto de arquivos de backup para um diretório temporário do servidor com a aplicação em testes, efetuou a gravação e apagou os arquivos do disco. Os arquivos somavam 1 Gb e esgotavam o espaço do disco. Esse processo durou apenas 5 minutos. A aplicação não possuía tratamento adequado para essa situação de disco cheio e simplesmente travou, sem gravar em log ou qualquer mensagem em tela ou por e-mail. Quando o testador verificou o disco, ele já estava com 1 Gb livre de novo. Quando perguntaram se havia algum problema no servidor, o operador disse que estava tudo funcionando corretamente. Quando questionado se havia acontecido algo de incomum, a resposta foi negativa, afinal, nada é mais comum para um operador de data center do que fazer backup. O Programador testou o programa na própria máquina, no servidor de desenvolvimento, no servidor de testes e nada de errado.

Um erro operacional humano, um disco quase cheio e a falta de tratamento de um risco em um sistema. Combinação simples, mas com conseqüências mal cobertas. Um teste mais detalhado dos limites de hardware acabou com o mito que perseguiu os Testadores por alguns dias.

Investigue

Procure identificar as possíveis causas, utilize o Diagrama de Ishikawa (Espinha de Peixe) e o Diagrama de Causa e Efeito para isso. Verifique cada ramo. Teste as combinações. Utilize softwares de monitoração para detectar alterações no ambiente (hardware, software, network, permissões e configurações). Converse com todos os envolvidos, procure estabelecer uma cronologia, colete evidências, procure estabelecer as relações de causas e efeitos, não um culpado. A caça as bruxas não é muito eficiente com profissionais de informática.

Testar não garante a completa ausência de defeitos. Outro sistema passou por todos os testes com louvor, mas um testador havia visto um defeito irreproduzível e ficado quieto. Em produção, falhava intermitentemente. A aplicação estava distribuída em vários servidores. Funções diferentes falhavam em horários diferentes, em máquinas diferentes, para usuários de perfis diferentes. Não parecia haver um padrão e falha incomodava o cliente e os clientes dele.

2 - Defeito Aleatório

A aplicação usava o padrão de numeração americano (ponto para separador decimal e vírgula para separador de milhar). O servidor estava configurado para esse padrão, porém um dos operadores tinha o seu perfil pessoal personalizado para o padrão brasileiro (vírgula para separador decimal e ponto para separador de milhar). Ou seja, ao contrário. Cada vez que esse operador realizava o login em uma máquina diferente, enquanto ele estava conectado, as funções que fossem acionadas naquele servidor, que fizessem uso de cálculo com decimais, produziam falhas.

Todos os perfis dos operadores foram verificados e padronizados. A aplicação e todas as novas que foram construídas passaram a ter uma programação defensiva para evitar que outros problemas relacionados às Configurações Regionais do sistema operacional pudessem gerar interferência em seu comportamento.

Não Arrisque

Sistemas que envolvem risco de vidas humanas não podem ser dar a esse luxo. Todos os defeitos irreproduzíveis devem ser registrados, mapeados, cercados e desmascarados. O monstro que bate na janela é provavelmente um galho de uma arvore, porém precisamos investigar, e não cobrir a cabeça com as cobertas.

Softwares de alto risco, além de teste a exaustão, podem muitas vezes necessitar de contratar serviços de consultorias independentes de teste para verificar e validar as situações que incorrem no defeito irreproduzível. Um olhar neutro e profissional de alguém de fora pode ser muito esclarecedor. Todo mundo já passou pela situação de ter um problema e não ver a sua origem, então um colega passa, olha e diz: “Não é isso aqui que está errado?”. A consultoria independente funciona de forma semelhante, só que com profissionais acostumados a lidar com esse tipo de crise.

3 - O Defeito Fantasma

O ambiente de teste foi montado para reproduzir exatamente o de Produção. No início da fase de Teste de Aceite, o Testador que iria acompanhar a homologação acessou o site, avaliou o funcionamento como normal e ligou para o usuário para avisá-lo de que poderia iniciar as atividades. O Usuário não conseguia acessar o site. O Testador acessou novamente, estava normal para ele. O Usuário foi de novo, nada. O Testador repetiu a URL para o Usuário, clicou em “Atualizar Página”, tudo certo. O Usuário soletrou letra por letra, tudo certo mais nada funcionava. O Testador achava que o Usuário estava fazendo algo errado e o Usuário se irritava, com razão, de que o Testador duvidava dele.

O Testador foi na mesa do Usuário, e este digitou novamente a URL falando que já fizera isso três vezes sem sucesso. Funcionou. O Usuário, sem graça, disse que foi tudo igual e que só funcionou porque o Testador estava ali. O Testador foi embora achando que o Usuário tinha feito alguma besteira antes. Mal o Testador saiu da sala, o Usuário testou mais uma vez com o mesmo processo e não funcionou de novo.

O Usuário já a beira de um ataque de nervos ligou para o Testador: “Vocês estão brincando comigo? Que droga de sistema é esse que só funciona quando você vem aqui?”. O Testador acessa de novo e está tudo bem. O Usuário acessa de novo e está tudo errado. Podíamos continuar por páginas e páginas.

Quem estava certo? O Testador ou Usuário?

Onde há fumaça, há fogo. O ambiente foi montado igual ao de Produção, em dois servidores com balanceamento de carga do tipo Round Robin. Nome muito bonito, dá até vontade de por em como nome em um filho. Porém, poderíamos traduzir o método para algo como uni-du-ni-tê, aquela brincadeira de criança para escolher entre a bala de uva e a de laranja. O Round Robin faz com que o primeiro acesso vá para um servidor e o segundo acesso vá para o outro servidor. Se um dos servidores cair, ele não verifica ou avisa, e os acessos podem cair em um buraco negro. Assim, pode parecer que está tudo certo para uma pessoa e completamente errado para outra. Um tipo de defeito fácil de identificar se apenas acreditarmos que o Usuário realmente viu alguma coisa errada.

Pense em um relógio analógico e seus ponteiros, mesmo quebrado, ele mostra a hora certa duas vezes por dia. Nosso Testador estava passando sempre na frente do relógio no momento propicio para não perceber o defeito. Esse é o pior dos defeitos, aquele que funciona em algumas situações.

Confiança é tudo

Testar é mais do que controlar a qualidade, é garantir a confiança dos usuários no sistema. Vai ser mais difícil de negar que um Testador confiável viu um defeito, mesmo que irreproduzível.

Testadores devem prezar por sua credibilidade e procurar embasar suas argumentações em fatos comprovados, em evidências, em informações válidas e em muito estudo. Testar envolve conhecer muito de tecnologia, de técnicas de teste, de lógica de programação, de infra-estrutura, de arquitetura de sistemas, de telecomunicações e do negócio que está sendo alvo do teste.

É complexo, é profundo, e por isso muitos Testadores ainda não se arriscam fora da borda de conforto do Teste de Sistema. Preocupam-se apenas com a automação dos testes, quando deveriam se esforçar por entender e implementar o modelo V e os processo de Verificação e Validação como um todo no projeto, de ponta à ponta.

A propósito, São Columbano caiu em descrédito na história do monstro do Lago Ness após ter contado um outro causo em que teria conseguido matar um javali apenas com um grito. Note que se duvidam até de um santo, porque não vão duvidar de você. Novamente a questão é credibilidade.

Seja um profissional completo de Tecnologia da Informação. Estude, se certifique, compartilhe conhecimento e experiência. Planeje, controle, meça o progresso. Experimente, erre, aprenda, melhore! Conquiste e mantenha a credibilidade. Registre, respeite e desmascare os erros irreproduzíveis. E principalmente, não tenha medo de bugs!

Inclua um comentário com algum caso de defeito irreproduzível que você já enfrentou e ajude-nos a continuar a discussão do assunto

Obs.: A narrativa do encontro de São Columbano com o “monstro” foi romanceada a partir das informações publicadas na Wikipedia (http://pt.wikipedia.org/wiki/Monstro_do_Lago_Ness).

Defeitos irreproduzíveis são discutidos no Curso de Formação de Teste de Software da Iterasys.

Embora no Ocidente comemoremos o 1º de Janeiro como dia de Ano Novo, é interessante notar que diversos povos seguem calendários diferentes e iniciam a contagem do novo ano em outras datas. É o caso dos chineses, dos cristãos ortodoxos, dos judeus, entre vários outros. Aqui no Brasil deveríamos assumir que nosso ano começa depois do carnaval, na quarta-feira de cinzas. Talvez na segunda-feira seguinte.

Começou o ano, começou o Blog.

Iterasys?

Uma empresa de tecnologia cuja especialidade é capacitar profissionais em teste de software e outras metodologias, técnicas e práticas relacionadas ao controle e gerenciamento da qualidade.

Para que uma empresa tem um blog?

Para abrir mais um canal de comunicação com seus clientes, fornecedores, parceiros e toda a sociedade. Novidades ou temas relacionados a empresa podem ser publicados e discutidos.

O blog vai falar de que?

Teste de software, qualidade, novidades e tendências.

De quanto em quanto tempo haverá um artigo novo?

Uma vez por semana é a periodicidade que pretendemos abrir novos temas. Porém, esse tempo pode ser menor em situações especiais. Segunda-feira foi eleita a data semanal de atualização.

Eu posso interagir?
Sim, seria ótimo receber a sua opinião. Se sentir dificuldade em expressá-la através do blog, envie um e-mail para contato@iterasys.com.br.

Vamos saudar o ano novo brasileiro e colocar nossas vidas, carreiras e empresas em progresso. Um ótimo 2008 e esperamos receber novamente sua visita em breve!