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…)


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


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


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


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