Agile Testing: Cultura de Qualidade em times ágeis

Há algum tempo atrás eu estava fazendo um trabalho com os profissionais de QA lá do Agibank e escrevi o artigo Agile Testing com dicas para mudança de mindset e ressignificação do papel dos QAs nos times Scrum.

De lá para cá muita coisa mudou em nossos times e faz-se ainda mais necessário a ressignificação não apenas do papel do profissional de qualidade dentro dos times como o próprio assunto qualidade. Afinal, não existe entrega de valor em times ágeis se não existir qualidade nas mesmas. Pior do que uma não entrega é a frustração de uma entrega desastrosa.

No artigo de hoje pretendo explorar os tópicos que compreendem o assunto Cultura de Qualidade, tendo como foco o Testing Manifesto da Growing Agile, que eu conheci no Agile Trends 2018.

Qualidade fica no final, certo?…

Todos conhecemos o modelo waterfall de desenvolvimento de software, até porque ele é bem intuitivo: analisamos uma demanda, desenvolvemos ela e antes de entregar, fazemos uma ostensiva etapa de testes, certo?

Além de definir esta etapa de testes mais ao final do projeto, o modelo tradicional defende a existência de um papel de testador ou QA (Quality Assurance) no time, como a pessoa responsável por garantir a qualidade do software antes dele ser entregue. Se deu problema em produção, o problema é do QA que deixou passar os bugs, certo?

No entanto, quando partimos para abordagens de fluxo contínuo como Kanban ou de entregas iterativo-incrementais como Scrum (ou ainda o misto dos dois com Scrumban), se deixarmos a fase de qualidade para o final de um ciclo, claramente teremos problemas, além de obviamente gerar muito estoque de software não testado o que por si só já é um problema, o que chamamos no Lean Thinking de um dos 7 desperdícios do Lean. Então, aqui já temos um ponto: simplesmente não rola fazer testes só no final ou sempre atrasaremos o fim da sprint!

Mas vamos avançar com outro questionamento: no Scrum, o principal framework ágil do mundo, simplesmente não existe o papel do QA. Temos o Product Owner, o Scrum Master e o Development Team, que em tese engloba todos os demais papéis que não sejam de liderança de produto e de processo, respectivamente. Seriam os QAs desenvolvedores dentro do contexto do Scrum?

O raciocínio vai além disso. O QA (quando existente) não é apenas um desenvolvedor dentro do contexto do Scrum, mas em times ágeis (usando Scrum ou não) você deveria considerar que TODOS possuem a responsabilidade sobre a qualidade do software a ser entregue. O ponto que quero colocar aqui é que, para que exista realmente qualidade no trabalho realizado, TODOS devem ser responsabilizados por ela. E a Definition of Done e os Critérios de Aceitação estão aí para ajudar o time nesse aspecto.

Com isso em mente, vamos explorar quais são os possíveis valores por trás de uma cultura de qualidade em times ágeis. Valores estes que devem ser seguidos por TODOS os profissionais do time e antes de eu dar spoilers, voltarei no final do artigo a falar sobre o papel do QA nisso tudo.

 

Manifesto Ágil para Teste de Software

Todos conhecemos a história do Manifesto Ágil para Desenvolvimento de Software, correto? Esse manifesto acabou inspirando diversos outros e dentro da área da TI inspirou as Agile Coaches sul-africanas da consultoria Growing Agile a criarem o Testing Manifesto em 2013, algo como um manifesto ágil para teste de software.

A ideia deste manifesto, assim como o original é inspirar times de desenvolvimento a aderirem a valores saudáveis e promissores, que lhes ajudem a entregar mais valor para todos.

Acredito que, assim como quando incorporamos os valores do Agile Manifesto no dia a dia dos times provocamos mudanças positivas, incorporar estes valores ao seu rol de práticas e lições possa ajudá-lo a criar uma cultura de qualidade junto aos seus colegas.

O manifesto original é composto por 5 valores, ilustrados na imagem abaixo e que na sequência irei fazer uma possível tradução e dissertarei brevemente sobre os mesmos.

Testing throughout over testing at the end

Cada valor segue a mesma lógica do Agile Manifesto: valoriza-se mais o item à esquerda do que o item à direita. Não é uma substituição, mas uma priorização na cadeia de valores, uma importância maior.

Assim, como primeiro valor temos “Testar através ao invés de testar no final”.

Eu falei sobre isso em meu artigo original e mencionei brevemente este tópico no início DESTE artigo. Se você deixar para testar somente no final da sprint, você estará em maus lençóis e na minha humilde opinião, este comportamento explica por que cerca de 90% dos projetos waterfall falham desde 1994 quando surgiu o Chaos Report.

Vivemos na era da entrega contínua (Continuous Delivery) e de tal forma temos de instruir nossos times a trabalhar com Teste Contínuo (Continuous Testing) também. A cada User Story desenvolvida, a mesma deve ser testada imediatamente e corrigida se necessário, o que nos leva ao próximo valor.

Preventing bugs over finding bugs

Nosso segundo valor é “Prevenir bugs ao invés de achá-los”.

Uma cultura de qualidade prega que ninguém deve ser parabenizado por encontrar bugs, bem como ninguém deve ser depreciado por causá-los, mas sim TODOS devem focar em evitá-los.

Mas como evitamos bugs que ainda não conhecemos?

O primeiro passo é o QA começar a trabalhar ANTES do desenvolvimento. Seja ajudando o Product Owner a especificar os Critérios de Aceite corretamente, seja escrevendo seus testes automatizados usando ATDD/TDD/BDD/etc, seja fazendo Pair Programming com os próprio programadores, para ajudá-los a deixar as funcionalidades com a maior qualidade possível.

Um bom QA não é aquele que acha muitos bugs no software dos devs, mas aquele que ajuda o seu time a não deixar bugs atrapalharem a vida do usuário em produção.

Linkado com as dicas que dei aqui, temos nosso terceiro princípio.

Testing understanding over checking functionality

Este valor pode ser traduzido como “testar entendimento ao invés de checar funcionalidade”.

Software é meio, não é fim. Logo, garantir a qualidade de um software não e limita a checar se ele está funcionando, mas sim se ele resolve o problema do usuário, se ele o ajuda a resolver a sua necessidade.

Assim, uma cultura de qualidade deve promover que os testes sejam feitos sempre sob perspectiva de solucionar o problema ou necessidade do usuário e jamais testar o software pelo software. Novamente, técnicas como ATDD e BDD ajudam aqui, bem como uma boa especificação ágil de requisitos e muita interação com o cliente.

O que nos leva ao próximo valor.

Building the best system over breaking the system

Como mencionei anteriormente, o papel do QA NÃO DEVE ser quebrar o sistema, mas sim ajudar enquanto Developer (segundo Scrum) a desenvolver o melhor sistema possível, e isso é exatamente do que se trata este valor: construir o melhor sistema ao invés de quebrar o sistema.

O racional de que a função do testador de software é “procurar bugs” (por mais que ele tenha uma intenção positiva de evitar que eles cheguem no usuário) é a origem de todo o mal da cultura de testes x a cultura de qualidade.

Quando se testa um software com o mindset de qualidade, procuramos entender se o que foi desenvolvido é o melhor que podemos entregar com as condições que temos visando satisfazer o cliente. Não é apenas ver se o botão salva ao ser clicado, mas se aquele é o melhor botão para resolver o problema do cliente.

E novamente, isso não deve ser feito somente no final do desenvolvimento. O papel de um profissional de qualidade deve ser de ponta a ponta, vide o primeiro valor. Não só dele, mas como de todos membros do time, certo?

Team responsibility for quality over tester responsibility

A responsabilidade pela qualidade deve ser de TODO o time ao invés de somente o testador.

Um Product Owner deve pensar constantemente na qualidade de seu entendimento e da sua comunicação dele para o time (escrita, falada, etc) para que tenhamos qualidade no requisito do projeto/produto.

Um Scrum Master/Agile Coach deve pensar na forma como o processo do time enfatiza a qualidade desejada pelo cliente e empresa, seja minimamente através de um fluxo de valor adequado, bem como boas práticas de engenharia ágil como TDD/ATDD/BDD, Pair Programming, Code Review, Mob Programming e muitas outras.

E os desenvolvedores são parte importantíssima em garantir a qualidade como um todo, fazendo desde um código de qualidade, com padrões concretos e adequados e seguindo as boas práticas sugeridas pelo agilista e mesmo criando práticas emergentes do time que apoiem a qualidade.

Mas se você, assim como eu acredita que “cachorro com dois donos morre de fome”…

O papel do QA Coach

Minha sugestão é que, em times que ainda exista a figura de um profissional especializado em qualidade (QA), ele atue como um coach (treinador) do time em práticas de qualidade. Que ele seja mais um facilitador, um educador e um aliado ao invés da última linha de defesa contra os bugs.

Um QA Ágil ou QA Coach deve ser alguém que não apenas domine técnicas de teste (funcional, automatizado, etc) mas que seja capaz de educar times sob a perspectiva da qualidade. Que assim como o Scrum Master ou Agile Coach que está todo o tempo todo “batendo na tecla” da melhoria contínua, da adaptabilidade, da entrega de valor, etc, que o QA Coach seja o cara que não deixa o time entregar nada menos do que um bom software para o cliente, dentro dos padrões de qualidade estabelecidos previamente.

Não defendo necessariamente a criação deste papel (o Scrum já tem papéis suficientes na minha opinião), em um cenário ideal acredito até que não deveria existir um profissional tão “especializado” assim em times ágeis, que todos developers deveriam ter estas skills, mas esta é uma discussão pra outro momento. Defendo que, nestes casos, que este “chapéu de QA coach” fique mais claro aos desenvolvedores que tenham como especialidade os testes, digo, a qualidade no âmbito de software. 😉

Concorda? Discorda? Deixe nos comentários e vamos bater um papo sobre isso!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!