As pragas do teste de software — parte 2

No meu primeiro texto sobre as pragas do teste de software, falei sobre as pragas do foco, da repetitividade e da amnésia. Se você não leu o texto, recomendo fortemente a leitura por este link.

Agora se você trabalha com testes e teve a oportunidade de ler, o que mudou desde então? Se ocupa um cargo de liderança em sua empresa, já levou para o time e demais líderes as reflexões propostas? O tempo está passando, e temos que aprimorar o que fazemos para acelerar este ciclo de transformação positiva. Quanto mais pragas eliminarem, melhor será o resultado que você e seu time entregam.

Este é o segundo texto sobre as pragas do teste de software, adaptado de uma série de artigos de James Whittaker. Agora abordarei as pragas restantes que estão constantemente presentes no nosso dia-a-dia como testadores.

A praga do tédio

“Teste de software é tedioso”. Não finja nem por um momento que nunca ouviu um desenvolvedor, analista, ou qualquer outro “não testador” expressar esse sentimento. Agora pare um instante e procure no fundo de sua alma pela verdade. Mesmo o testador mais obstinado teria de admitir que já contraiu esta praga em algum momento. A execução de testes em um software dia após dia e o preenchimento interminável de relatórios de bugs simplesmente não interessam à maioria das pessoas que se sentem atraídas pela computação devido a seus aspectos criativos e reputação de desafiadora. Mesmo que você acredite ser imune a esta praga, tem de admitir que existem muitos aspectos monótonos e repetitivos associados ao nosso trabalho na área de teste de software.

Contudo, no início não é assim. No começo da carreira de um tester, a adrenalina da caça aos bugs pode mantê-lo motivado por vários meses. Neste estágio, a caça aos bugs pode ser tão envolvente quanto procurar um prêmio escondido em algum jogo de videogame. Durante os primeiros anos, os testadores evoluem muito em termos de habilidade, técnica e experiência, passando de iniciantes a muito bons em pouquíssimo tempo. Quem consegue reclamar de uma carreira que oferece tanto aprendizado, evolução e problemas intelectualmente interessantes?

Aqui, um parênteses: tudo isso é oferecido nos diversos projetos com os quais temos contato, mas se você não aproveita, não se desenvolve. Ou seja, de nada adianta ter tido contato com mil e um projetos (ou ter mil e uma certificações) se você não consegue explicar o motivo pelo qual toma as suas decisões técnicas, argumentando a favor ou contra algum ponto de vista. “Faço meus testes dessa maneira porque sempre fiz assim” é uma das respostas que escuto com recorrência nas centenas de entrevistas que fiz nestes últimos anos. Quando se espera escutar uma argumentação técnica, ter isso como resposta é desanimador no meu ponto de vista. (fecha parênteses)

Voltando à discussão sobre aprendizado, tudo pode ser muito legal. Porém, à medida que a curva de aprendizado se estabiliza, a execução de testes pode tornar-se repetitiva e rapidamente tediosa. Pessoalmente, acredito que essa seja a principal razão pela qual muitos profissionais de teste de software trocam para o desenvolvimento após alguns anos. Os desafios e a criatividade são afastados pela monotonia.

PRAGA DO TÉDIO - TESTER ENTENDIADO

Acredito que testadores entediados estão se esquecendo de algo. Acredito que apenas os aspectos táticos do teste de software é que se tornam repetitivos, e para solucionar este problema muitos recorrem à automação. Uma coisa é a automação de testes como uma poção para curar o tédio da execução de casos de teste e do relato de defeitos, mas automação não é substituto para os aspectos estratégicos do processo de testes. Aliás, comece a automatizar testes do mesmo jeito, sem pensar em inovações, e garanto que ainda assim a monotonia vai bater na sua porta. Trabalha com desenvolvimento e fica programando telinhas iguais o tempo todo? Vai rolar monotonia! Aqui está o pulo do gato: é justamente nos aspectos estratégicos que se encontra a cura para esta praga.

No projeto, decidir o que será ou não testado e em que proporção não é uma tarefa que é facilmente automatizável. Veja que a tomada dessa decisão é muito  interessante e desafiadora; e se eu te disser que teremos uma reunião emergencial com nosso cliente daqui a 20 minutos e que precisamos desta resposta? Mais interessante e desafiadora ainda, não? Também não é um problema simples ou automatizável monitorar os testes e decidir, estrategicamente, quando parar. O que testar, o que não testar, qual a melhor técnica para aplicar, são  problemas difíceis e estratégicos que irão banir a praga do tédio. Testadores podem sucumbir à praga do tédio ou podem mudar seu foco, saindo dos aspectos puramente táticos dos testes para um misto de aspectos táticos e estratégicos do teste de software. Você está inovando em seu projeto? Ou simplesmente faz mais do mesmo?

Garanta que na pressa para executar seus testes, você não deixe de lado os aspectos estratégicos de seu trabalho, pois são neles que estão os desafios técnicos e de alto nível que irão manter seu interesse na atividade de teste de software e manterão esta praga longe! Inove sempre, e não caia na cilada da monotonia.

A praga da casa nova

Dois grupos distintos de pessoas encontram bugs com frequência: os testadores (nas equipes de teste), que são pagos para encontrar tais defeitos, e os usuários que se deparam com eles por acidente. Obviamente os usuários não fazem isso de propósito, mas acabam ativando as falhas ao usarem o software para trabalhar (ou socializar, ou divertir-se, etc.). Com frequência, isto é resultado de uma combinação mágica entre a interação da aplicação com usuários reais, utilizando dados reais e em um ambiente real. Não é óbvio que os testadores deveriam se esforçar para recriar tais dados e ambientes em seus laboratórios de teste, a fim de encontrar tais defeitos antes que o software seja entregue?

Na verdade, a comunidade de testes vem tentando com afinco e por décadas fazer justamente isso. Eu chamo isso de “trazer o usuário para o laboratório de testes”, seja em corpo ou espírito (através de técnicas baseadas em perfis de uso). O próprio James Whittaker trata de estatísticas e perfis de uso em sua tese de doutorado, muito embora ele não seja o pioneiro nos estudos deste tópico. Contudo existe um limite para o sucesso de tais empreitadas. Testadores simplesmente não conseguem ser usuários reais ou simular suas ações de uma maneira realista o suficiente para encontrar todos os bugs importantes. A menos que você efetivamente viva no software, você irá deixar passar defeitos importantes.

É como adquirir uma casa nova. Não importa quão bem a casa seja construída. Não interessa o quão cuidadosos sejam a construtora e seus subcontratados durante a obra. A casa pode ser inspecionada minuciosamente a cada etapa do processo de construção, pela construtora, pelo proprietário e pelo fiscal. Existem alguns problemas que só serão encontrados uma vez que a casa seja ocupada e por algum tempo. A casa precisa ser usada, é preciso jantar nela, dormir nela, tomar banho nela, cozinhar, farrear, relaxar, enfim… é preciso fazer todas as coisas que os proprietários de uma casa fazem em suas casas. Só quando o filho adolescente tomar um banho de uma hora enquanto a irrigação do jardim está ligada é que se perceberá que o sistema hidráulico é deficiente. Só quando tentarmos estacionar o carro na garagem é que perceberemos uma rebarba na coluna. Os construtores não vão, e com frequência não conseguem, perceber tais problemas.

PRAGA CASA NOVA - TESTE DE SOFTWARE

 

O tempo também influi. É preciso alguns meses com lâmpadas queimando, semana sim, semana não, para perceber um curto na fiação. É preciso um ano para que as cabeças dos pregos saiam das paredes secas. Esses são problemas para o proprietário, não para os construtores. Esses problemas são equivalentes aos vazamentos de memória (memory leaks) e perda de dados (data corruptions). É preciso tempo para encontrar estes defeitos.

Estes são alguns defeitos que simplesmente não podem ser encontrados enquanto ninguém more na casa, e com software não é diferente. O software precisa passar por usuários reais, realizando trabalho real, em ambientes reais, para que alguns defeitos apareçam.

A equipe de teste não é proprietária de nenhuma casa. Podemos fazer o que podemos, e nada mais. É importante entendermos nossas limitações e nos planejarmos para o inevitável feedback dos usuários. Fingir que o projeto acaba quando a aplicação é entregue é simplesmente errado. Existe um período de garantia que estamos subestimando e que ainda é parte do processo de teste.

Eu, por exemplo, adoro acompanhar nos canais digitais (e estimular meu time também a acompanhar) o que vem sendo falado pelos usuários finais a respeito dos projetos em que fizemos testes. É muito legal quando observamos feedback positivo após o lançamento de novas versões, pois nos passa a certeza de que conseguimos gerar valor de fato. Da mesma forma, ver feedback negativo também é bom, pois nos permite tirar insights, revisar a estratégia, e inclusive transformar aqueles feedbacks em novos casos de teste para futuras versões.

A praga da cegueira

Imagine jogar videogame com os olhos vendados ou com o monitor auxiliar desligado. Você não consegue monitorar a saúde de seu jogador, seus sistemas de mira estão perdidos! Você fica sem radar e sem nenhum sistema de avisos. Nos jogos, a inabilidade de acessar a informação sobre o mundo do jogo é debilitante e um ótimo jeito de ter seu jogador morto.

Existem muitos aspectos do teste de software que se enquadram no espectro invisível. Software é invisível. Nós o vemos apenas através da interface com muita coisa acontecendo debaixo dos panos, fora do alcance de nossos olhos. Não é como construir um carro, onde é possível ver peças faltantes e muitos engenheiros podem olhar o carro e enxergar exatamente a mesma coisa. Não existe discussão se um carro tem ou não seu amortecedor instalado, ele está a vista, onde todos os envolvidos podem vê-lo. O mesmo não acontece com software, o qual existe como flutuações magnéticas em uma mídia de armazenagem, as quais não são muito úteis de se ver.

O teste de software é como jogar videogame com os olhos vendados. Não podemos ver falhas no código, não podemos ver a cobertura na maior parte dos casos, não podemos ver também as mudanças no código. Essa informação, vital para nós testadores, está escondida em relatórios estáticos inúteis. Se alguém nos colocasse uma venda, poderíamos sequer perceber!

blur-close-up-device-442576

Essa cegueira com relação ao nosso produto e seu comportamento cria problemas reais para realização dos testes. Que partes do software foram mais testadas por testes de unidade? Que partes foram alteradas de uma versão para a outra? Que partes possuem defeitos em aberto? Que parte do software um caso de teste específico cobre? Que partes foram testadas rigorosamente e que partes não receberam atenção alguma?

Nosso tradicional remédio para nossa cegueira é medir a cobertura do código, APIs, métodos ou mesmo interface. Nós escolhemos as coisas que conseguimos ver melhor e medimos, mas isso realmente nos diz algo? Fazemos isso há anos, não porque é interessante, mas porque é o que nossa cegueira nos permite fazer. Interagimos muito com as aplicações testadas, mas precisamos confiar no feedback de sentidos menos apurados para saber o quão efetivo está sendo nosso esforço.

Testadores de software podem aprender muito com o mundo dos jogos. Liguem seus monitores auxiliares e vejam a informação que tem ignorado. Existe poder na informação.

Assim como as pragas da do foco, da repetitividade e da amnésia estão presentes no nosso dia-a-dia, as pragas do tédio, da casa nova e da cegueira também nos assolam no nosso cotidiano como testadores. Cabe a nós trabalhar constantemente para não deixar com que elas nos afetem, encontrando meios eficientes de realizar testes cada vez melhores.

Hora de promover mudanças em seu trabalho! Está preparado? Vale a pena, eu garanto!

Ajude a compartilhar este conteúdo com seus amigos do trabalho, e se tiver alguma dúvida sobre as pragas ou quiser conversar sobre o assunto, entre em contato comigo através do e-mail bruno.abreu@sofist.com.br ou ligue em (19) 3291-5321. Vai ser um prazer conversarmos!