Getting Technical I: Três Passos pra Começar

Esse é o primeiro de pelo menos cinco posts sobre tecnologias, ferramentas ou práticas de viés técnico para aumentar produtividade e diferenciar o seu currículo. Esses posts vão reunir quinze, dos muitos elementos que fazem parte do dia a dia de um QA.

Em alguns casos vamos falar de uma ferramenta em particular, como o Jenkins ou o Rake. Escolhi as ferramentas com base no que eu trabalho, mas sinta-se a vontade para escolher uma ferramenta alternativa. O importante é conseguir o benefício. Se esta usando Java provavelmente vai ser melhor usar o Gradle do que o Rake por exemplo.

Eu não fiz nenhuma pesquisa profunda, com formulários ou monografia, mas estou no mercado a algum tempo e converso bastante com pessoas em foruns e listas, além é claro de ser um recrutador de novos QAs para times em diferentes empresas desde de 2007. Juntei um pouco do que eu sinto que está faltando, especialmente nos QAs do Brasil. Sinta-se a vontade para comentar outras necessidades ou se acha que algum dos itens não deveria estar aqui. Fazendo isso me ajuda a melhorar a minha percepção.

1 – Mude para o Linux

Terminal do Linux
Terminal do Linux

O básico de qualquer engenheiro, desenvolvedor ou tester é saber operar Linux. A maioria das applicações web hoje em dia (e sempre) são suportadas por Linux. A maioria dos testes automatizados, rodam mais rápido ou são mais fáceis de executar em Linux. Não existem contra argumentos. Em algum momento da sua vida você vai ter que trabalhar com Linux. Porque adiar o inevitável?  Abrace a mudança e aprenda antes que lhe seja cobrado ou antes de perder aquela oportunidade de entrar em uma empresa mais legal.

Substituir Windows por Linux ou mesmo MacOS em casa pode ser o primeiro passo. Ganhando confiança e ficando basicamente produtivo, pode substituir o sistema que usa no trabalho também. Se ja trabalha em um ambiente que usa Linux, mas usa Windows para ter Internet Explorer, use uma maquina virtual com Windows e trabalhe no Linux. A curva de aprendizado usando todos os dias, para ficar minimamente produtivo, no meu caso foi de três meses.

O linux te permite fazer instalações de ferramentas modernas em segundos. O Linux também tem todas as IDEs mais famosas (exceto Visual Studio e percursores), o que torna a adaptação ainda mais fácil no caso de ambiente desenvolvimento.

Além de todas as vantagens listadas acima, por ter um terminal muito mais amigável e o fantástico apt-get, o Linux também vai facilitar e potencializar o uso das próximas ferramentas. Download Ubuntu (more…)


Destilando JMeter II: Vamos escrever testes!

Leituras recomendadas antes desse artigo: “Destilando JMeter I: Introdução e Conceitos” e ”http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Don’t be evil! Use o JMeter para o bem :]

Esse é o segundo post da série Destilando JMeter. Esse artigo foca nas principais dúvidas do dia a dia para quem está testando páginas. Serviços seguem outra linha em muitos casos, e será abordado em um futuro post.

Para esse post estou tentando algo novo, com a ideia de tornar o post mais iterativo e a ferramenta mais fácil de aprender (e de quebra de pegar uns exemplos prontos, é claro). Caso queira ter 100% de proveito, baixe o arquivo: JMeterExample.jmx compatível com JMeter 1,9+ (recomendo o 2.11) e o JMeter para acompanhar os exemplos. Caso queira um JMeter com todos os plugins, baixe esse “https://github.com/camiloribeiro/rake-jmeter/tree/master/jmeter

Eu criei um plano de teste de performance onde vamos habilitando cada um dos exemplos e ver eles funcionando. Assim você pode ler o exemplo, entender o conceito e experimentar na ferramenta, apenas habilitando e acompanhando no relatório e nos debugers espalhados pelo plano.

O objetivo dessa série é fomentar material prático, didático e completamente gratuito em português. Ajude-me a entender o que falta (comente, envie suas dúvidas e o seu feedback!), e juntos podemos construir um material que vai ajudar os novos QAs e developers a ter uma curva de aprendizado mais rápida e fácil em JMeter e teste de performance.

JMeter sem mouse

Embora o JMeter exija muito mais atenção e cuidado do que velocidade e produtividade, aprender os comandos de teclado podem (e vão) salvar muito o seu tempo quando estiver debugando. Para demonstrar isso, experimente o seguinte exemplo: Abra o menu File, clique no Save para salvar as novas mudanças. Agora clique no menu Run e clique no Clear All para limpar os relatórios. E agora clique novamente no menu Run e clique em Start. Todos esses cliques podem ser substituídos por Ctrl + SER (Save, Clear e Run).

Outros comandos interessantes: Enable/Disable: Muitas vezes você vai precisar testar o seu script sem um determinado elemento, grupo, condição etc. Para fazer isso de forma rápida, use Ctrl + T, tanto para habilitar, quanto para desabilitar. Stop Testing: Começou o teste sem querer ou já viu a quantidade de erros no listener e desconfia que tem algo errado? Pare o teste com Ctrl + .Duplicate Node: Precisa duplicar um elemento para testar alguma mudança sem perder o que já estava usando? Ctrl+Shift+C. (Atenção: Use git, mesmo que localmente. Já perdi meu jmx por corrupção de dados algumas vezes. Se não fosse o git teria algumas horas de trabalho ;) )

Quer mais shortcuts? -:> https://wiki.apache.org/jmeter/JMeterShortcuts

Aonde colocar os nodes?

Um node é qualquer elemento do JMeter. Como vimos no post “Destilando JMeter I: Introdução e Conceitos“, eles podem ser um thread group, um sampler, um listener, um timer, um config element entre outros. Só para relembrar, o funcionamento do node está diretamente relacionado com aonde ele está aninhado. Se um timer por exemplo, está aninhado em um sampler (é filho de um sampler), ele só vai ser ativado naquele sampler. Lembre-se que apesar disso, como ele executa uma pausa no teste, ele tem efeitos colaterais sobre o teste como um todo.

Criar um plano

Não confunda o plano de testes do JMeter, com algum documento que sua empresa ou cliente precisa ou com o planejamento/estratégia de testes de performance/carga/stress. Aqui vamos falar sobre o plano da ferramenta e como flexibilizá-lo para alcançar alguns dos objetivos de um planejamento. Caso tenha interesse sobre planejamento, pode conferir o nosso post sobre “12 Lições aprendidas em Testes de Performance Server Side” ou lendo algum livro sobre o planejamento. Nesse post vamos trabalhar somente os aspectos técnicos da ferramenta.

-Plano baseado em iterações

O plano em iterações é ideal para dois casos distintos. O primeiro e mais comum, é o caso de quem precisa testar uma quantidade limitada de requisições, não importa o tempo. Para ver esse exemplo funcionando, habilite o plano “Fixed number of requests example” e execute o teste observando o resultado.

Exemplo de plano de teste com número fixo de execuções e threads
Exemplo de plano de teste com número fixo de execuções e threads

O número de requests vai ser o número de iterações definido no campo “Loop” vezes o número de threads. O ramp-up só vai “amortecer” o início dos testes, mas não afeta o resultado final em número de requests. PS: Não se preocupe, estamos usando um “Dummy Sampler”, o que significa que estamos emulando requisições dentro do próprio JMeter.

O segundo modelo é o teste “eterno”. A configuração é a mesma, mas ao invés de informar o número de repetições. só informamos o número de threads e selecionamos a opção “Forever”. Esse teste é pouco falado. Eu uso ele por exemplo, para testar a estratégia de rolling-deployment, Blue-Green deploy e eventualmente loging, mas isso é um tópico a ser discutido em um futuro post :) Caso queira manter um teste de “maturidade” ou soak test por um período bem long, também pode selecionar essa opção. (more…)


IceCream e a fábrica de testes inteligente

Sim! Existe uma forma inteligente de juntar as palavras “Fábrica” e “Teste”. Obviamente, o título é um trocadilho, mas o conceito deste post é bem interessante, principalmente para quem usa webdriver ou outro framework de automação baseado em Ruby.

A bastante tempo tenho usado Factory-Girl como factory para fazer meus testes, mas na maioria das vezes a applicação era baseada em Rails, Sinatra ou algo semelhante, que facilitava o uso dessa rubygem. Mas algumas vezes em que eu estava usando ruby para fazer testes blackbox com Selenium, Watir ou Cello, onde de nenhuma forma o aplicativo interno me interessava, e por isso eu tinha que fazer muitas gambiarras para conseguir usar essa ou outra gem para fabricar objetos de teste. Depois de procurar por bastante tempo por uma solução agnostica de implementação, frameworks e sem dependências, eu resolvi montar a minha própria rubygem, e assim nasceu, em dois dias, o IceCream (https://github.com/camiloribeiro/icecream).

Como as minhas outras gems/projetos, o nome faz uma analogia que reflete o meu péssimo senso de humor. Mas vamos falar sobre isso mais a frente. Primeiro, vamos entender o que é um Factory e como ele pode nos ajudar a testar com menos esforço, menos código, mais reuso e mais flexibilidade.

O conceito

Factory é um padrão de projetos (design pattern) originalmente desenhado para linguagens orientadas a objetos, para gerar, de uma maneira simples e prática, objetos de vários tipos baseados em uma única interface, ou seja, você pode pedir a uma entidade um objeto qualquer que ela conheça, e ela vai te retornar esse objeto e seus atributos. Você ainda pode mudar os atributos desse objeto de acordo com as suas necessidades. Encontre outras definições melhores que essa aqui (wikipedia), aqui (JavaWorld) e aqui (devmedia).

Exemplificando com a analogia do IceCream, vamos imaginar que temos um freezer. Esse freezer contém um estoque infinito de dezenas ou centenas de sabores diferentes de sorvete. Sempre que precisamos de um sabor diferente, podemos ir ao freezer e pedir um novo sorvete. :)

Mas onde isso se aplica nos meus testes?

Formulário simples de cadastro de sorvete
Formulário simples de cadastro de sorvete

Vamos imaginar que estamos testando o cadastro de sorvetes de uma sorveteria. Para isso, vamos usar o formulário a nossa esquerda. Vamos escrever, de uma maneira bem superficial, alguns casos de teste que podemos identificar baseado somente nesse formulário:

  • Cadastrar um sabor com todas as informações;
  • Cadastrar um sabor só com os campos obrigatórios;
  • Cadastrar um Sorvete com cada opção especial “Light”, ”Diet” e “Cheio de Açucar”;
  • Tentar cadastrar um sabor sem cada um dos campos obrigatórios “Sabor do Sorvete”, ”Preço” e ”Coloração”;
  • Cadastrar um Sorvete com cada uma das cores;
  • Um sorvete com preço quebrado (com centavos);
  • Tentar cadastrar um sabor sem o campo obrigatório com letras no preço;
  • Etc.

Todos esses são casos de teste que um testador pensaria na etapa de planejamento dos testes. Cada um vai descrever esses casos de uma maneira, desde os mais tradicionais com artefatos ou documentos para cada caso, até os mais flexiveis como eu, que vai ter um bloco de notas com algumas ideias ou alguns rabiscos em um rascunho velho. (more…)


Destilando JMeter I: Introdução e Conceitos

Leitura recomendada para antes de ler esse post: 12 Lições Aprendidas em Teste de Performance Server Side

Don’t be evil! Use o JMeter para o bem :]

A muito tempo tenho recebido pedidos de pessoas sobre como usar o JMeter e sobre como fazer testes de performance. Apesar de não ser um full time Performance Testing Engineer, como generalista que sou, tenho alguma experiência com performance e por sorte acabei praticando bastante esse tipo de teste usando o JMeter nos últimos dois anos e passei por dor de cabeça o suficiente para escrever um tutorial completo com parte do que eu aprendi.

A boa notícia é que vou lançar alguns posts sobre JMeter no modelo conceitos e tutorial (passo a passo explicativo) totalmente gratuito e não comercial, e vou me esforçar para que esse material seja mais detalhado e didático sobre JMeter na lingua portuguesa. Com sua ajuda com dúvidas, feedback e compartilhamentos eu tenho certeza que isso é possível ;]

Nesse primeiro post vamos cobrir os conceitos básicos sobre os conceitos do teste de performance, defeitos e outras informações básicas que precisamos para começar os testes de performance. Além disso vamos falar um pouco sobre o projeto JMeter, sobre a interface gráfica e vamos preparar o JMeter com os plugins e ferramentas mínimas para executarmos load tests, stress tests e soak tests com profissionalismo. Ainda vamos ter uma visão geral dos relatórios, configurações e parâmetros que podemos usar através da UI do JMeter. (Sim é muita coisa e esse é mais um dos posts gigantes do bugbang.com.br :p)

Exemplo de gráfico de Tempo de Resposta por Tempo do JMeter
Exemplo de gráfico de Tempo de Resposta por Tempo do JMeter [13]

Testes de performance é sobre tempo de resposta?

Quando falamos em testes de performance, sempre vem a cabeça medir o quão rápido é a resposta de uma página, mas testes de performance podem ir muito além disso.

A Microsoft define teste de performance como:

…a investigação técnica feita para determinar ou validar a velocidade, escalabilidade e/ou estabilidade características do produto sob teste. [2]

A wikipedia tem uma definição que eu gosto muito:

…testes executados para determinar como um sistema performa em termos de responsivilidade e escalabilidade sob uma carga particular.

e faz um adendo:

… também investigar, medir, validar ou verificar outros atributos de qualidade do sistema, tais como a escalabilidade, confiabilidade e uso de recursos.[1]

Eu gosto de definir que testes de performance são:

Teste onde submetemos aplicações a cargas e condições específicas por tempo determinado afim de observar e avaliar os diferentes comportamentos que essas condições e cargas vão proporcionar.

Esse comportamento pode ser observado de várias maneiras e o teste de carga pode ter como saída defeitos de performance (timeouts, tempo de resposta abaixo da expectativa,  problemas de I/O, etc.), funcionais (falha no mecanismo de caching, inconsistências matemáticas ou de dados, etc), estruturais (armazenamento, memory leak, corrupção de dados, problemas de rede ou load balancer, etc) e de segurança (exposição de dados, exposição de stack traces, etc). Ou seja, o simples fato de uma aplicação ter um tempo de resposta abaixo de um valor estipulado pelo negócio não significa que essa aplicação tem qualidade quando submetida as condições e cargas dos nossos testes. (more…)


12 Lições aprendidas em Testes de Performance Server Side

Tenho trabalhado com performance nos últimos meses e tive a oportunidade de parear com algumas pessoas muito experientes no assunto, e juntos até desenvolvemos um conjunto de rake tasks para execução automática de testes, o rake-jmeter, que falarei em um futuro post.

Como QA do projeto, eu fiquei encarregado de desenvolver os testes, coletar as informações de aceite, diagnosticar os principais problemas e dependências, gerar relatórios periódicos, acompanhar as melhoras e integrar os testes de performance ao build pipeline. Para isso escolhemos o JMeter, ferramenta open source, simples de usar, conhecida e muito testada na comunidade. Escolhemos ela principalmente por ter uma interface de linhas de comando que ajuda na distribuição dos testes em vários servidores ao mesmo tempo e por ser uma ferramenta com muita credibilidade.

Além do JMeter, outro elemento fundamental para o sucesso dos testes foi o NewRelic, ferramenta de monitoramento de performance em tempo real, que facilitou a visão do comportamento interno e identificação de gargalos e erros, enquanto o JMeter se encarregava de estressar a aplicação e catalogar o comportamento externo.

Abaixo algumas observações e lições aprendias ao longo desses últimos meses no fantástico mundo dos testes de performance:

1 – O tempo médio é só uma promessa

É muito comum ver critérios de aceite de performance baseados exclusivamente em tempo médio de resposta. Já presenciei muitos profissionais em listas de discussão e até materiais de referência para certificações, treinamentos ou ferramentas, citarem que tempos mágicos como quatro ou seis segundos de tempo médio seria o requisito de performance, mas aqui existe uma grande cilada.

O tempo médio de resposta é a soma de todos os tempos de resposta divididos pelo número de transações avaliadas. Por esse motivo ele é facilmente confundido com um número que define o quanto o visitante da página vai esperar quando acessar a página sob a carga experimentada durante os testes. O tempo de médio de resposta deve ser visto sim, mas como um dos fatores de aceite para o desempenho de uma aplicação web, mas nunca como o fator determinante para que essa aplicação entre em produção.

Para exemplificar como o tempo de resposta pode ser usado da forma errada, vamos supor que após executar testes em uma página web, essa página tenha nos retornado nove requests com os seguintes tempos de resposta:

5, 11, 5, 1, 5, 2, 1, 5 e 1.

Pode ser representado pelo seguinte gráfico:

Exemplo de requests com diferentes tempos de resposta ao longo do tempo

 

Nosso product owner disse que os usuários desse tipo de sistema, normalmente abandonam o site ou perdem o foco quando estão acessando a aplicação e ela demora cinco segundos ou mais para responder. Nesse caso, nosso objetivo é que os usuários não aguardem mais do que quatro segundos e meio para ver a página completamente carregada.

Se olharmos o tempo médio das requisições acima vamos ter (5+11+5+5+5+2+1+1+1)/9 = 4 segundos. Podemos então, baseado apenas no tempo médio de resposta, dizer que os nossos testes estimam que os usuários estarão felizes usando essa aplicação, pois o tempo médio é menor que o ponto em que os usuários se frustram. Mas se observarmos de outro ângulo, podemos notar que nos nossos nove registros, apenas quatro estão abaixo do tempo de resposta desejado pelo product owner, logo, por essa outra forma de ver o mesmo requisito, podemos dizer que apenas 44% dos nossos usuários estariam verdadeiramente satisfeitos baseando-se nesse tempo de resposta de quatro segundos e meio.

O tempo médio é um indicador importante, pois ele agrega os tempos de resposta e facilita a identificação de páginas ou APIs mais demoradas, mas ele não é e nunca deve ser visto como o critério definitivo de aceite, pois ele é um número muito maleável e pode facilmente enganar o analista de performance. O ideal é observar inicialmente a variação no tempo de repostas que é representada pelo desvio padrão e a porcentagem de transações abaixo do nosso tempo máximo (leia mais logo a frente). (more…)


Hoje um Leitor, Amanhã um Líder

“Today a reader, tomorrow a leader.” ― Margaret Fuller

Começando na área de testes? Pensando em dar um upgrade nos seus conhecimentos? Estabelecendo as metas de carreira para 2013? Nesse post vou falar um pouco sobre a maneira mais rápida e barata para se aprender de verdade, começar a aplicar coisas novas na sua empresa ou para se preparar para aquela empresa que você tanto queria trabalhar. A leitura!

Imagem Ilustrativa

Eu vejo que muita gente manda e-mails para as listas, especialmente DFTestes, perguntando “por onde devo começar?”. A resposta muitas vezes vem na forma de um material de certificação básica ou a certificação mesmo, o que no meu ponto de vista é um grande erro, por inúmeros motivos, entre eles a falta de atualização do material e a falta de profundidade nos tópicos abordados, entre outros fatores políticos, filosóficos e até pessoais.

Outra razão para esse post, é que eu vejo que poucos profissionais de teste tem o hábito de ler, o que não é verdade em outras comunidades como desenvolvedores, gerentes de projetos e analistas de negócio. Por esses dois grandes motivos, decidi fazer um comparativo entre uma certificação internacional de nível fundamental em teste de software, e um plano de estudo baseado em leitura e prática para o ano de 2013.

O valor da candidatura a certificação em 16 de Janeiro de 2013 é R$350,00 (trezentos e cinquenta reais). Por questões éticas e legais não vou falar qual instituição nem qual a certificação será usada como exemplo, mas adianto que é a certificação presente no Brasil que eu vejo com “melhores olhos”.

O material didático fornecido em português no site da afiliada é composto por um guia de referência contendo aproximadamente 60 páginas de conteúdo. Esse material foi desenvolvido em 1999, traduzido para pt-br em 2007 e desde então possui algumas notas de correções que couberam em uma página e meia, tudo isso descrito no próprio material em um dos anexos.

Nesse material são apresentados mais de 50 tópicos, incluindo os seguintes: (more…)


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]. (more…)


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. (more…)


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. (more…)


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.  (more…)