Aprenda agora a forma ideal para testar o seu software

Texto: Leonardo Miyagi
Imagem: Rafaela Brum

Testes, muitas vezes esquecidos ou até desprezados, fazem parte do desenvolvimento de todo software que se preze. Se uma falha acontecer na mão de um usuário, você não terá chance para se explicar. E assim, o negócio de alguém pode estar em risco por uma simples bobagem feita no código. Então, a melhor forma de garantir a qualidade do aplicativo que você está fazendo é testando ele.

Mas, afinal, de quem é a responsabilidade de testar a aplicação? É do desenvolvedor? Do analista de teste / tester (responsável por encontrar erros, falhas, bugs e outros tipos de problemas que não foram detectados durante o desenvolvimento de um software)? Do gerente de projeto / PO (profissional responsável por priorizar as atividades que maximizam o valor do produto e garantir o retorno do investimento)? A resposta é: todos. Sim, todos devem testar a aplicação, desde o início do desenvolvimento.

Para evitarmos futuras dores de cabeça e correções relâmpago, a equipe de desenvolvimento de software faz (ou pelo menos, deveria) testes em todas as aplicações produzidas. Testes de software são divididos primariamente em três categorias: unitários, de integração e ponta a ponta.

  • Testes unitários são feitos em partes isoladas do código, para cada componente. É como se testássemos cada “peça” de um aparelho antes de colocá-las. Vamos pensar que estamos montando um carro. Para garantir a segurança e evitar erros antes de unir todas as peças, é preciso testar cada uma delas separadamente. Por exemplo, para ter certeza que o veículo está funcionando normalmente antes de ir para o mercado, você tem que testar separadamente o freio, o volante, o câmbio, etc.
  • Testes de integração são testes unitários feitos em mais de uma parte do código. Eles juntam múltiplos componentes (normalmente 2) e verificam a comunicação e integração entre os mesmos. Este é o teste que garante que a ligação entre as peças está funcionando. Pense no caso do carro novamente: quando você utiliza o volante para dirigir-lo, a roda tem que responder ao pedido e mover o automóvel.
  • Testes de ponta a ponta são testes que validam todo tipo de comportamento possível dentro da aplicação, ou seja, simulam a atividade do usuário final. Se usarmos o exemplo do carro, esse tipo de teste seria dirigir o veículo após tudo estar finalizado, como se fosse o usuário normal. Garantindo assim que todas as peças do produto final e as comunicações entre elas estão funcionando corretamente.

Apenas os teste de ponta a ponta bastam?

Ora, mas se testes ponta a ponta simulam um usuário real, então, em teoria, é a melhor escolha:

  1. O desenvolvedor fica feliz, afinal a responsabilidade de testar não é dele
  2. O analista de teste fica feliz, pois consegue testar simulando um usuário real, então seus testes são mais valiosos
  3. O gerente do projeto / PO fica feliz, pois isso vai garantir que o usuário final terá uma experiência melhor

MAS, infelizmente, não é bem assim que funciona. Se dependermos apenas de testes de ponta a ponta, o procedimento ficaria algo mais ou menos assim:

  1. O desenvolvedor faz uma feature/versão e passa para o tester do seu projeto
  2. Se o tester encontrar algum bug, ele cria um relatório do erro, e o desenvolvedor é notificado
  3. O desenvolvedor verifica o erro, checa o código, e corrige o bug
  4. Após toda a validação, uma versão de produção é lançada e enviada ao cliente

O que foi vantajoso nesse processo?

  • Erros que afetariam diretamente o usuário final foram detectados e corrigidos.

O que houve de errado nesse processo?

  • Os desenvolvedores tiveram que esperar o relatório de bugs para poder resolvê-los;
  • Bugs pequenos podem estar escondidos atrás de bugs maiores;
  • Encontrar a causa dos bugs pode levar um bom tempo.

Obtenha um procedimento mais efetivo

A melhor forma de conseguir sucesso durante o processo é utilizando testes unitários:

Testes unitários são testes feitos em partes isoladas do código, verificando métodos e funcionalidades específicas de um componente. Por estarem isolados, é muito mais fácil encontrar e corrigir erros. São testes rápidos e confiáveis.

O grande problema dos testes de ponta a ponta é a espera – você não sabe do erro até que ele ocorra na mão de um possível usuário, ou seja, quando já é tarde demais. Testes unitários conseguem ser precisos, ou seja, você sabe o que deu errado com mais precisão, sem esperar chegar ao usuário.

Apesar de todas essas vantagens, há uma coisa que o teste unitário não faz: simular um usuário real.

Evite possíveis bugs

A melhor maneira de nos prevenirmos contra bugs no desenvolvimento é utilizar cada teste corretamente e também usar o nosso tempo durante este processo de forma mais eficiente.

Por isso, utilizamos a pirâmide de testes proposta pela Google:

img_blog

 

A sugestão é que se faça uma divisão de 70/20/10, ou seja:

  • 70% de testes unitários;
  • 20% de testes de integração;
  • 10% de testes de ponta a ponta.

Isso serve para tentar sempre evitar uma pirâmide invertida (focada em testes de ponta a ponta), ou em formato de ampulheta (foco em testes unitários e ponta a ponta, mas nenhum em integração).

 

*Este texto foi baseado em um artigo publicado pela própria Google, falando sobre testes de ponta a ponta (End-to-End Tests): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

 

 

 

Como simular internet lenta no ambiente de desenvolvimento

Recentemente trabalhando no desenvolvimento de aplicativos para iPhone me deparei com uma situação bastante comum – infelizmente – que é a velocidade de download de uma Internet 3G versus a performance da aplicação. Isso as vezes é difícil de testar no ambiente de desenvolvimento visto que estamos em uma rede Wifi e muitas vezes com uma conexão com a Internet infinitamente melhor que uma 3G, especialmente em São Paulo, que a rede é mais instável que o aceitável.

Por conta disso, fiz algumas pesquisas e encontrei uma forma legal de testar esse tipo de situação usando a Firewall do próprio MacOS X, o ipfw. O uso é bem simples, vou mostrar alguns comandos:

sudo ipfw pipe 1001 config bw 300KBits/s delay 200

Esse código cria um pipe com o identificador 1001 e configura dois parâmetros: A bandwitch (largura de banda) para 300 KBits/s, e um delay (latência) de 200 milisegundos. Esses dois parâmetros me simulam uma conexão 3G de 300 Kbps (típica da TIM) rodando em um servidor fora do Brasil, tipo o EC2 da Amazon que usamos, que dá uma latência média de 200 ms.

Depois de criar o pipe, temos que aplicá-lo em uma interface de rede com o comando:

sudo ipfw add 1 pipe 1001 src-port 3000

Esse comando cria a regra 1 e aplica o pipe 1001 quando a porta for 3000. Isso porque usamos a aplicação Rails em desenvolvimento na porta 3000 geralmente, mas você pode aplicar a um host na porta 80 se quiser.

Finamente, para excluir a regra você usa o comando abaixo:

sudo ipfw delete 1

Para saber mais sobre o ipfw, dá uma olhada na documentação oficial. Ahhh… se você usa linux, também funciona.

Vi aqui.

Dojo sobre TDD

No dia 13/08/2010 fizemos mais um DOJO, dessa vez  sobre Test Driven Development (TDD). Foi realizado na co.workingCG  e tivemos a presença de 15 pessoas: eu, Saulo Arruda, João Bosco, Edilmar Alves, Gilliard Cordeiro, Dantiele, João Paulo Sossoloti, Zé Ricardo, Jean Carlos, Leonides Fernando(Bart), Flávio Ricardo, Otávio Martins, Marcos Beirigo, Vinícius, Kristopher Murata.

Eu e o Saulo fizemos inicialmente a apresentação do problema (escrever números por extenso) e das principais técnicas de TDD em um pomodoro, em seguida a galera se dividiu em pares e começou a  criar os testes e implementação do problema sempre trocando o par a cada 5 minutos. A galera trabalhou em 3 pomodoros para a solução do problema e no intervalo de cada pomodoro a galera destruía os salgadinhos.

Dojo sobre TDD
Dojo sobre TDD com a utilização de pomodoros

Todas as fotos do Dojo:  http://www.flickr.com/photos/jerasoftware/sets/72157624634827957/with/4907479200/

Retrospectiva

Pontos positivos

  • Utilização de pares para programação, facilitando inclusive quem nunca mexeu com Java.
  • Utilização de pomodoros para gerenciamento do tempo.
  • Espaço disponibilizado pela co.workingCG.
  • Fazer amigos (comentário do Bart).
  • Salgadinhos e refrigerante.
  • Saulo não participou efetivamente, ficou nos bastidores. (Brincadeira)

Nem tão bom

  • Faltou um datashow.
  • Faltou TDD para uma aplicação Web.
  • Edilmar falou que os salgadinhos ficaram frios.
  • Faltou papel para rabiscar idéias.

Melhorar

  • Arrumar um DataShow.
  • Fazer um Dojo de TDD para uma aplicação web.