Evento percorrerá as principais capitais brasileiras com objetivo de discutir formas de trabalho mais eficientes para a área de Teste de Software. As primeiras duas cidades confirmadas são Fortaleza e São Paulo.

Um evento feito por Testadores para Testadores.

São Paulo: 18 de setembro (sábado)
Fortaleza: 13 de outubro (quarta-feira)

Horário: 08:30 - 18:00

Investimento:
- Participantes: R$ 140,00
- Alunos e Ex-alunos: R$ 70,00

O investimento pode ser parcelado em 2X no boleto ou cheque.

O valor pago poderá ser utilizado integralmente como desconto em qualquer curso da Iterasys.

Conteúdo e inscrições pelo site da Iterasys

Iterasys :: Líder pela Qualidade
Patrocinador da Trilha de Testes no TDC 2010, CinTeQ 2010 e expositora no Brateste 2010

(11) 3254-4915 begin_of_the_skype_highlighting              (11) 3254-4915      end_of_the_skype_highlighting begin_of_the_skype_highlighting              (11) 3254-4915      end_of_the_skype_highlighting | (11) 3254-7625 | contato@iterasys.com.br | @iterasys

O ganhador será apurado e divulgado em 18/agosto/2010.

Pela primeira vez, o já tradicional evento de desenvolvimento terá uma trilha de Testes, organizada pela comunidade Testadores e patrocinada pela Iterasys. Participe!

Data:20 de Agosto de 2010 - sexta-feira
Horário: 8:30 - 18:30
Local: Universidade Anhembi Morumbi - R. Casa do Ator, 275 - Itaim Bibi - São Paulo/SP
Investimento: R$ 20,00 (valor simbólico)

Sorteio de Credencial VIP em 18/Ago | Sorteio de Vale Descontos no evento
Veja quais serão as palestras apresentadas por instrutores da Iterasys

Saiba mais sobre o evento e as promoções relacionadas

No exame realizado em 1º de Julho, 85,7% dos alunos do preparatório conquistaram a certificação. Sem contar os alunos que participaram de outros treinamentos que também colocaram com sucesso o seu conhecimento a prova.

Parabéns aos alunos e professores pelo excelente resultado!

Visite o site para ver o banner com o nome dos aprovados e conheça as turmas abertas (hoje estão publicadas apenas as de SP, mas a partir de 23/07 estarão também as dos demais estados).

Local: São Paulo - Unidade Paulista 2
Data: 31 de Julho (sábado)
Horário: 9:30 ás 11:30
Palestrante: Elias Nogueira, CSTE
Investimento: Gratuíto

Conteudo Programático e Inscrições: Site da Iterasys

Sobre a Iterasys:
Principal centro de treinamento brasileiro em Teste de Software e Garantia da Qualidade, único credenciado ALATS, BSTQB/ISTQB e QAI.

Conheça também o Curso de Formação em Teste de Software:
Treinamento com 120 horas, sendo 64 horas sobre processos e técnicas de Verificação e Validação acrescidas de 56 horas práticas em automação de testes com as ferramentas VirtualBox, Mantis, Testlink, JUnit, Code Analysis, JMeter, Badboy e Selenium.

Próximas Turmas:
- Alphaville - Segunda à Sexta - 18:00 às 22:00 - início: 9 de Agosto
- Campinas - Sábados - 09:00 às 18:00 - início: 7 de Agosto
- Rio de Janeiro - Sábados - 08:30 às 17:30 - início: 14 de Agosto
- São Paulo - Sábados - 09:00 às 18:00 - início: 7 de Agosto

Seja um procurado. Faça Iterasys!

Iterasys :: Lider pela Qualidade

Patrocinador do CInTeQ 2010 e expositor no Brateste 2010.

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.