Livros Recomendados #2: How Google Tests Software

O segundo livro da sério no blog é um livro para pessoas mais experientes. O livro escrito pelo famoso James A. Whittaker (ex-diretor de testes do Google) e pelos então Googlers Jason Arbon and Jeff Carollo.

Sobre os autores

James Whittaker
James Whittaker

James Whittaker: Um dos engenheiros mais conhecidos sob o aspecto “teste de software”, James tem muitos anos de experiência, é PhD em Ciência da computação pela Universidade de Tennessee-Knoxville, escreveu livros como “How to Break Software“, “How to Break Web Software” (coautor com Mike Andrews), “How to Break Software Security” (coautor com Herbert H. Thompson) e “Exploratory Software Testing“. Como profissional ele trabalhou na direção de empresas como Microsoft e Google onde durante mais de dois anos foi diretor de testes trabalhando principalmente no Google Chrome, Google Maps, and Google Web Apps. Além de escrever esse livro, mantinha publicações periodicamente no blog de testes do Google.

Jason Arbon

Jason Arbon: Formado em Electrical and Computer Engineering na Universidade de Utah, Arbon também passou pela Microsoft e posteriormente no Google, onde trabalhou principalmente nos produtos Google Desktop, Chrome, and Chrome OS. Sua colaboração além desse livro, pode ser vista em diversos projetos open-source e em publicações no blog de testes do Google. Atualmente ele tem sua própria startup chamada Herecandy (http://herecandy.com/) e é Engineering Director na uTest (www.utest.com).

Jeff Carollo

Jeff Carollo: Bacharel em Ciência da Computação pela Texas A&M University trabalhou em empresas como Microsoft, Hewlett-Packard (HP), IBM Research e Google, sem contar o início de carreira na NASA. Atualmente ele é Engenheiro de software na uTest (www.utest.com), mesma empresa em que Jason Arbon trabalha.

Apesar de nenhum dos autores trabalhar atualmente no Google, pelo que eu acompanho nas publicações do blog Google Testing Blog, o conteúdo ainda é bem fiel, sem falar que o livro é relativamente novo, pois foi publicado em abril deste ano. Outro bom motivo para ler esse livro é que ele foi finalista do Jolt Award (http://www.drdobbs.com/joltawards), uma das premiações mais importantes para livros técnicos, prêmio que esse ano foi faturado por um dos nossos próximos reviews e citado com frequência aqui no blog, Specification by Example do Gojko Adzic [11].

Sobre o Livro

No meu ponto de vista esse é um livro voltado para pessoas com mais experiência e dificilmente eu o recomendaria para um iniciante. Os assuntos abordados no livro vão de definições arquiteturais do código de testes, passando por iniciativas para disseminar cultura de testes automatizados em larga escala até processos e ferramentas para suporte ao teste de software, como builds de integração continua.

How Google tests Software
How Google tests Software

O Google é uma empresa inovadora e está sempre um passo a frente em quase tudo, e com teste não é diferente. Ainda me lembro que no ano passado (2011) o Alberto Savoya indiretamente causou um alvoroço no DFTestes por causa da palestra Test is Dead [3], que mais tarde deu origem aos posts Testing 2.0 [4] e para os dois posts em português do José Carreira [5], além de vários outros posts, apresentações e artigos sobre Testers/QAs Técnicos.

Essa palestra falava muito mais sobre focar no “o quê” do que focar no “como”, algo parecido com os conceitos abordados no livro The Lean Startup [6] do Eric Ries, mas fatalmente foi confundida com “deixe os testers morrerem, só precisamos de engenheiros”. O ponto é que o Google possui dezenas de Software TE (Test Engineers), que são Testadores com conhecimento mais básico de automação/programação e foco em testes exploratórios e no negócio, que é descrito e muito discutido nesse livro e também no blog post Conversation with a Test Engineer [7], em uma interessante entrevista com um desses “novos velhos testers”, onde explicam a diferente entre os “tipos” de testers do Google.

Além disso, um dos melhores, senão o melhor livro sobre testes exploratórios da atualidade, o Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design [8], foi escrito pelo James Whittaker, que na época trabalhava como um dos líderes de teste dentro do Google. Por todos esses motivos e tantos outros que eu poderia detalhar aqui, independentemente do meu ponto de vista esse seria um livro muito interessante para testadores/desenvolvedores, principalmente os que almejam um lugar na mais cobiçada empresa de software do mundo.

O ponto é que o meu review aqui é muito positivo, e eu poderia escrever um pequeno livro com comentários, notas, exemplos e teorias sobre diversos aspectos que lidos nesse livro, mas vou tentar me limitar a um conjunto bem sucinto de destaques que eu notei ao decorrer da leitura. Para mais, consulte os comentários e reviews na Amazon Store [9].

Alguns pontos que chamaram a minha atenção

Vocabulário

O Google criou o seu próprio vocabulário, como uma saída para facilitar a disseminação do conhecimento e facilitar a comunicação entre os Googlers. A princípio eu pensei “Porque criar uma nomenclatura exclusiva, se já existe uma nomenclatura na comunidade?”. Daí eu pensei na quantidade de nomes que temos para as mesmas coisas e ninguém consegue se entender. A comunidade open-source tem seu vocabulário, o ISTQB tem outro, o QAI tem outro, desenvolvedores muitas vezes tem outro e no final, não sabemos quem está certo.

Isso me fez pensar que ao entrar para o Google, durante algum tempo você se sente desconfortável de usar os nomes small, medium e large tests para unit, integration and system tests, mas que depois de algum tempo convivendo com o novo vocabulário você se acostuma e ao mesmo tempo isso evita os problemas de ego e a dependência de entidades externas.

O Google build inteligente

Muitos de nós sofremos com builds demoradas e constantemente esse é o assunto de blog-posts, livros e apresentações em eventos. Um dos principais motivos para isso é que muitas vezes existem centenas de testes executando sem necessidade, pois nossos testes são executados de forma linear, passando por todo o pipeline.

O Google sofria com esse problema também, até que criaram um sistema de identificação dos testes que devem ser executados para cada mudança. Toda vez que o código é modificado, um “robô” identifica quais são os testes que devem ser executados, economizando recurso computacional para outro testes muitas vezes de outros produtos e tempo do build que pode fornecer um feedback muito mais rápido para o desenvolvedor.

Test Certified e Test Contest

O Google criou uma iniciativa muito interessante para incentivar e “culturizar” desenvolvedores em teste. Uma espécie de CMMi interno baseado em soluções técnicas que iam desde o básico como “conhecer a cobertura de testes” no nível 1 até itens mais sofisticados como “ter testes automatizados para cada defeito major” no nível 5.

O mais interessante foi que essa estratégia, além de criar melhorias de curto prazo como a melhoria dos testes nos projetos, o que incluía código legado que não estava sequer preparado para ter testes automatizados, também tinha uma visão muito forte a longo prazo, que era a disseminação da cultura de testes, que tornou o Google uma das principais referências em testes poucos anos depois. ps: No final do capitulo 2 tem uma entrevista com as pessoas que criaram esse processo e eles entram em alguns detalhes sobre como implementar isso em outras empresas. Vale a pena conferir.

Entrevista com um SET (Software Engineer in Test)

Outro ponto muito interessante. O Google está na lista das entrevistas mais difíceis segundo o Glassdoor.com[1], e um dos fatores para isso pode ser porque o processo de contratação de desenvolvedores e testadores é o mesmo. Para engenheiros de software em teste, além de problemas de teste são propostos problemas de desenvolvimento idênticos aos problemas apresentados para candidatos a vagas de desenvolvimento [2].

De acordo com o livro, é muito observado a forma com que as perguntas são interpretadas. Quando um problema é apresentado por exemplo, é da natureza de um desenvolvedor pensar em uma solução, o que o direciona para escrever código, enquanto uma pessoa com mindset de testador normalmente realiza perguntas e tenta encontrar problemas antes de pensar em qualquer solução.

Testes Baseados em Riscos Usando Atributos, Componentes e Capacidades (ACC)

Os autores explicam como é feita a definição dos testes baseados em Atributos, componentes e capacidades [10] inclusive usando um exemplo baseado no Google+. Para saber mais da minha opinião e review dessa abordagem leia o post Testes Baseados em riscos com Google Test Analytics aqui no blog, ou para um post do google consulte “Google Test Analytics – Now in Open Source” [12].

Ainda falando de ferramentas de suporte ao TE, o livro comenta sobre o Google Test Case Manager (gerenciador de casos de teste manuais) e sobre o Bugnazer (bugtracking), mas que aparentemente não são tão diferentes do que estamos acostumados como TestLink e Mantis.

A diferença entre Software Engineers in Test e Test Engineers por Jason Arbon

Esse pequeno texto vale os pouco mais de dez dólares pagos no livro. Jason Arbon conseguiu sintetizar um texto em que qualquer Tester se define como SET ou TE em poucos minutos, embora (no meu ponto de vista) não é difícil que bons testers se identifiquem com pontos de ambos os perfis.

Afirmações interessantes e até divertidas como “Você sabe que é um TE quando não consegue entender porque temos que digitar ‘i’ antes de começar a escrever em um certo editor de texto” ou “Você sabe que é um SET quando prefere um terminal de linhas de comando do que um interface gráfica de usuário e raramente toca o mouse”. Esse texto pode ser visto quase que completo no preview do livro no Google Books [13]

Bots

Jason Arbon descreve como criar bots para vasculhar a internet e comparar webpages no Chrome com as mesmas webpages em outros browsers fez com que em 48 horas, fossem executados testes que antes só seriam possíveis com um ano de testes manuais.

Esses bots navegavam na internet com o Google Chrome usando o  WebDriver, inicialmente procurando por defeitos no browser e mais tarde foi evoluído para comparar as páginas do Chrome com o Firefox. Além de comparar com outros browsers, ele também realizava comparação entre versões mais antigas do Google Chrome. Mas claro que não foi fácil fazer isso, o algoritmo teve de ser escrito com inteligência o suficiente para entender que algumas páginas como o CNN.com e YouTube.com mudam conteúdo quase que a todo minuto, e isso não é um bug. Toda a experiência é bem detalhada no cap 2.

Browser Integrated Testing Environment (Google BITE)

O Google BITE é uma ferramenta bem interessante. Ela funciona como um plugin para o Google Chrome, e o objetivo é reduzir o trabalho manual durante report de defeitos e execução de testes manuais, tanto para testes exploratório quando para testes seguindo test cases. Para mais consultar o Google Testing Blog [14] ou entenda na prática procurando por “Google BITE” no Google App do Google Chrome ou baixando e executando você mesmo no Google Code [15].

O futuro do teste no google

O Google é uma das primeiras empresas a admitir que o teste de software como conhecemos, está caindo. Segundo o livro, os SETs vão se tornar cada vez mais desenvolvedores e os TEs vão se tornar cada vez mais pessoas focadas no negócio. Essa transformação não só mostra que a raíz agil, que a dez anos dizia que não precisávamos de “especialistas em teste” ou em outras categorias, mas sim generalistas em software estava certa, como mostra que finalmente estamos alcançando essa maturidade. Segundo os autores, os desafios a partir de agora serão muito mais técnicos e gerenciais do que manuais. O perfil de profissional que mantiver nesse caminho pode estar em risco nos próximos anos.

Lendo o Livro em Forma de Blog Posts

Muito do conteúdo do livro pode ser encontrado no Google Testing Blog (googletesting.blogspot.com), citado várias vezes neste post e inúmeras vezes no próprio livro, e como eu sou muito “bonzinho”, separei alguns dos posts do blog Google Testing Blog de acordo com os capítulos do livro:

Cap 1 – Introduction to Google Software Testing

How Google Tests Software: Part One

The difference between QA, QC, and Test Engineering

Testing 2.0 (Também em cap. 5)

The Difference Between QA, QC, and Test Engineering

Cap 2 – The Software Engineer in Test

Covering all your codebases: A conversation with a Software Engineer in Test

Test Engineering at Google

Test Sizes

How Google Tests Software: Part Five

Automating Tests vs. Testing-Automation

How We Tested Google Instant Pages

How Google Tests Software – part VI

Cap 3 – The Test Engineer

Conversation with a Test Engineer

Testability Explorer: Measuring Testability

How Google Tests Software: Part Seven

The FedEx Tour

Exploratory Test on Chat

Google Test Analytics is Now in Open

The 10 Minutes Test Plan

Take a BITE out of Bugs and Redundant Labor

Cap 4 – The Test Engineering Manager

If You Were a Brand New QA Manager

If You Were a Brand New QA Manager (Cont…)

Cap 5 – Improving How Google Tests Software

Talk: Test is Dead (Palestra na integra)

How Google Tests Software – A Break for Q&A

Claro que o livro detalha muito mais cada um dos tópicos e que a abordagem do livro é mais didatica e completa do que no blog, mas o pelo blog podemos estudar bastante do que está no livro e aumentar o nosso apetite por essa leitura. Espero que aproveitem ambos.

Conclusão

Esse é um livro “must read” para todo desenvolvedor e testador sênior. O livro é bem completo, bem transparente e sem dúvida mais uma grande contribuição do Google para a nossa comunidade. Meu conselho e entender que o livro não é um “How to become Google”, mas sim um conjunto de experiências, depoimentos e práticas que o Google podia compartilhar em um livro de pouco mais de 300 páginas, portanto não espere que somente a leitura desse livro te transforme em um QA do futuro, mas sim que o livro te ajude a entender como teste de software é muito mais do que planejar a execução de alguns testes ou uma arquitetura de automação, pois envolve o pensamento primordial de sustentar através de tecnologia, a melhor estratégia para garantir que o cliente tenha o que agregue mais valor para ele.

Ler um livro como esse, que te da fatos e exemplos acompanhados de conceitos e teorias pode te empolgar (assim como fez comigo), por isso tente entender o valor de cada prática e cada exemplo que encontrar durante a leitura, e caso queira implementar algo, planeje com calma e lembre-se de adaptar para a realidade da sua empresa, sempre lembrando que não é porque o Google faz ou por que deu certo no ambiente deles que essa vai ser a melhor estratégia para a sua empresa/projeto.

No mais é um livro muito técnico (do ponto de vista conceitual) mas ao mesmo tempo muito fácil de ler. Muito barato para o conteúdo que oferece e como citei anteriormente, focado em práticas e exemplos, bem detalhados e com o significado de cada um bem explicito. Caso esteja procurando por um conjunto de boas práticas técnicas, principalmente para os seus projetos com integração continua, automação de testes e teste técnico, compre e seja feliz :)

Referências:

[1] http://www.glassdoor.com/blog/top-25-difficult-companies-interview-consulting-firms-lead/

[2] http://googletesting.blogspot.com.br/2011/04/set-career-path.html

[3] http://www.youtube.com/watch?v=X1jWe5rOu3g

[4] http://googletesting.blogspot.com.br/2012/08/testing-20.html

[5] http://bytesdontbite.com/?s=test+is+dead

[6] http://theleanstartup.com/

[7] http://googletesting.blogspot.com.br/2012/09/conversation-with-test-engineer.html

[8] http://www.amazon.com/Exploratory-Software-Testing-Tricks-Techniques/dp/0321636414

[9] http://www.amazon.com/Google-Tests-Software-James-Whittaker/product-reviews/0321803027/ref=dp_top_cm_cr_acr_txt?ie=UTF8&showViewpoints=1

[10] http://code.google.com/p/test-analytics/wiki/AccExplained

[11] http://www.drdobbs.com/joltawards/jolt-awards-the-best-books/240007480

[12] http://googletesting.blogspot.com.br/2011/10/google-test-analytics-now-in-open.html

[13] http://books.google.com.br/books?id=vHlTOVTKHeUC&pg=PA128&lpg=PA128&dq=the+difference+between+sets+and+tes+by+jason+arbon&source=bl&ots=ipl4ay9GP_&sig=QRsQzQA4i2ok4-KBTkI2TyoAPjw&hl=en&sa=X&ei=PAaxUMvzAYaQ8wSjoYAg&redir_esc=y#v=onepage&q=the%20difference%20between%20sets%20and%20tes%20by%20jason%20arbon&f=false

[14] http://googletesting.blogspot.com.br/2011/10/take-bite-out-of-bugs-and-redundant.html

[15] http://code.google.com/p/bite-project/

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

One thought on “Livros Recomendados #2: How Google Tests Software

  1. Muito bom o review trazendo várias informações extras e links interessantes. Já está na minha lista de “must read”.

    É muito bom ver outro profissional da área que sabe dar valor há algo praticamente esquecido hoje em dia: Ler bons livros para se aperfeiçoar como profissional.

    Sigam o exemplo não fique atrás da velha desculpa “Na teoria é uma coisa e na prática é outra”.

Leave a Reply