Agile Testing: Dicas para testes de software em times ágeis

Então a empresa decide adotar métodos ágeis top-down. Show, geralmente o alto escalão é quem boicota esse tipo de iniciativa. Começar com seu apoio já é meio caminho andado. A outra metade do caminho? Convencer o restante da empresa a fazer o movimento bottom-up da transformação ágil.

Embora para algumas pessoas isso possa soar muito fácil, não é tão fácil quanto parece, principalmente quando colocamos dois elementos-chave na equação de qualquer transformação ágil: sustentação e testes. Pretendo falar de sustentação em outro artigo, hoje vou me focar na questão de $1M que é: como testar de maneira ágil?

O papel do testador em um Time Ágil (QA)

O primeiro ponto a ser definido, antes de falar de práticas é do papel do testador. Primeiro que em Times Scrum (e 90% dos times usam Scrum ou ao menos ScrumBut) não existe o papel do analista de testes. Todo mundo que não é PO nem Scrum Master é um Desenvolvedor. Um analista de testes é alguém que colabora no desenvolvimento do produto, logo, é co-responsável por todo o ciclo de desenvolvimento do mesmo, não apenas os testes.

Uma vez que, ao contrário do modelo Waterfall, não teremos uma fase de testes ao final do projeto, cabe ao profissional de testes participar ativamente de todo o processo, desde o planejamento (quer alguém melhor do que um QA para ajudar com Critérios de Aceite?), ao desenvolvimento (seja Pair Programming ou mesmo desenvolvendo testes automatizados) e finalmente os testes propriamente ditos, que, ao invés de serem realizados todos no final do projeto (ou mesmo no final da iteração) devem ser realizados conforme os itens do Sprint Backlog venham sendo entregues pelos desenvolvedores.

Ufa! Sim, um QA Ágil tem muito mais trabalho que um QA tradicional, tendo de acompanhar o restante do time durante o dia a dia do projeto, ajudando-os, ao invés de focar-se em encontrar o maior número possível de bugs no final do projeto.

Não obstante, vale lembrar que qualidade não é responsabilidade exclusiva do QA, mas sim de todo o time, e cabe à ele também ressaltar e criar uma cultura de qualidade dentro do time constantemente, como se fosse um Scrum Master da qualidade ou QA Master. 😀

Teste Ágil x Tradicional
Teste Ágil x Tradicional

Teste Tradicional x Ágil

Essa mudança de mindset do profissional de qualidade é vital para que ele consiga entrar no modelo ágil do time. Isso porque, não raro, times de desenvolvedores adotam métodos ágeis mas não agilizam os testes, geralmente delegando esta atividade para um time de QA, que muitas vezes fica em outro setor.

Neste cenário bi-modal, geralmente o time de QA vai se focar em construir pesadas documentações com casos de teste e registros dos testes realizados, além de exigir do time de desenvolvimento as demais documentações do projeto, como casos de uso (às vezes aceitam histórias de usário). O que acontece é que dessa forma gasta-se um tempo e esforço enormes produzindo documentação quando poderíamos aproximar profissionais de QA dentro dos Times Scrum e colocá-los a trabalhar com o time, e não para o time.

Essa burocracia, aliada a uma cultura de “última linha de defesa da qualidade do software” gera um histórico enorme de conflitos entre devs e QAs que é totalmente desnecessário. No momento que algumas empresas separam a responsabilidade da qualidade entre times diferentes, um inadvertidamente culpa o outro por todo o tipo de problema encontrado no processo de desenvolvimento. Frases como:

  • Os devs me largam software de qualquer jeito pra testar!
  • Os QAs estão atrasando a entrega do projeto!
  • Sou o maior, achei 30 bugs na última release do software, esses devs são uns incompetentes!
  • Eu não vou testar o software que desenvolvi, os QAs são pagos pra isso!

Entre outras pérolas.

O fato é que não há como ter um time ágil se o processo de QA não é ágil. A sprint não pode ser considerada bem sucedida se não temos todos itens do sprint backlog como DONE. E francamente, eles não podem estar definidos como DONE se não tiverem sido testados ainda.

O mindset do QA Ágil

Ao invés de se posicionarem como a última linha de defesa, os testadores de um time ágil devem se colocar como os evangelistas da qualidade dentro do time:

  • ajudando o PO a escrever Critérios de Aceite para suas User Stories;
  • realizando ATDD, BDD e/ou Specification by Example;
  • ajudando os devs a escreverem testes unitários automatizados;
  • desenvolvendo testes funcionais automatizados;
  • ajudando o Scrum Master com as métricas de qualidade do time;
  • e, em último caso, realizando testes funcionais tradicionais.

Ou seja, o trabalho do QA não pode estar limitado a escrever documentos de teste no início da sprint e testar o software no final (isso sempre dá errado), mas sim desenvolver especificações e testes no início da sprint e iniciar os testes de software conforme os itens de backlog forem sendo entregues.

Só desta forma é que é possível garantir qualidade e agilidade ao mesmo tempo. Para resultados excepcionais, os profissionais do time devem estar dispostos a uma dedicação excepcional.

Automação de Testes

Você deve ter percebido que, em vários momentos, eu falei de automação de testes (ou alguma de suas práticas). Isso porque simplesmente não tem como falar de teste ágil de software sem falar de automação de teste.

Imagine o seguinte cenário: um desenvolvedor termina de codar a US001, ele entrega para o QA testar e o QA testa a US001. Outro desenvolvedor termina de codar a US002 e entrega para o QA. Como ela possui dependência com a US001, o QA testa a US002 e a US001 para garantir que tudo continua funcionando. O primeiro desenvolvedor termina uma US003 que causou mudanças em trechos de código que impactam outra user stories do sistema, mas sem clareza de quais são, logo, o QA faz uma regressão, testando US001, US002 e US003.

E quando o sistema atingir a marca da US100? Ou da US1000? Quantos QAs você vai precisar no seu time para atender à demanda de testes necessária?

Automatizar testes é a única maneira de garantir uma cobertura de qualidade no seu software. Não é uma questão de ser ágil ou não, mas uma questão de ser honesto quando você diz que seu sistema está 100% testado ou não.

Escrever testes unitários é o primeiro passo e deve ser regra dentro do seu time de desenvolvimento independente de usarem TDD ou não. Mas são nos testes funcionais automatizados que está a beleza de frameworks como ATDD, BDD e Specification by Example. Profissionais de qualidade modernos e realmente ágeis não escrevem documentação de teste para depois passarem horas fazendo testes manuais. Eles escrevem requisitos junto ao profissional de negócio de maneira que a especificação é o próprio teste funcional automatizado, ao mesmo tempo que garantem que os devs vão lhe entregar incrementos pequenos e facilmente testáveis, além do que eles já devem ter passado por uma bateria de unit tests.

Se você é um profissional de testes e quer continuar com demanda no mercado, principalmente nas empresas mais top de tecnologia, você tem de aprender automação de testes. Fazer teste funcional hoje, é o mesmo que querer programar perfurando cartões: lento, ineficiente e não escala bem.

Referências

Vou ser sincero com você: meu livro de Scrum e Métodos Ágeis (no final deste post) não fala de teste ágil de software. Mas as leituras abaixo falam muito bem:

Tem outros livros ou dicas para compartilhar? Deixe nos comentários!

Quer saber mais de Scrum e Métodos Ágeis? Conheça o meu livro sobre o assunto!

Leituras recomendadas para Product Owners

Atualizado em 05/07/18!

Desde a criação do Agile Manifesto em 2001 e a consequente popularização dos métodos ágeis no início deste século que eu tenho como o maior ganho promovido pelo modelo a aproximação da área de negócio das empresas com  área de TI das mesmas. Essa aproximação se dá em grande parte à obrigatoriedade do papel do Product Owner dentro dos Times Scrum, sendo esse o framework ágil mais difundido no mundo.

No entanto, para que essa conexão produza bons frutos é necessário que o papel do Product Owner seja respeitado e que o mesmo possua as skills necessárias para tanto. Mas que skills seriam essas?

Um Product Owner geralmente é um especialista na sua área de negócio, mas não necessariamente um especialista em métodos ágeis. No entanto, diferente de um Scrum Master ou de um Agile Coach que devem respirar métodos ágeis no seu dia-a-dia, um Product Owner deve respirar concepção e desenvolvimento de produtos de maneira ágil, tema central das leituras que recomendarei neste artigo.

Clique nos títulos ou nas capas para ver o livro na Amazon.

A Startup Enxuta

Obra máxima de Eric Ries, A Startup Enxuta (Lean Startup no original) já foi motivo de resenha aqui no blog e dispensa apresentações. Conceitos como MVP (Minium Viable Product), Contabilidade para Inovação e o ciclo Build-Measure-Learn são obrigatórios no repertório de qualquer Product Owner.

Business Model Generation

Este fantástico livro de Alex Osterwalder (até a edição é excelente, já fiz resenha aqui no blog) introduz o famoso Business Model Canvas, estrutura o raciocínio sobre a ideação de modelos de negócio inovadores e nos traz diversos cases de modelo disruptivos que empresas famosas descobriram para se reinventar.

Value Proposition Design

Outra obra-prima de Alex Osterwalder, desta vez ele nos introduz ao Value Proposition Canvas, uma poderosa ferramenta que auxilia os Product Owners a fazer a conexão certa entre o que os clientes desejam e o que o seu produto realmente deve ser.

Sprint

Ao contrário do que o nome sugere, este não é um livro de Scrum, mas sim um livro sobre o método usado no Google para testar e aplicar novas ideias em apenas cinco dias. É muito interessante de ler e aplicar, tendo sido escrito por Jake Knapp em parceria com membros do Google Ventures.

Reinvente sua Empresa

ReWork no original de Jason Fried, este livro é a versão parruda e mais moderna do recomendadíssimo Caindo na Real, escrito pelos fundadores do Basecamp. Não apenas promove uma mudança cultural na cabeça de quem lê, ele dá aos Product Owners um passo-a-passo de como orientar a criação de aplicações ágeis e que realmente atendem as necessidades dos clientes com menos pessoas e menos software.

Direto ao Ponto

Paulo Caroli é um engenheiro de software e autor brasileiro que ficou famoso no mundo inteiro com a sua Lean Inception, um método de concepção de novos produtos muito alinhado aos conceitos do Lean Startup, permitindo que através dos métodos descritos em seu livro, empresas consigam definir os escopos de seus novos produtos em até uma semana de trabalho.

Scrum

O mais famoso livro sobre Scrum do mercado (ele aparece na minha lista de 6 livros recomendados para aprender agilidade), o “livro amarelo do Scrum” foi escrito por Jeff Sutherland, um dos criadores do Scrum e uma das figuras mais famosas em agilidade no mundo inteiro. Não é exatamente um livro que te ensina como dominar o framework, mas que te dá a base histórica e teórica do framework, seus princípios e como eles são aplicados em diversos contextos através de todo tipo de case. Essencialmente um livro sobre cultura ágil.

Running Lean

Infelizmente para quem não domina o idioma Inglês, nem todas as grandes obras possuem edição nacional e essa é uma delas. O excelente Running Lean do Ash Mauriya traz conceitos de outros livros como o Business Model Generation e o Lean Startup para outro nível, mais focado em produtos digitais e na realidade que os permeiam. Se eu pudesse resumir esse livro em uma frase seria: saia do escritório e vá falar com seus clientes.

The Four Steps to the Epiphany

Outra excelente obra sem tradução, esse livro de Steve Blank (um dos maiores investidores e mentores do Vale do Silício) é o avô do movimento Lean Startup, tendo sido Blank o professor do Eric Ries (autor do Lean Startup). Neste livro ele introduz conceitos como Customer Discovery e Customer Development, trazendo à tona questões como a busca pelo Product-Market Fit e tantos outros conceitos importantíssimos para todos profissionais responsáveis pela criação de produtos no século atual.

Agile Product Management with Scrum

Esta é uma obra-prima do guru dos Product Owners, Roman Pichler. É um livro que já foi traduzido pro Português mas que é bem difícil de achar a versão nacional, sendo bem mais fácil comprar o ebook na Amazon, embora um tanto salgado. Mas felizmente vale a pena cada centavo se você está investindo na carreira de PO. Roman fala do MMP (Minimum Marketable Product), fala de grooming, de planejamento de releases e ajuda de uma vez por todas a entender este importante papel dentro de times ágeis.

Esqueci algum livro que você gostaria de adicionar na lista? Me mande nos comentários!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Como se tornar um Agile Coach?

Nesse mês de maio completo 6 meses na minha nova função como Agile Coach no banco Agibank. Relembrando agora minha trajetória com métodos ágeis desde 2010, talvez eu nunca tenha sido apenas um Scrum Master, uma vez que sempre estive atento a outras práticas e frameworks, adotando o que melhor se adequava à cada necessidade das empresas em que trabalhei (e fundei) desde então. E afinal, essa é a essência de um Agile Coach!

Neste post tento trazer uma luz a um tópico que tanto me deixava receoso no final do ano passado: afinal, o que é preciso para se tornar um Agile Coach de sucesso ou ao menos como se tornar um Agile Coach de verdade? Além das skills básicas de Scrum Master, tal qual as descritas no Scrum Guide, o que mais eu precisaria?

Segundo o Agile Coaching Institute, 8 são as competências necessárias que todo Agile Coach deve possuir para que possa desempenhar a sua função com maestria, e é nessas 8 competências que estruturei o artigo de hoje, explicando o que é cada uma delas e citando referências bibliográficas onde você pode se aprofundar.

Framework de Competências do Agile Coach
Framework de Competências do Agile Coach

Em uma tradução/adaptação livre, temos as seguintes competências:

Cultura Ágil e Lean

Independente do framework ágil de sua preferência, um Agile Coach deve ter um mindset ágil, um foco nas raízes do Lean da Toyota (berço de boa parte das práticas ágeis) e uma cultura de agilidade tal qual descrita no Agile Manifesto. Essa base lhe propiciará um discernimento do que é ser ágil não apenas a nível de prática, mas a nível de princípios e entendimento realmente profundo.

Algumas referências de estudo nessa linha incluem (com links para a Amazon):

Desenvolvimento de Software com Scrum: Aplicando Métodos Ágeis com Sucesso, de Mike Cohn, cujo título original em Inglês faz mais sentido: Succeeding with Agile.

Coaching Profissional

Como o próprio nome da função sugere, o Agile Coach é em essência um treinador e deve ter habilidade para atuar como tal, com um grande foco em orientar os times e os indivíduos a alcançarem a máxima performance, explorando todo o seu potencial. O interesse do seu cliente é o seu norteador e, baseado nele, o Agile Coach deve ser capaz de aplicar as técnicas e métodos mais adequados a cada situação independente da sua opinião ou até mesmo da sua expertise, indo muitas vezes além do técnico dos métodos ágeis e partindo para uma transformação de mindset dos envolvidos (Programação Neuro-Linguística ajuda muito aqui).

Para desenvolver tais habilidades, além de muita empatia e prática, existem cursos específicos para se tornar um coach (como os oferecidos pelo IBC) e algumas leituras recomendadas, tais como o Poder sem Limites do Tony Robbins, o meu autor de PNL favorito.

Facilitação

O Agile Coach guarda nas suas raízes como Scrum Master o perfil de facilitador: um indivíduo neutro, guardião de técnicas, que guia a organização rumo à descoberta de seus processos e ao sucesso de seus projetos.

O fantástico Game Storming de Dave Gray (que aliás é imenso e eu tenho na minha estante) é um prato cheio de jogos para inovar, mudar o rumo de reuniões e ajudar as pessoas a irem muito além de brainstormings já “amarelados”.

Mentoria

Mentoria é a capacidade de transmitir a experiência, o conhecimento e a orientação de uma pessoa para ajudar no crescimento de outra pessoa nos mesmos domínios de conhecimento ou semelhantes. Resumindo: a capacidade de formar outros Agile Coaches dentro da organização.

Obviamente que você só vai querer fazer isso após ter o mínimo de confiança de que você mesmo é um Agile Coach, mas uma maneira de ir se aperfeiçoando enquanto mentor é se focando em leituras sobre liderança, como o excelente O Monge e o Executivo, e sobre trabalho em equipe como As 17 Incontestáveis Leis do Trabalho em Equipe. Ambos livros te darão um norte de como líderes empoderam times vencedores.

Ensino

Um bom professor é aquele que possui a capacidade de oferecer o conhecimento certo, no momento certo, ensinado da maneira correta, para que indivíduos, equipes e organizações metabolizem o conhecimento para o seu melhor benefício.

Diferente da mentoria, que possui um foco em passar a sua experiência para que outro indivíduo assuma posição semelhante à sua, o ensino foca na passagem de conhecimentos específicos, dadas as circunstâncias de um indivíduo, usando ferramental apropriado.

O clássico Coaching Agile Teams (somente em Inglês), da Lyssa Adkins, que é a “bíblia” do Agile Coaching, tem muitas lições acerca de como ser um bom professor de métodos ágeis, além de um mentor e coach.

Maestria Técnica

Essa competência resume-se a saber “botar a mão na massa” quando necessário, ou seja, não ser apenas um profissional teórico, mas saber como a coisa funciona na prática, a ponto de você conseguir executar ou propor atividades técnicas pontuais no dia-a-dia.

Um Agile Coach sem conhecimento técnico (mesmo que superficial) vai depender e muito de membros técnicos de confiança nos times em que atua para conseguir bons resultados, uma vez que muitas transformações em processos exigem mudanças técnicas nos times como testes, arquitetura, CI, CD, refactoring, código-limpo e muito mais.

É obrigatório o Agile Coach entender o que é Continuous Delivery e ajudar o time a enxergar neste conceito a agilidade técnica de que tanto precisam. Neste ponto, o excelente Entrega Contínua de Jez Humble cumpre bem o seu papel como um guia no assunto.

Já o compilado eXtreme Programming do Daniel Wildt e cia. lhe dará um overview de técnicas e práticas do XP para complementar as lacunas deixadas por uma formação pautada apenas com Scrum (como a minha).

Maestria de Negócios

Além de skills técnicas, cabe ao Agile Coach ter skills de negócio também, principalmente aquelas vinculadas a concepção de novos produtos, validação de hipóteses, personas e muito mais, uma vez que não tem como ser ágil se as áreas de negócio da empresa não são.

Um Agile Coach sem conhecimento de negócio (mesmo que superficial) dependerá de Product Owners extremamente experientes dentro dos times, uma vez que não conseguirá auxiliá-los em etapas extremamente difíceis da jornada de cada time como descoberta de novos negócios, priorizações difíceis, etc.

Leituras neste sentido não faltam, mas seguem duas referências:

Capacidade de Transformar

Um Agile Coach é um agente de mudança e, como tal, deve ser capaz de provocar mudanças culturais e organizacionais dentro da empresa em que atua. Muitas vezes ele deve liderar esta transformação, evangelizando a cultura ágil em todas as esferas da empresa para garantir que a mesma não seja um movimento isolado e que morra com o passar do tempo.

O livro Os 5 Desafios das Equipes (Dysfunctions no original de Patrick Lencioni) trata muito deste assunto, bem como o Virando a Própria Mesa do brasileiro Ricardo Semler, um ícone de transformação organizacional e cultural moderno. Outros títulos famosos, estes que eu não conheço ainda, são Emergência: A Dinâmica de Rede das Formigas, Cérebros, Cidades e Software, de Steven Johnson e o Inteligência Emocional de Daniel Goleman.

E aí, o que achou deste framework de competências? Concorda ou discorda? Use a área de comentários abaixo para discutirmos nossas percepções sobre esse importante papel nas empresas ágeis.

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.