Ao avaliarem o que será testado no software, o Google assume que há 3 tipos diferentes de testes: o pequeno, o médio e o grande. Cada um deles dá ênfase diferente no montante do código que será testado e em como ele será feito. A seguir, há alguns detalhes de como cada um é tratado:

Testes pequenos: são normalmente automatizados e interagem apenas com uma função ou módulo do software. Podem necessitar de mocks e ambientes falsos para serem executados. O objetivo desses testes é verificar se não há problemas comuns, como corrupção de dados, condições de erros, etc. A questão que o teste pequeno deve responder é: este código está fazendo o que deveria fazer?

Testes médios: podem ser automatizados ou manuais, e envolvem 2 ou mais funcionalidades e cobrem a interação entre estas funcionalidades. Uma descrição para esses testes é “teste a função e seus vizinhos mais próximos”. A questão que o teste médio deve responder é: este conjunto de funcionalidades estão interoperando da maneira que deveria?

Testes grandes: cobrem várias funcionalidades e representam cenários de uso real. A questão a ser respondida é: o produto funciona da maneira que o usuário espera?

James reforça que não importa como esses testes são chamados. O importante é a equipe ter uma linguagem comum para falar sobre o que vai ser testado. Sobre o que vai ser testado e como vai ser testado, esse é um processo dinâmico e varia muito de produto para outro.

A mistura entre testes manuais e automatizados abrange todos os 3 tipos de testes. Se algo pode ser automatizado e não requer intervenção humana, então ele deveria estar automatizado.

A indústria esforça-se para automatizar os seus testes, fazendo com que eles sejam executados a cada nova versão do sistema, garantindo mínimas regressões e mantendo os testadores manuais focados apenas nos novos itens. O Google também automatiza a submissão de bugs. Se um teste automatizado “quebra”, o sistema determina qual das últimas mudanças no código é a culpada mais provável, envia um e-mail para seus autores notificando o ocorrido e registra o bug.

A próxima e última parte da série reunirá algumas idéias que surgiram ao longo dos textos apresentados, de modo que poderemos refletir em como melhorar o processo atual de testes em uma realidade diferente do Google, como é o caso da Dextra.

Escrito por Dherik Barison