Desenvolvimento

28 nov, 2018

As pragas do Teste de Software – Parte 02

209 visualizações
Publicidade

Na primeira parte do artigo, sobre as pragas do teste de software, abordamos as pragas da repetitividade, da amnésia e do tédio. Caso não tenha lido, pode acompanhar a leitura aqui.

Já nessa segunda parte falaremos sobre mais algumas pragas:

  • A praga da casa nova (The Plague of Homelessness)
  • A praga da cegueira (The Plague of Blindness)

A praga da casa nova (The Plague of Homelessness)

Essa praga se inicia com uma pequena definição. São dois grupos distintos que encontram bugs com frequência: os testadores e os usuários, que acabam se deparando com os erros quase que na maioria das vezes sem querer. Isso acontece com a combinação da interação da aplicação com usuários reais, utilizando dados reais e em um ambiente real.

Por mais que pareça que testar com esses dados é a função do tester, nem sempre é tão fácil. Na verdade, é bem isso que os testers tentam fazer. Porém, simplesmente não conseguem ser usuários reais ou simular suas ações de uma maneira mais real possível, a fim de encontrar todos os bugs importantes.

É como comprar uma cadeira. Ela foi testada e aprovada por alguém, é perfeita aos olhos da equipe que a desenvolveu. Porém, ao ser vendida, o comprador tem um tamanho diferente e o piso de sua casa é de madeira.

O cliente senta na cadeira em seu escritório e não gosta, não se sente à vontade na mesma. Ele então quer devolver a cadeira, pois não é por ela que ele pagou – ela não é confortável como ele queria, ela risca o piso de madeira, etc. Pronto, está encontrado aí um bug causado pela interação do usuário real em ambiente real.

O tempo também pode interferir. Só após um tempo que as rodinhas da cadeira irão parar de rodar por ter um certo peso na cadeira por um certo tempo.

Às vezes o pensamento acaba sendo de que esse é um problema para o comprador e não para quem fez a cadeira, mas temos que nos atentar a isso para sabermos como nosso software estará daqui a algum tempo.

A equipe de testes não tem escritório em casa e não usa essa cadeira. O importante é entender as limitações da equipe de testes, e estar sempre preparado para os feedbacks que possam vir, e jamais fingir que após entregue o projeto tenha deixado de existir.

Uma coisa bacana de se fazer em casos em que o projeto que você testou está em uma loja de aplicativos como a Play Store, é acompanhar feedbacks de usuários e ir ajustando seus testes para contemplar essas situações e garantir que esteja cada vez mais nos aperfeiçoando e garantindo o máximo de qualidade possível.

A praga da cegueira (The Plague of Blindness)

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.

O teste de software se enquadra bastante em um espectro invisível, pois o software é invisível e visto apenas através de uma interface, sem que o que acontece por debaixo dos panos esteja ao alcance dos olhos.

Diferente de uma bicicleta que se pode ver que existem peças faltantes, quando um responsável olhar para a bicicleta ele verá que nela está faltando o freio, e não tem discussão de que se tem ou não freio, pois isso é óbvio.

Então testar é como jogar videogame com os olhos vendados. Não conseguimos ver falhas ou as mudanças no código. e essa é uma informação importantíssima para que nós, testers, possamos traçar estratégias, definir e escrever casos de teste para cobrir as alterações, e assim garantir que o sistema continue funcionando da maneira esperada.

Sem estas informações fica difícil medir quais casos de testes contemplam quais partes do código e do sistema, e também qual parte do código é a mais testada e qual está sendo deixada mais de lado.

O remédio mais comumente utilizado é medir a cobertura do código, APIs, métodos ou mesmo interface, pois escolhemos aquelas coisas que melhor vemos e medimos – isso realmente nos diz algo relevante?

Fazemos isso há anos porque é o que a nossa cegueira nos deixa fazer. Interagimos bastante com aplicações, e precisamos confiar em feedbacks para saber o quão efetivo está sendo nosso esforço.

Diante das pragas apresentadas tanto na parte um quanto na parte dois da série de artigos, na sua opinião, quais seriam as outras pragas?

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.