A primeira sessão está lotada e a das 12 às 14h tem apenas mais 7 vagas. Os interessados devem se apressar.

Estamos comemorando a aprovação dos alunos do Curso Preparatório para a CTFL.

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).

As vagas se esgotaram em menos de 10 horas. Mudamos a palestra para uma sala maior, mas temos apenas 15 vagas remanescentes. Se quiser participar é melhor se inscrever rápido!

Iterasys convida para Palestra de Selenium.

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.

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.

De 19 a 21 de maio, a UNIBAN promove uma série de palestras sobre TI. Estarei apresentando o tema “Certificações Profissionais em Teste de Software e Garantia da Qualidade”, porém abordando apenas as três principais linhas certificatórias: ALATS, ISTQB e QAI.

Agradeço ao Prof. Celso Arruda e ao Sr. Carlos Souza pela oportunidade de divulgar as certificações aos estudantes e a comunidade.

Programação:
- Carreira em Teste de Software e Garantia da Qualidade
- Profissões, cargos e salários
- Perfil dos Profissionais
- Crescimento do número de vagas
- As três principais certificações (CBTS, CSTE e CTFL)
- Como se preparar para os exames

Data, Hora e Campus:
19/05 - 08:00 UNIBAN SUL - Morumbi
19/05 - 19:45 UNIBAN ABC
20/05 - 08:00 UNIBAN Campo de Marte
20/05 - 19:45 UNIBAN Campo Limpo
21/05 - 08:00 UNIBAN Osasco
21/05 - 19:45 UNIBAN Osasco

Agradeço ao Prof. José Eduardo Deboni e ao Fábio Martinho Campos pela oportunidade de divulgar nossos treinamentos durante o seminário do GTS-IPT (Grupo de Estudo sobre Teste de Software do Instituto de Pesquisas Tecnológicas) sobre o tema “Certificações em Teste de Software” realizado em 28 de abril.

As certificações foram apresentadas com grande neutralidade e de forma bastante ampla e espero ter conseguido colaborar com minha experiência a cerca da CBTS (Certificação Brasileira de Teste de Software) da ALATS (Associação Latino-Americana de Teste de Software) e da CSTE (Certified Software Tester) do QAI (Quality Assurance Institute).

O GTS-IPT é aberto a interessados pelo tema, conheça o trabalho do grupo e participe. A apresentação e material referenciado no seminário estão disponíveis http://groups.google.com.br/group/gts-ipt/web/seminrio-sobre-certificao-em-teste.

Surgiu o convite, prontamente aceito, de realizarmos um debate sobre “Certificações x Mestrado” que acredito ocorra no próximo semestre. A data será oportunamente divulgada neste blog e no site do GTS-IPT.

QAI Brasil (Quality Assurance Institute Brasil) e Iterasys realizarão seminário sobre resultados e tendências em Teste de Software.

A evolução da área de Teste, certificação profissional. análise e mitigação de riscos, o valor da Verificação: um caso de sucesso, e a virtualização de ambientes de teste são os temas que serão apresentados e discutidos.

Data
Terça-feira, 15/04/2008

Horário
18:30 às 22:30

Investimento
R$ 90,00/participante

Este seminário vale 4 pontos para a recertificação CSTE/CSQA

Agenda

Hora Tema
18:30 Recepção e Welcome Coffee (Networking)
18:45 Abertura: Introdução Iterasys - Apresentação QAI/Certificações em Software
19:15 Aumento do Nível de Capacidade do Processo de Teste de Software
20:20 Estudo de Caso: O Valor da Verificação
20:50 Coffee break e Networking
21:10 Análise e Mitigação de Riscos através do Processo de Teste de Software
21:50 Workshop: Virtualização de Ambientes de Teste de Software
22:30 Considerações finais e encerramento

Local
IMAM - Rua Loefgreen, 1.400 - Vila Mariana
Estacionamento no local
Próximo a estação Santa Cruz do Metrô

Inscrições
QAI Brasil - Tel.: (11) 3048-4018 com Valéria

Diversos sites de noticias publicaram nota de imprensa sobre a parceria do QAI Brasil com a Iterasys, entre eles:

QAI Brasil e Iterasys firmam parceria em São Paulo

Iterasys passa a ser agente local da QAI e assume a realização dos cursos preparatórios e dos exames para certificações internacionais

A QAI Brasil, instituição especializada em serviços de consultoria e treinamentos na área de teste e qualidade de software acaba de firmar mais uma parceria estratégica em São Paulo. Desta vez é com a Iterasys, empresa de tecnologia dedicada à melhoria do processo de desenvolvimento de software. Com o acordo, a Iterasys passa a funcionar como agente local da QAI para a oferta de treinamentos e certificações.

“Nossa idéia é pulverizar a oferta de certificações internacionais em toda a região de São Paulo”, afirma Fernando Scarazzatto, responsável pelas operações da QAI no Brasil.

Na prática, a Iterasys assume a realização dos cursos preparatórios na região de São Paulo. “Agora contamos com mais um agente capacitado na capital para suprir a demanda de treinamentos, que vem crescendo nos últimos meses”, completa Scarazzatto.

Atualmente, a QAI oferece duas certificações no Brasil: a CSTE (Certified Software Tester) e a CSQA (Certified Software Quality Analyst). A primeira estabelece padrões para a qualificação dos profissionais e oferece um direcionamento para a função de testes. “A obtenção do título CSTE indica o nível de proficiência nos princípios e práticas do controle de qualidade na área de TI”, explica Scarazzatto.

Por sua vez, a certificação CSQA estabelece padrões para a qualificação e melhoria contínua das competências profissionais. Seu programa foi desenvolvido para identificar a capacidade do profissional em auxiliar a gerência na melhoria da qualidade dos sistemas de informação, avaliar sua habilidade para aplicar seu conhecimento e oferecer uma fundação para obtenção de reconhecimento profissional.

“Os profissionais com certificação CSQA contribuem com as funções de garantia de qualidade (QA) e do controle de qualidade (QC), além de participar dos grupos de engenharia de processos de software e de gerenciamento quantitativo baseados em métricas. Eles estão muito presentes no início de novos projetos, na melhoria de processos de software e na redução das ineficiências em sistemas, reduzindo custos e ampliando o ROI”, completa.

Sobre a QAI – Fundada em 1980, nos Estados Unidos, a Quality Assurance Institute é uma organização formada hoje por mais de mil membros corporativos em todo o mundo, cuja missão é compartilhar métodos considerados “o estado da arte em teste de software”, assim como ferramentas e técnicas de garantia de qualidade em TI. Estas soluções são oferecidas ao mercado sob a forma de serviços de consultoria, educação, treinamento e certificações profissionais.

Mais informações:
Comuni Marketing –Assessoria de Imprensa
Coordenação de Imprensa: Márcia Becker (mbecker@comuni.com.br)
Contato: Rafael Passos (rpassos@comuni.com.br)
Tel: 11-5501-4007