As Pragas do Teste de Software – Parte 2

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

Na primeira parte do artigo sobre as pragas do teste de software, abordamos sobre 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, iremos falar 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 da pessoa e o piso de sua casa é de madeira.

 

via GIPHY

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 esta em uma loja de aplicativos como a PlayStore, é acompanhar feedbacks de usuários e ir ajustando seus testes para contemplar essas situações, e garantir que estamos 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. 

 

via GIPHY

Então testar é como jogar videogame com os olhos vendados. Não conseguimos ver falhas ou as mudanças no código, esta é 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 I quanto na parte II da série de artigos, na sua opinião quais seriam as outras pragas? Chame o pessoal do Comitê de Testes para discutirmos e tentarmos minimizar ou eliminar de vez essas pragas, pois aqui na DB1 não é o lugar delas! Deixe sua opinião nos comentários 😀 

 

Referências 

http://ensaiosdeqa.blogspot.com.br/2009/09/pragas-do-teste-de-software.html 

https://testing.googleblog.com/2009/06/7-plagues-of-software-testing.html 

https://testing.googleblog.com/2009/08/7th-plague.html 

http://blog.onedaytesting.com.br/pragas-teste-software-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”.