Desenvolvimento

8 nov, 2018

As pragas do Teste de Software – Parte 01

288 visualizações
Publicidade

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 02 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 se encontra 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 os bugs desprevenidos!

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

Dentre as pragas da amnésia existentes, existe 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 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 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.

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

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. Porém, a automação não deve ser utilizada para curar a monotonia, mas sim como uma ferramenta.

A cura para essa 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), e 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.

As demais pragas serão abordadas nos próximos artigos que poderão ser acompanhados no portal.

Referências

***

Artigo escrito em parceria com Robson Cachoeira. Formado em sistemas de informação pela UNIPAR – Francisco Beltrão – PR, Robson 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.