As Pragas do Teste de Software – Parte 1

Não pode ler agora? Ouça esse conteúdo durante suas atividades:

Segundo James A. Whittaker, existem as chamadas “Pragas do Teste de Software”, que resumem problemas vividos no cotidiano de testers. Algumas delas são: 

• A praga da repetitividade (The plague of Repetitiveness) 
• A praga do tédio (The Plague of Boredom) 
• A praga da amnésia (The Plague of Amnesia) 
• A praga da casa nova (The Plague of Homelessness) 
• A praga da cegueira (The Plague of Blindness)
  

Hoje, falaremos um pouco sobre as 5 pragas acima. Em breve, teremos aqui uma parte 2 com as outras duas Pragas do Teste de Software. Vamos lá?

A praga da repetitividade (The plague of Repetitiveness)

A praga da repetitividade pode estar relacionada à falta de propósito. 

Propósito: Segundo o dicionário é aquilo que se busca alcançar; objetivo, finalidade, intuito. Ou então a intenção (de fazer algo) ou ainda projeto. 

Questões para se refletir: 

• Há algum plano ou conhecimento conduzindo nossos testes, ou estamos apenas apertando teclas e explorando funcionalidades esperando que algum defeito apareça milagrosamente?  
• O conhecimento em testes adquirido e os momentos de “insight” estão sendo disponibilizados para que outros testadores tenham acesso e não precisem “reinventar a roda”, ou estão guardados a “sete chaves”? 

Caso as respostas às questões acima não venham de imediato: eis aí a falta de propósito! 

Registrar e avaliar os sucessos alcançados, as lições aprendidas e compartilhar com o time e não ficar no “just do it”, —-(apenas faça – frase conhecida da Nike – bem aplicada aos exercícios físicos, entretanto não recomendada para os testes de software)– é um bom começo para tentar evitar a falta de propósito! 

Como a falta de propósito = “just do it”, a praga da repetição = (“just do it” * “just do it” * “just do it”) …. Ou seja, a praga da repetição é um “just do it” feito várias vezes. 

A praga da repetitividade está também relacionada ao paradoxo do pesticida de Boris Beizer, no qual o pesticida é usado para matar os insetos, no entanto se for aplicado o mesmo pesticida várias vezes, os insetos que restarem se tornarão imunes aos efeitos dele.  

A mesma ideia ocorre para os testes. Se utilizarmos sempre as mesmas estratégias e a mesma maneira de testar, teremos uma falsa sensação de segurança e ausência de bugs, podendo assim mascarar métricas, resultados e completude dos testes. O que está realmente ocorrendo é: os testes realizados estão deixando de ser abrangentes, ficando “velhos” e inevitavelmente tornando-se obsoletos, podendo criar uma versão repleta de super-defeitos, imunes ao nosso “testicida”.  

Quando não encontra-se bugs nos sistemas e aplicações, não é porque não existem. Uma das causas pode ser a repetitividade que está causando o paradoxo do pesticida. 

Analisando com mais atenção os resultados dos testes (tanto manuais quanto os automatizados), verificando e retirando os que não estejam mais agregando valor, variando a ordem dos testes e as fontes de dados, criando novos ambientes para execução, alterando valores de entrada, etc, são algumas das possíveis formas de evitar o problema da repetitividade e o paradoxo do pesticida, “pegando assim de jeito” os bugs desprevenidos! 

A praga da amnésia (The Plague of Amnesia)

Dentre as pragas da amnésia existentes, há a amnésia da equipe. 

• Amnésia da Equipe: Aparentemente a cada novo projeto ou novo desafio que surge, as experiências, bugs, testes, falhas anteriores são simplesmente “esquecidos”, fazendo assim com que os mesmos voltem a ocorrer, pois têm-se a ideia de que novas oportunidades, seriam novos começos, no entanto são novos objetivos para uma equipe mais experiente. Percebe-se claramente: o que falta é uma maneira de reter e compartilhar esses conhecimentos adquiridos, seja por meio de Wiki’s, documentações, registro das lições aprendidas, artigos, treinamentos, capacitações, etc, que estejam disponíveis e de fácil acesso. 

via GIPHY

Questões para refletir sobre a equipe ou projeto no qual está trabalhando, que já trabalhou ou que irá trabalhar: 

• Como você (ou sua equipe) testará o próximo projeto lançado por sua empresa?  
• Quanto conhecimento coletivo foi desenvolvido a partir das tecnologias já utilizadas?  
• Quanto do que foi aprendido testando as versões anteriores do software poderia auxiliar?  

• Quanto do que foi aprendido daria para ser reaproveitado?  
• Com que facilidade as equipes de testes desses projetos iriam se adaptar a esse novo desafio?  
• Será que a maioria das dificuldades nessas novas empreitadas seriam iguais aos que já foram encarados anteriormente? Provavelmente sim! 
• Afinal, será que conseguiremos nos recordar?
  

A praga do tédio (The Plague of Boredom)

“Testar software é tedioso”. Essa é uma frase que com certeza não se ouve apenas uma vez na vida de quem trabalha com desenvolvimento de software, normalmente dito por um dev, analista ou qualquer outro “não testador”.  

via GIPHY

Como consequência das pragas anteriores (praga da falta de propósito, praga da repetitividade e praga da amnésia) ou de outras situações, acaba-se chegando a praga do tédio e com certeza todo tester algum dia já contraiu tal praga, mesmo que não admita ou não se lembre. Isso acontece porque passar dias e mais dias executando os mesmos testes, abrindo bugs, retestando e retestando acaba sendo monótono, ainda mais para quem entrou para a área da computação pelo desafio proposto pela mesma. 

Lógico que isso começa a partir de um certo momento da vida do tester, pois no início existe uma certa adrenalina de caça aos bugs. O grande aprendizado nos primeiros meses, seja ele de ferramentas, metodologias, sistemas, regras de negócio e o conhecimento adquirido tão rapidamente pelos projetos em que passamos acaba nos mantendo motivados. 

E a medida que a curva de aprendizado se estabiliza é que a execução dos testes de forma repetitiva começa a se tornar tediosa, e muitos testers começam a automatizar achando que isso ajuda a passar a monotonia. Mas a automação não deve ser utilizada para curar a monotonia e sim como uma ferramenta. A cura para esta praga passa por parar e olhar o projeto em que você está atuando, e definir o que é e o que não é importante, o que precisa realmente ser executado todo dia (se precisa ser executado sempre, automatize), o que pode ser deixado de lado algumas vezes. Com isso em mente, aí sim entra a automação para diminuir o tempo de execução repetitiva (ela ainda vai existir, mas em menor escala). Isso é inovar e/ou empreender no projeto/empresa em que atua. Essa é uma possível cura para a praga do tédio. 

Quer conhecer as outras pragas de teste? Leia na parte 2 desse artigo!

 

Referências 

Ensaios de Qualidade – Pragas do Teste de Software

One Day Testing – As Pragas do Teste de Software – Parte 1

One Day Testing – As Pragas do Teste de Software – Parte 2

Esse artigo foi escrito por:

Andressa Karla Pilar

Cursando 4º ano de Informática na Universidade Estadual de Maringá. Trabalha como Analista de Testes em vários projetos há aproximadamente 3 anos na DB1 Global Software. Possui certificações CTFL e CTFL-AT. Apaixonada por Qualidade de Software e por Automação de Testes Web e Mobile. 

Robson Cachoeira

 Formado em sistemas de informação pela UNIPAR – Francisco Beltrão – PR. Trabalha como Analista de Testes há 6 anos, e em vários projetos há 2 anos e meio na DB1 Global Software. Atualmente, atua como Coordenador de Testes da unidade de IT Services da DB1. Apaixonado por cerveja, desafios e resolver problemas. “May the test be with you”.