Olá pessoal!

Antes de falarmos de como a equipe de desenvolvimento do Google se organiza para realizar os testes, é preciso apresentar o autor da série “How Google Tests Software”. Seu nome é James Whittaker e é o Diretor de Engenharia em ferramentas de engenharia e testes nos escritórios do Google em Seattle e Kirkland. Tem o título de PhD em Ciência da Computação pela Universidade do Tennessee, publicou vários livros, já foi consultor de segurança e testes para diversas empresas e trabalhou por 3 anos como arquiteto na Microsoft.

Nas primeiras partes da série, James explica como as equipes de desenvolvimento e teste são organizadas.

A primeira importante informação sobre a equipe do Google é que há pouquíssimas pessoas dedicadas a testar o software. O que eles tem é uma equipe de testes voltada a prover todas as ferramentas, técnicas e facilidades para que o desenvolvedor possa realizar o teste.

Uma equipe de desenvolvimento no Google é formada por três tipos de papéis: o Engenheiro de Software (ES), o Engenheiro de Software em Testes (EST) e o Engenheiro de Teste (ET).

Os ESs são os tradicionais desenvolvedores. Desenvolvem as novas funcionalidades e garantem a qualidade destas funcionalidades de uma forma isolada. Eles são responsáveis por projetos tolerantes a falhas, TDD, testes unitários e trabalham em conjunto com o ESTs para escrever testes e exercitar o código da nova funcionalidade.

Os ESTs são desenvolvedores que fornecem funcionalidades de testes. Disponibilizam um framework que pode isolar o novo código desenvolvido, simulando dependências com stubs, mocks e fakes. Grande parte dos testes é feito pelo ES, e os ESTs estão lá para garantir que as funcionalidades são testáveis e atentos para verificarem se os ESTs estão envolvidos em escrever casos de testes. Eles são parte do ES, mas ficam focados no aumento da qualidade e cobertura de testes, ao invés de adicionarem novas funcionalidades ou aumentar a performance do sistema.

Os ETs, por sua vez, são o contrário dos ESTs. Para eles primeiro vem o teste, depois o desenvolvimento. Eles acumulam diversas funções voltadas a teste com foco no usuário. Eles organizam o trabalhos do ESs e ESTs, interpretam a execução e resultados dos testes, gastam boa parte do seu tempo escrevendo scripts de automação e código que simula um cenário de uso ou que até imite um usuário (como testes funcionais). São especialistas nos produtos, consultores de qualidade e analistas de risco.

Essa estratégia de organização de equipe é interessante, pois coloca desenvolvedores e a equipe de desenvolvimento voltada a teste em um mesmo nível de responsabilidade sobre o que está sendo produzido, colocando-os como parceiros, e não rivais. Como o Google tem um número de pessoas dedicadas a testar desproporcionalmente baixo, a responsabilidade fica com o desenvolvedor, e ninguém é melhor que ele para garantir a qualidade.

Aliás, segundo a visão de James, equipes que insistem em ter uma grande presença de pessoas dedicadas a testar estão geralmente assumindo que estão fazendo algo errado durante o processo de desenvolvimento, e adicionar mais pessoas para testar não irá resolvê-lo.

Na série disponível no blog do Google sobre testes (http://googletesting.blogspot.com/), e em artigos paralelos, você pode obter mais detalhes de cada papel e até analogias para entender a responsabilidade de cada um deles.

O próximo post da série falará um pouco de qualidade e dos canais de desenvolvimento que o Google usa para organizar o desenvolvimento.

Escrito por Dherik Barison