Lean Inception: concepção de produtos enxutos – Parte 2

No artigo anterior iniciei conceituando o que é a Lean Inception. Falamos um pouco da sua história e tratei de resumir as dinâmicas que envolvem os dois primeiros dias de trabalho de uma inception (ou três, se você considerar o trabalho prévio). Entendemos que o foco da inception é sair com um entendimento comum do que será o produto e quais serão os primeiros passos da sua construção, o seu MVP inicial, bem como o roadmap que se seguirá a partir dele.

Claro, até o término do segundo dia não é possível ter tanta clareza assim uma vez que o melhor ainda está por vir nos dias seguintes. E é desses dias que vou falar nesta segunda e última parte do artigo sobre Lean Inception!

Dia 3: Quarta-Feira

Assim como todos os dias da inception, começa-se com uma energização e em seguida faz-se uma restrospectiva dos dias anteriores, neste caso passando pela Visão do Produto, o que ele É-Não É-Faz-Não Faz, quem são as Personas que usarão o produto e quais as Features que descobrimos para ele.

E é com esse gancho das features que iniciamos o terceiro dia da Inception, fazendo um nivelamento das mesmas, também chamado de Revisão Técnica e de Negócio. Esse nivelamento é feito com todo o grupo em conjunto de uma maneira tão simples quanto levantar a mão com uma nota de 1 a 3 para cada uma das perguntas seguintes:

  • de 1 a 3, qual o nível de entendimento de negócio que temos sobre esta feature?
  • de 1 a 3, qual o nível de entendimento técnico que temos sobre esta feature?

Conforme as respostas são consolidadas para cada feature (incentive o debate quando existirem notas 1 e 3 para a mesma feature, semelhante ao que fazemos em um Planning Poker), coloque-as em uma matriz como abaixo.

Matriz de Entendimento
Matriz de Entendimento

Ou seja, se uma feature recebeu nota 1 para entendimento técnico e 3 para entendimento de negócio, ela vai ficar no canto superior esquerdo. Essa feature deve ser sinalizada com a cor vermelha, geralmente colando o post-it dela sobre um cartão com esta cor.

Note que se a feature ficar posicionada em algum dos quadrantes com um X, ela não será incluída no MVP, pois seu nível de certeza é baixíssimo. Demais features em posições vermelhas devem ser melhor discutidas, features nos quadrantes amarelos estão com nível razoável de certeza e features verdes estão prontas para serem desenvolvidas.

Após essa análise sobre uma feature, fazemos uma segunda análise, também em grupo, respondendo as seguintes perguntas:

  • de 1 a 3, qual o esforço necessário para desenvolver esta feature? Marque o consolidado no canto do cartão da feature usando os símbolos E, EE ou EEE para o esforço.
  • de 1 a 3, qual o retorno financeiro desta feature? Marque o consolidado no canto do cartão da feature usando o símbolos $, $$ e $$$ para a receita.
  • de 1 a 3, o quanto os usuários vão amar esta feature? Marque o consolidado no canto do cartão da feature usando corações (1 a 3).

Na imagem abaixo está um exemplo de feature “estimar preço” nivelada com grau amarelo de certeza, esforço médio e receita alta. Não tem o coração ainda pois essa foi uma adição mais recente do Caroli ao método.

Feature Nivelada
Feature Nivelada

Após fazer isso com todas as features descobertas no dia anterior, teremos um canvas de features (aquele com as Personas x Features, lembra?) com mais detalhes sobre cada uma delas.

Feature Canvas nivelado
Feature Canvas nivelado

Note que as discussões geradas por esse nivelamento produzem muito mais do que apenas cards coloridos e marcações, elas dão uma clareza muito maior do que pretende-se desenvolver para todos os membros do grupo e inclusive você pode incluir mais informações aos cards para uso posterior, oriundas dessas discussões.

Na parte da tarde, sim o dia ainda não acabou, é hora de falarmos de Jornadas dos Usuários. Aqui a dinâmica é mais simples: cada grupo pega uma persona (se sobrar tempo pode fazer para mais de uma) e trabalha em uma jornada dela, onde haja ponto de contato com o produto que será desenvolvido.

Um excelente framework para essa dinâmica é pegar uma folha A2 para cada jornada e traçar uma matriz com as colunas sendo: antes, durante e depois e com as linhas sendo: ação, ponto de contato, pensamento e humor. Na coluna Antes você vai colocar as ações, em ordem cronológica, que vão levar o usuário a ter contato com seu produto, ele se deparando com o problema ou necessidade o qual o levará até o produto. Vale qualquer coisa, até falar do café da manhã dele. Para cada ação, não esqueça de citar os pontos de contato com o produto, o que o usuário está pensando naquele momento e como está o humor dele.

Na coluna Durante, descreva as ações do usuário já usando o produto, não esquecendo dos pensamentos e sentimentos também. Já na coluna Depois, descreva as ações pós-uso do produto, do usuário aproveitando o benefício obtido, por exemplo.

Caso mais de algum grupo faça a mesma jornada, é importante que haja uma consolidação através do consenso entre eles. Podem existir várias jornadas por persona, mas que não descrevam a mesma situação de uso do produto. Ao término do dia, todos apresentam suas jornadas, registra-se tudo e enviam-se os materiais gerados por email.

Dia 4: Quinta-Feira

No quarto dia, após a energização e recapitulação dos dias anteriores, é hora de mapear as features às jornadas do usuário. Lembra que lá atrás mencionei que era uma boa colocar identificadores únicos nas features? Pois é, aqui isso vai ser bem útil.

Mudam-se os grupos para que cada grupo fique com uma jornada que não foi criada pelo próprio grupo. Para cada ação do usuário (principalmente na etapa Durante), verifica-se quais features seriam utilizadas naquela ação, anotando o código da feature em um post it e colando próximo ou sobre a ação.

Caso note-se que tem alguma feature faltando, já cria-se ela e faz-se o nivelamento da feature individualmente que nem foi feito no dia anterior, colocando-a à disposição dos demais grupos no canvas de features.

Caso note-se que alguma feature ficou sobrando, talvez seja o caso de despriorizá-la, pois nas principais jornadas do usuário ela não se mostrou presente.

Após todos os times terminarem de mapear o uso das features nas suas jornadas, apresenta-se o resultado para o grande grupo.

Na parte da tarde do mesmo dia é hora de fazermos o Sequenciador de Features. Considerando tudo que foi aprendido e co-criado até aqui, vamos usar o Sequenciador de Features para definir o escopo do nosso MVP e o que sobrar ficará para as releases seguintes, em um roadmap incremental de produto.

Você cria a dinâmica do sequenciador com um único cartaz dividido em linhas horizontais (com altura suficiente para um card de feature e largura para três), numeradas à esquerda, como mostra a imagem abaixo.

Sequenciador de Features
Sequenciador de Features

Os times vão debater e decidir quais features devem ser implementadas primeiro (i.e. serem colocadas primeiro no sequenciador) considerando as jornadas mais importantes, precedência de features, etc. O preenchimento do Sequenciador é um trabalho do grupo inteiro. No entanto, existem algumas regras que devem ser seguidas, criadas pelo Caroli após várias inceptions na prática:

  1. Cada linha pode conter no máximo 3 features;
  2. Cada linha não pode conter mais do que 1 feature vermelha;
  3. Cada linha deve conter uma feature verde;
  4. A soma do esforço das features de uma linha não pode ser superior a 5 Es;
  5. A soma da receita das features de uma linha não pode ser menor que 4 $s;

Cada regra tem uma razão de existir e é recomendado que sejam seguidas à risca para garantir releases que balanceiem a entrega de valor x o risco. Considerando a ordem de cima para baixo e da esquerda para direita, em algum momento você conseguirá definir o escopo do primeiro MVP e dos MVPs seguintes.

Caso nunca tenha feito uma estimativa de alto nível antes, você pode pegar uma das features cujo nível de entendimento de negócio e técnico seja muito alto e tentar estimar em quanto tempo ela seria desenvolvida (usando T-Shirt Sizing, por exemplo) usando o time que você possui hoje. Com base nela você consegue estimar as demais por comparação e sinalizar no Sequenciador onde terminam cada um dos MVPs, montando o roadmap incremental do produto.

Dia 5: Sexta-Feira

No último dia da inception enxuta, é hora de consolidar tudo o que foi aprendido ao longo da semana em um MVP Canvas (técnica mais recente do que a mostrada no livro Direto ao Ponto original), cujo template você encontra abaixo. Claro, não esqueça de enviar a todos por email os resultados do dia anterior, fazer uma energização no início do dia e uma recapitulação das dinâmicas anteriores.

MVP Canvas
MVP Canvas

Um único MVP Canvas será criado para cada release do roadmap criado a partir do Sequenciador de Features, de maneira colaborativa entre todo o grupo. Mas nem só de consolidação é formado o canvas, pois algumas áreas exigirão que o grupo raciocine sobre o construído, de forma a torná-lo “user centered” e que seja possível medir o seu sucesso para pivotar ou não, uma vez que dependendo do aprendizado obtido a partir da construção deste MVP, todo o restante do roadmap pode ser alterado (não caia na armadilha de seguir um roadmap de  MVPs à risca e às cegas). É só seguir a cartilha do Lean Startup, não tem erro!

Resumidamente, você preenche o MVP Canvas da seguinte forma:

  • MVP Vision: baseado na Product Vision criada no primeiro dia da inception, derive para uma visão específica desta release;
  • Outcome Statement: qual o foco de aprendizado deste MVP? O que estaremos validando com esta entrega? O que esperamos alcançar?
  • Metrics: como iremos medir o progresso/sucesso deste MVP? Que índice indicará sucesso ou falha?
  • Personas & Platforms: para quais personas este MVP será lançado? E para quais plataformas? Restrinja a uma ou duas personas/plataformas em cada resposta.
  • Journeys: quais jornadas das personas escolhidas serão atendidas por este MVP?
  • Features: quais features do Sequenciador entrarão neste MVP?
  • Cost & Schedule: qual o custo e prazo desta entrega?

Após a construção do MVP Canvas, na parte da tarde é feito o showcase para todos os stakeholders do projeto, além do próprio grupo que trabalhou duro para chegar neste resultado, não é mesmo?!

E depois?

Com o MVP Canvas em mãos e todo mundo alinhado com o que deve ser feito no primeiro MVP, é hora de colocar a mão na massa rodando o bom e velho Scrum: o Product Owner terá de incluir as features dos canvas no seu Product Backlog, refinando-as em User Stories os que devam entrar no primeiro MVP, para que na primeira Sprint Planning o Time de Desenvolvimento consiga quebrá-las em tarefas, estimá-las em pontos e iniciar o desenvolvimento do produto de fato.

Para se aprofundar no assunto, leia o livro do Caroli, abaixo. Para mais conteúdo sobre Métodos Ágeis de desenvolvimento de software, recomendo o meu livro Scrum e Métodos Ágeis: Um Guia Prático.

Lean Inception: concepção de produtos enxutos

A Lean Inception é uma técnica de concepção de produtos enxutos criada por Paulo Caroli, consultor da ThoughtWorks. É um método bem popular entre os agilistas brasileiros e é fortemente documentada nos livros Direto ao Ponto e Lean Inception (mais moderno, mas apenas em Inglês), do mesmo autor.

Caroli conta em suas palestras e livros que até então as inceptions (reuniões para concepção de um novo produto) duravam mais de um mês na TW e como Caroli atuava como consultor, não raro ele tinha de passar várias semanas por mês fora de casa, fazendo inceptions em clientes. No entanto, quando seu filho nasceu, ele decidiu que não mais ficaria tanto tempo longe da sua família e construiu uma técnica que, em apenas uma semana, é possível definir tudo que é necessário para se conseguir de fato tangibilizar um produto para que tenhamos insumos suficientes para o time de desenvolver começar a trabalhar.

Lean Inception, Sprint 0, Pré-Jogo…

A Lean Inception ocorre logo no início do projeto, no período que antecede a primeira sprint do time de desenvolvimento, período popularmente chamado de Sprint 0 ou Pré-Jogo. Embora o Scrum não aceite a existência de uma Sprint 0, é comum que isto aconteça de fato logo no início de grandes projetos onde a incerteza é tão grande que não vale a pena iniciar o desenvolvimento às cegas.

A ideia central da Lean Inception é fornecer momentos únicos de interação entre os membros do time e os stakeholders para definição dos conceitos elementares do produto, suas funcionalidades, jornadas do usuário, escopo das entregas, roadmap, etc. Tudo em uma semana muito intensa onde a cada dia novas atividades são realizadas e documentadas.

A ideia deste artigo é dar uma resumida no processo completo, cabendo aos interessados em aplicar esta dinâmica na prática buscar os livros do Caroli ou os treinamentos dele e dos treinadores certificados, como a Mayra Souza. O resumo do treinamento que fiz com esta última pode ser visualizado no vídeo abaixo.

Dia 0: Antes de Começar

O trabalho da Lean Inception começa antes do primeiro dia de dinâmicas. Você terá de montar um grupo heterogêneo de profissionais que possam colaborar com a definição do MVP do produto (objetivo final da inception) ou que estejam diretamente interessadas na construção do mesmo (usuários-chave ou stakeholders, por exemplo). Converse individualmente com cada uma destas pessoas e faça o convite pessoalmente, explicando a importância do comparecimento em todos os dias, como que funciona o processo, etc.

Monte uma lista de emails contendo o contato de todos os membros do grupo e dias antes da inception já comece a lembrá-los de que ela vai começar em breve. Certifique-se que seu grupo tenha até 30 pessoas e que tenha facilitadores suficientes para dar conta desta galera toda, em média 1 facilitador para cada 10 pessoas. Os facilitadores não executam as atividades, apenas conduzem, sem influenciar. Também garanta que todos os perfis abaixo estejam presentes neste grupo:

  • Product Owner do produto;
  • Scrum Master do time (geralmente um dos facilitadores);
  • profissionais técnicos do time (programador, analista, etc);
  • profissionais criativos de UX, UI, marketing, etc;
  • profissionais das áreas de negócio da empresa;
  • profissionais das áreas de atendimento da empresa;
  • usuários-chave do sistema;

Dia 1: Segunda-feira

Como a inception dura a semana inteira, o ideal é que ela comece em uma segunda-feira, para que não aconteça quebra de raciocínio. Mande um email reforçando o início da inception para todos os convidados e tenha um ambiente minimamente dedicado para que a dinâmica aconteça todos os dias no mesmo local e com os mesmos materiais, para que nada se perca entre cada um dos dias.

No primeiro dia as regras da inception são explicadas e em alto nível o que é a ideia do produto (geralmente o Product Owner dará este briefing). Geralmente pede-se que todos os membros do grupo se apresentem, expressem suas expectativas e faz-se uma dinâmica de energização para quebrar o gelo e animar o pessoal. Paulo Pontual, Zip-Zap-Zum, entre outras são sugeridas.

São formados grupos de trabalho, geralmente de 2 a 5 e na parte da manhã a primeira atividade é escrever a Visão do Produto. Cada time escreve a sua visão usando o template abaixo:

Para [cliente final],

cujo [problema que precisa ser resolvido],

o [nome do produto]

é um [categoria do produto]

que [benefícios-chave, razões para comprá-lo].

Diferente do [alternativa de mercado],

nosso produto [diferença-chave].

Depois, cada grupo apresenta a sua versão da visão do produto e ao término das apresentações, consolida-se em apenas uma só, gerando debates para que esta consolidação gere o melhor resultado. Documente a Visão do Produto com fotografias, isso será útil mais tarde, e preferencialmente transcreva-a para um cartaz que deverá estar fixo na sala da dinâmica a semana inteira.

Product Vision
Product Vision

Na parte da tarde (que tal uma energização após o almoço?) faz-se a dinâmica de definição do produto, também chamada de É-Não É, Faz Não-Faz. Aqui a ideia é que cada grupo trabalhe em um cartaz dividido em 4 quadrantes: É, Não É, Faz, Não Faz.

É-Não É-Faz-Não Faz
É-Não É-Faz-Não Faz

Em cada quadrante os membros do grupo discutem o que o produto é, o que ele não é, o que ele vai fazer e o que ele não vai fazer. Depois que cada grupo cria as suas definições individualmente, novamente cada grupo apresenta e o resultado final é consolidado em apenas uma versão após várias rodadas de discussão envolvendo cada quadrante.

As evidências destas duas dinâmicas são enviadas a todo o grupo no final do dia, bem como quaisquer outras fotos tiradas e uma descrição rápida de como o dia passou. Caso não seja possível deixar os cartazes consolidados nas paredes da sala, o facilitador deve guardar os mesmos para que seja possível manter o histórico da dinâmica completa.

Dia 2: Terça-feira

Começa-se o segundo dia reforçando o compromissos com todos via email, antes mesmo da dinâmica começar. Quando a dinâmica começa de fato, após a energização/quebra-gelo (sim, sempre faz-se uma no início do dia) inicia-se uma recapitulação do dia anterior, mostrando o produto final das dinâmicas de Visão do Produto e da É-Não é-Faz-Não Faz, para que todos estejam na mesma página novamente.

Uma vez que temos em alto nível os conceitos mais fundamentais do produto, é hora de falarmos de quem vai usá-lo/comprá-lo: as personas. As personas são arquétipos de usuários-chave típicos do produto. Cada produto possui no mínimo uma persona, enquanto que alguns podem possuir várias.

Cada grupo de trabalho pega uma persona para trabalhar, preenchendo um cartaz com os quatro quadrantes sobre a persona que escolheram:

  • nome e retrato: qual o nome ou apelido deste usuário-chave do produto? como ele se parece, se veste, etc?
  • perfil: idade, nacionalidade, etnia, renda, formação, profissão, etc
  • comportamentos: hobbies, crenças limitantes, crenças fortalecedoras, etc
  • necessidades: o que ele está buscando? Quais as suas dificuldades? As suas “coceiras”? As suas aspirações?
personas
personas

Uma vez que um produto pode ter várias personas, pode ser que cada grupo fique com uma diferente, não havendo necessidade de consolidação. Caso alguma persona se repita, deve-se consolidar os resultados obtidos para a mesma persona. De qualquer forma, cada grupo apresenta aos demais os resultados obtidos.

No mesmo dia, na parte da tarde, é hora de fazer a Descoberta das Features. Uma feature ou funcionalidade é a descrição de uma interação do usuário com o produto ou alguma ação que o sistema é capaz de realizar. As descrições das features devem ser simples e sem entrar em detalhes técnicos.

Para fazer esta descoberta de features existem diversas dinâmicas possíveis, desde simples brainstormings até entrevistas com usuários-chave. A técnica sugerida pela Lean Inception é fazer uma matriz onde cada coluna é algo que o sistema faz (lembra do Faz-Não Faz?) e cada linha é uma persona. O cruzamento das personas com o que o produto faz deve induzir às features necessárias.

Personas x Features
Personas x Features

Note que esta matriz é para ajudar o raciocínio para a descoberta de features, não para limitar a criatividade das pessoas nem para obrigar a fazer todas as combinações de coisas que o produto faz com as personas existentes. No entanto, é sempre interessante descartar features neste momento que de fato não auxiliem na resolução de nenhuma necessidade das personas, direta ou indiretamente.

Ao final do dia, tiram-se fotos dos cartazes das personas e do resultado da descoberta de features. É interessante também adicionar uma numeração nas features para facilitar a organização posterior. Envia-se um email a todos envolvidos com as evidências da dinâmica.

Este artigo ia ficar muito grande, resolvi quebrar em duas partes, sendo que a segunda parte está neste link. Para se aprofundar no assunto, leia o livro do Caroli, abaixo. Para mais conteúdo sobre Métodos Ágeis de desenvolvimento de software, recomendo o meu livro Scrum e Métodos Ágeis: Um Guia Prático.

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!