Testes Baseados em Riscos com Google Test Analytics

Quem acha que só de automação vivem os testers no Google vai tomar um susto com esse post. Uma ferramenta pouco conhecida, que lembra o velho Testlink (mas muito mais enxuto e objetivo) é parte do dia a dia dos engenheiros da maior empresa de software do mundo. Uma ferramenta de interface simples mas com um conceito bem interessante, o Google Test Analytics usa uma abordagem baseada em riscos que mescla os Atributos, Componentes e Capacidades do software sob testes para derivar casos de teste e testes exploratórios.

A ferramenta que inicialmente foi desenvolvida internamente para planejamento dos TEs (Test Engineers) do Google hoje está disponível para quem quiser conhecer e clonar. Ao contrário do que muitos pensam, o processo de planejamento de testes do Google não é nada monstruoso, definido por softwares de inteligência artificial que usam algoritmos de complexidade exponencial, muito pelo contrário, é feito como nas nossas empresas, com a criatividade e atenção que só um bom profissional pode ter.

Imagem 1: Exemplo de capacidades para o blog The Bug Bang Theory

 

Mas atenção, essa ferramenta não é para definição de centenas de casos de teste, o que ela faz é aplicar um conceito útil para planejamento baseado em riscos, mostrando graficamente a relação entre componentes e as atributos do sistema, e derivando capacidades desta relação. Podemos usar essas capacidade para conhecer o sistema, identificar riscos e derivar testes. Em alguns casos outros elementos podem ser usados para identificar os componentes ou atributos mais complexos, como por exemplo bugs ou cobertura de testes.

A ferramenta é nova pra mim também mas me parece bem simples. Vou tentar fazer um overview no formato passo-a-passo aqui no blog, enquanto eu exploro o Google Test Analytics. Para esse experimento vou usar o blog The Bug Bang Theory como produto sob testes. Continue reading

Aprendendo automação sem cursos caros

Quanto mais fazemos algo, ficamos mais experientes no que praticamos. Sabemos disso, pois não adiantam cursos e mais cursos de inglês se não introduzirmos no nosso dia a dia, não adianta ler um bom livro técnico se não introduzirmos o conhecimento no nosso cotidiano e etc. Com automação não é diferente.

Mas como podemos introduzir automação no nosso dia a dia se nem ao menos trabalhamos com isso?

Terminal usando irb e Firefox com os resultados para os comandos executados usando Watir-Webdriver e Ruby

Existe uma maneira muito simples e totalmente gratuita de se acostumar com os frameworks de automação que temos por aí, e quando falamos de acostumar com esses frameworks, não estamos falando puramente de sintaxe, mas das limitações que eles nos oferecem, com tecnologias e técnicas secundárias que nos confrontamos durante automação de testes (como json, css, xpath, etc), com HTML e Javascript, com os erros retornados pelo código, com a linguagem de programação que eles usam, com a documentação desses frameworks etc.

Para isso você não precisa de cursos caros, ferramentas milagrosas, um sistema operacional diferente ou quaisquer outras coisas. Pra ser bem sincero você só precisa de muita vontade de aprender, pois a tarefa que vem aí, embora seja bem simples e fácil, é meio chata no começo.

A linguagem de programação ruby nos fornece um recurso para trabalhar no console/terminal executando pequenos pedaços de código chamada Interactive Ruby Shell mais conhecido como irb. O irb é muito usado por desenvolvedores para testar pequenos pedaços de código, executar tarefas simples, debugging entre outras atividades. Ele fornece uma forma de executar pequenos trechos de código com muita flexibilidade e com todos os recursos que a linguagem ruby oferece.

Com a ajuda desse recurso vamos praticar um pouco de automação hoje com esse breve tutorial e você vai poder praticar diariamente usando o seu framework preferido.

Como?

Você vai praticar watir-webdriver ou selenium-webdriver, ou ambos agora :) Basta escolher. Mesmo sem nenhum conhecimento em automação de testes ao final você vai postar um comentário neste post utilizando apenas um terminal e algumas linhas de comando :) Para isso, escolha a sua ferramenta e siga as instruções abaixo. Continue reading

Agile Brazil 2012: Boas Práticas de Teste Automatizado

Esse ano tive o prazer de falar para uma plateia gigantesca sobre algo do dia a dia, testes automatizado. O Agile Brazil é o maior evento da cultura ágil da América Latina e uma das maiores conferências sobre agilidade do mundo. Um palco onde figuras como Martin Fowler (ThoughtWorks), Philippe Kruchten (Rational Software), Klaus Wuestefeld (sneer.me), Jim Highsmith (ThoughtWorks), Joshua Kerievsky (Refactoring to Patterns) e tantos outros compartilharam suas ideias. Esse ano, outros nomes marcaram presença como Neil Ford (ThoughtWorks), James Shore (The Art of Agile Development) e Khawaja Shams (NASA), entre outros tantos grandes nomes do Agile. Sem falar na galera presente na comunidade de teste brasileira como o Mauricio Aniche (Caelum) e Jorge Diz (MAPS S/A).

Agile Brazil 2012

A minha palestra em par com o Carlos Palhares (ThoughtWorks) falou sobre testes automatizados, e tentamos guiar a palestra para mostrar situações ou desafios que encontramos durante o dia a dia quando automatizamos testes, os erros comuns que cometemos ao tentar resolver esses desafios e algumas técnicas que podemos usar para evitar os problemas desses erros. Para quem acompanha o blog, foi uma abordagem parecida com o post “Penso, logo automatizo“.

Importante: Não estamos em momento algum propondo uma “bala de prata” para nenhum dos problemas que serão apresentados aqui, mas uma solução mais elegante para tratar de alguns problemas comuns que encontramos em códigos por aí.

Cada uma das implementações que tentamos evitar aqui pode ser útil em alguma situação específica ou mesmo as soluções que recomendamos podem ser um problema em dezenas de outras situações. Cada caso deve ser estudado separadamente e a decisão deve ser tomada por alguém com total contexto sobre todo o ambiente do problema. Entretanto, os casos apresentados aqui representam experiências positivas e negativas dos autores durante algum projeto real.  Continue reading

Voto Como Vamos: Ágil, Open-Source e One-Click Deploy sem custo

O projeto Voto Como Vamos foi uma das coisas que me marcou esse ano. É simplesmente fantastico ver o potencial de pessoas apaixonadas pelo que fazem em ação. Digo isso porque esse projeto foi desenvolvido com 100% de trabalho voluntário e com um objetivo muito nobre: A conscientização política.

No início eram quatro ou cinco pessoas de um grupo que queria melhorar de alguma forma o modo como candidatos e eleitores se relacionavam em Porto Alegre, o grupo Porto Alegre Como Vamos e a ThoughtWorks cedeu espaço para que eles pudessem falar com a gente sobre esse projeto estranho de nome mais estranho ainda, o Voto Como Vamos.

No início, vimos o vídeo abaixo e alguns dos membros do Porto Alegre como vamos falaram com a gente sobre alguns detalhes e expectativas que eles tinham com o projeto, entre eles, os fatores mais críticos do projeto… custo deve ser baixo e o release deve ser em quatro semanas, integração com sistemas do governo, gestão do cadastro dos candidatos, integração com redes sociais…


Resumindo o vídeo, o Voto Como Vamos é um projeto desenvolvido por um grupo apartidário chamado Porto Alegre Como Vamos, formado por jovens apartidários da sociedade civil, que visa melhorar a cidade de Porto Alegre. O objetivo desse projeto é aproximar candidatos e eleitores criando um canal de comunicação colaborativo através de redes sociais, principalmente o Facebook. Continue reading

The Developers Conference: O Mundo Precisa de QAs Técnicos!

Esse ano tive a oportunidade de apresentar algumas notas e pensamentos no #TDC2012 (The Developers Conferente) que sem dúvidas é um dos maiores eventos para profissionais de software no Brasil. Em primeiro lugar gostaria de agradecer ao Elias Nogueira, Jorge Diz e Leonardo Oliveira que avaliaram minha apresentação, me convidaram para o evento e me deram todo o suporte que eu precisava, parabenizar a Yara, Vinicius Senger e toda a equipe Global Code pelo evento muito bem organizado e pontual, agradecer aos meus amigos ThoughtWorkers que ajudaram na revisão, especialmente Mozair, Babi, Ghisi e Mathias, e claro, agradecer a ThoughtWorks por mais uma vez me enviar a um evento de cinco dias em outro estado com tudo pago :) Provavelmente eu não poderia aceitar o convite do TDC sem esse apoio.

The Developers Conference 2012

No evento eu pude me reencontrar com amigos do teste como Elias, Sarah, Leo Oliveira, Galani e José Correia e pude conhecer outros que não conhecia pessoalmente como o Diz, Cristiano Caetano, Wandi, Eduardo Souza, Alan Correa e Eder Ignatowicz além de conversar com dezenas de outros profissionais de teste de software e ouvir alguns bons feedbacks sobre o blog, sobre o evento e sobre as talks.

Outro ponto muito positivo foi o “Testing Hour” promovido pela Iterasys na Sexta-feira em um bar ao lado da Universidade em que o evento aconteceu, o que promoveu um network legal e uma discussão mais relax sobre diversos temas vistos nas palestras.

O evento contou com números expressivos no número de trilhas, de inscrições e de palestrantes. Uma das coisas que me surpreendeu foi que as trilhas mais cheias e com maiores filas de espera foram as trilhas de Testes e Testes University, o que demonstra um enorme interesse da comunidade de testes, que por incrível que pareça se mostrou muito mais presente do que comunidades conhecidas por lotar eventos e marcarem presença como Agile, Ruby e Java. Parabéns para nós :D

O Mundo Precisa de QAs Técnicos

Essa notícia foi muito boa e bate exatamente com alguns dos problemas que vamos ver abaixo, o que é muito bom, pois esta é uma das provas que estamos mudando esses problemas aos poucos.

Além as trilhas Testes e Testes University eu também biquei as trilhas de Ruby, Dados Abertos e Agile que mantiveram a mesma qualidade das palestras e o alto nível dos palestrantes.

A minha apresentação no TDC teve o título “O Mundo Precisa de QAs Técnicos”. Claro que a apresentação é muito mais baseada no meu ponto de vista e no ponto de vista de muitos profissionais que eu admiro, por tanto muitas pessoas podem e vão discordar de muitos tópicos abaixo, mas acredito que em alguns pontos essas mesmas pessoas vão concordar.

O fato é que o termo tester, QA entre outros relacionados aos profissionais e a área de Qualidade/Teste de software vem sofrendo transformações ao longo dos anos e algumas falácias e estereótipos aparecem junto com a sua popularização. De uma certa forma, como todos os papéis/cargos em informática e computação testes também é uma área nebulosa, e acaba por não ter definições e é sobre esses problemas que falamos nessa talk. Continue reading

Livros recomendados #1: Agile Testing – A Practical Guide for Testers and Agile Teams

Estou começando com esse post, uma série de posts que vão falar sobre a livros técnicos que no meu ponto de vista influenciaram muito no meu conhecimento. Nesta série estão previstos vários livros além deste, como Lessons Learned in Software Testing, Specification by Example, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation , The Art of Software Testing, Exploratory Software Testing, Test Driven Development: By Example, Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional,  Handbook of Usability Testing, Capacity Planning for Web Performance: Metrics, Models, and Methods entre vários outros livros importantes para quem trabalha com teste de software.

Essa série de posts é uma forma de ajudar a popularizar a leitura técnica entre os testadores do Brasil, visto que muitas vezes não lemos tantos livros técnicos quanto developers ou project managers por exemplo, o que acaba nos tornando muito dependentes das mesmas terminologias e conceitos distribuídos por uma ou outra certificação, em muitos casos, estando em desacordo com as novas tendências ou com aplicabilidade contestada pelo estado da arte, descrito nesses livros.

Outra motivação para esses posts, é demonstrar como estamos desatualizados em comparação com os livros internacionais no Brasil. Nossos principais livros ainda se baseiam inteiramente em modelos ultrapassados como cascata, modelo de desenvolvimento em V e documentação IEEE829, o que é extremamente prejudicial a qualidade dos nossos profissionais, visto que a maioria deles se atualiza por esses livros. Isso faz com que a maioria desses profissionais acabem optando por metodologias antigas em contramão ao mercado internacional, deixando de lado conceitos “mais recentes” como TDD, BDD, ATDD, Continuos Integration, xUnit Test Patterns, BDD, DDT, Continuous Integration entre vários outros, além de criar dependência de modelos tradicionais de desenvolvimento de software, comprometendo a adaptação desses profissionais em empresas com desenvolvimento ágil e enfraquecendo o profissional brasileiro no mercado exterior.

O primeiro livro da série é o “Agile Testing – A Practical Guide for Testers and Agile Teams” da Lisa Crispin e Janet Gregory, um clássico do teste de sotware no mundo inteiro, com a assinatura do Mike Cohn e publicado pela grande editora Addison Wesley.

Agile Testing - A Practical Guide for Testers and Agile Teams

O livro é relativamente novo, foi escrito em 2008 e aborda o tema “Agile Software Development” focando em times com ou sem testers, mas falando sobre o teste de software no contexto ágil. Em outras palavras, originalmente muitas pessoas acreditam que times ágeis não precisam de profissionais especialistas em teste de software, o que em muitos times não deixa de ser verdade, mas como visto no foreworks do próprio Mike Cohn e do Brian Marick e em relatos como o do Jonathan Rasmusson apresentado no primeiro capitulo, esses profissionais fazem uma diferença muito grande no time. De qualquer modo, o livro não discorda desse ponto de vista, mas várias vezes afirma que os profissionais de teste de software são essenciais para um melhor aproveitamento em projetos de desenvolvimento ágil.

Lisa Crispin

Sobre as Autoras:

Lisa Crispin é uma das mais respeitadas testers com várias publicações em importantes periódicos da IEEE, da Better Progrmming, da Methods and Tools entre outros, além de ser co-autora do livro também sobre testes ágeis intitulado Testing Extreme Programming também da Addison Wesley (2002) e ter participado no cap “Beautiful Testing as the Cornerstone of Business Success” do livro Beautiful Testing: Leading Professionals Reveal How They Improve Software. Lisa ainda é uma evangelista dos testes ágeis, participando abertamente de comunidades, redes sociais, fóruns, listas de discussão e com e-mail aberto para ajudar a quem pedir. Sem dúvidas uma atitude louvável de uma das pessoas mais importantes quando falamos de teste de software em nível global.

Janet Gregory

Janet Gregory é a fundadora da consultoria de processos ágeis e treinamento DragonFire, Inc. trabalha com testes ágeis desde 1998, implementando processos de teste de software em empresas de todos os tamanhos. Ela também se apresenta em vários seminários e conferencias sobre ágil e sobre teste de software, além de ser considerada a maior colaboradora da comunidade de testes ágeis da américa do norte. Assim como a Lisa, colabora em blogs, fóruns, listas e redes sociais. No ano passado ela participou do Bratestes da ALATS, inclusive ministrando um treinamento sobre automação em times ágeis.

O livro conta com a colaboração de diversos outros grandes nomes da comunidade ágil e com relatos várias ocasiões onde as autoras escrevem sobre suas experiências ou por meio de terceiros comentam alguns casos de sucesso. Continue reading

ThoughtWorks Brasil Tech Radar – O Test Radar

What is hot… and what is not in software testing?

Essa últimas duas semanas foram completamente insanas na ThoughtWorks Brasil. Recebemos mais de quarenta visitantes de outros países e tivemos a oportunidade de conversar sobre dezenas de aspectos tanto da ThoughtWorks, quanto sobre justiça social e sobre o futuro de tecnologias.

Com a visita do Mike Mason (Head of Technology, Americas da ThoughtWorks) nós fizemos um exercício bem interessante, como se fosse um mini Tech Radar dentro do nosso escritório. Achei muito bom poder discutir e argumentar com o pessoal, e claro, expor o que um QA julga ser interessante ou não nessa sopa de letrinhas composta por ferramentas, técnicas, plataformas e etc.

Para quem não conhece, o ThoughtWorks Tech Radar é um conhecido jornal anual de tecnologia desenvolvido por um grupo sênior de tecnologistas chamado ThoughtWorks Technology Advisory Board que classifica diversas tecnologias, ferramentas, plataformas, técnicas e linguagens de programação em quatro níveis que são:

  • Adopt (Use) – Acreditamos fortemente que esses itens estão maduros e são confiáveis o suficiente para serem usados em projetos, e de fato são usados em nossos projetos. Acreditamos que a indústria deveria optar por essas soluções ao invés das demais citadas no Tech Radar.
  • Trial (Experimente) – Esses itens parecem confiáveis e podem ser usados em projetos que possam assumir um certo nível de risco.
  • Assess (Explore) – Experimente esses itens buscando o entendimento e como tirar proveito deles, mas eles ainda representam um grande risco para o projeto.
  • Hold (Melhor esperar) – Tenha cautela. Esse item pode ser muito novo para ser usado em projetos, pode ser questionável do ponto de vista técnico ou pode não ser produtivo se comparado com outros itens no mercado.

Se quiser saber mais sobre o Tech Radar pode acessar a página da ThoughtWorks sobre o assunto: http://www.thoughtworks.com/radar

O formato do nosso mini Tech Radar foi baseado em quatro passos:

  1. Brainstorm sobre diversas ferramentas que usamos no dia a dia, que ouvimos falar muito no mercado ou na comunidade, que gostaríamos de saber se alguém usa e que tivemos experiência em projetos, sejam ele open source  ou produtos.
  2. O segundo passo era um tempo para que cada um falasse um pouco sobre os itens que ele adicionou no quadro, de forma bem superficial, só para que todos conhecessem ou lembrassem desse item.
  3. Depois disso cada um pode colocar os seus itens no que eles julgavam que deveriam estar.
  4. Em um quarto passo, o grupo observava o quadro e questionava cada um dos itens lá colocados, e acredite…, isso deu muito barulho.
Quadro com itens alinhados após a discussão (Clique para ampliar)
Quadro com itens alinhados após a discussão (Clique para ampliar)

Eu chamo esse post de Test Radar porque vou focar nos itens mais importantes para QAs e Testers no meu ponto de vista. Claro que o quadro possui plataformas e linguagens de programação que são parte do nosso dia a dia e influenciam diretamente na nossa produtividade e na qualidade dos nossos projetos, mas por serem itens mais relacionados a desenvolvedores, vou esperar que algum developer presente nesse exercício escreva o ponto de vista dev e incluo aqui.

É importante ressaltar que esse post são as minhas notas e opiniões sobre um exercício inspirado pelo ThoughtWorks Tech Radar e representam somente a minha percepção sobre a discussão:) Continue reading