Como conectar PO, Dev e QA para melhorar a qualidade do produto
Qualidade sempre foi considerada um “mal necessário”
Olá pessoal! Pra quem não me conhece, meu nome é Adriano Driuzzo e essa é a primeira vez que colaboro com a Product Guru’s. Trabalho na área de desenvolvimento desde 2011 e desde 2018 estou focado em teste e qualidade de software.
Gosto muito de postar reflexões sobre a área, então se você quiser me acompanhar, fique à vontade pra me seguir no LinkedIn clicando aqui.
Se você trabalha com metodologia ágil, provavelmente já se pegou no final do ciclo tendo que decidir entre qualidade ou entrega, principalmente se você estiver num contexto de alta performance.
Qualidade sempre foi considerada um “mal necessário”. “Mal” porque ela tem um custo elevado. Custa tempo, esforço e senso crítico. E “necessário” porque se você lança um produto com baixa qualidade, isso pode se tornar o calcanhar de Aquiles do seu produto. Um bug desconhecido que vai pra produção pode virar desde piada (em casos mais simples) até causar prejuízos milionários (em casos mais graves).
Foi pra minimizar esses riscos que surgiu a área de Qualidade de Software dentro do ciclo de desenvolvimento.
Antigamente, o profissional dessa área era chamado apenas de Tester e tinha um papel bem pontual: validar se o produto seguia os requisitos funcionais e procurar bugs. Isso geralmente era feito só depois que o código estivesse pronto e num ambiente de teste.
De lá pra cá muita coisa mudou e a área de testes evoluiu. Hoje o tester passou a se chamar QA (sigla do termo Quality Assurance) e acabou adquirindo uma abordagem mais estratégica e preventiva do que uma atuação pontual no final do ciclo.
Por que o QA costuma achar bugs?
Sabemos que um QA não encontra bugs por acaso. Ele possui técnicas específicas pra isso. E digo mais, ele testa com a intenção de encontrar erros.
Um dos princípios básicos do teste de software é que “o teste mostra a presença de bugs, não a sua ausência”.
O que isso quer dizer?
O teste só consegue provar que um sistema tem bugs. Ele não consegue provar que um sistema não tem bugs. Até porque se, durante um teste não for encontrado nenhum erro, não significa que o sistema está livre de erros, só significa que o teste não conseguiu encontrá-los.
Se pararmos pra pensar, um QA encontra bugs porque ele pensou num cenário “E se eu fizer tal ação, o que vai acontecer?”. Na maioria dos casos o bug já aparece logo no início do teste.
Então o QA costuma encontrar bugs porque o cenário que ele executou não estava sendo esperado, seja pelo código ou pela regra de negócio. Guarde bem esse reflexão, pois vamos voltar a ela mais pra frente.
Por que o papel do QA é importante no ciclo de desenvolvimento?
Vamos no ponto que mais dói em qualquer projeto: o bolso!
Bugs custam caro. O custo de corrigir um bug em produção pode chegar a valores estratosféricos, dependendo da sua criticidade. Em vez do time focar em novas funcionalidades ou trabalhar em melhorias, ele vai passar esse tempo investigando a causa do bug e a sua correção. Enquanto isso o dinheiro tá escorrendo pelo ralo! (Lembram do bug da CrowdStrike que fez parar os aeroportos do mundo todo?)
Mas, assim como uma andorinha só não faz verão, um QA sozinho não faz Qualidade. Qualidade é responsabilidade do time todo. Você até consegue AVALIAR a qualidade de um produto apenas com um QA, mas você só consegue CONSTRUIR qualidade trabalhando como time. E é aí que vamos ver como o QA pode contribuir para alcançar esse objetivo, sendo uma ponte entre a área técnica e de negócio.
Um dos principais problemas no desenvolvimento de software é a falta de clareza entre o que o cliente quer, o que a área de negócios entende e o que o dev pensa que o produto precisa fazer. Geralmente é muito difícil fazer esses 3 fatores se conectarem, pois cada área tem uma linguagem diferente.
Uma das formas de resolver esse problema é aplicando a metodologia BDD no processo de desenvolvimento. Como o próprio nome sugere, Behavior Driven Development é uma metodologia que foca no comportamento do produto, e não na sua parte técnica.
Desmistificando o BDD
Pra usarmos o BDD da melhor maneira, precisamos tirar o mito que existe sobre ele e definir alguns conceitos antes:
Uma confusão que acontece muito é criar cenários de teste em Gherkin e chamarmos de BDD. BDD é metodologia, então você não cria um “teste em BDD”, você cria um teste em gherkin.
Técnicas para atingir o BDD
Beleza, BDD parece muito interessante, mas como aplico isso no dia a dia?
Uma das técnicas que mais contribuem pra atingir o BDD é uma reunião chamada Three Amigos (3 Amigos). Nela, vamos juntar as áreas de Produto, Dev e QA (no mínimo uma pessoa de cada área). Ali os 3 papéis podem:
Conversar sobre ideias de novas features
Elaborar juntos as User Stories
Criar cenários de testes através de exemplos (aqui podemos usar o gherkin para escrever esses cenários)
Definir os critérios de aceite para considerarmos a feature aceita ou concluída
Cada área vai ter um papel nessa reunião:
A pessoa de produtos vai tirar dúvidas e esclarecer como a feature deve funcionar e quais são suas regras de negócio.
O Dev vai analisar a complexidade técnica de como isso será aplicado.
O QA vai pensar em cenários de testes e levantamento de riscos.
Resumindo:
O PO foca no ”O que”.
O Dev foca no “Como”.
O QA foca no “E se…”
Veja que essa abordagem já faz o time pensar em testes e no que pode dar errado antes mesmo da feature começar a ser desenvolvida.
O QA pode trazer insights que ninguém estaria pensando naquela etapa, como: “O que acontece se o usuário ficar inativo por X tempo?”, “Se ele clicar duas vezes no botão de Salvar, o que vai acontecer?”.
Os artefatos gerados nesses encontros serão cenários de fluxo voltados ao comportamento do sistema.
Esses cenários servirão de base pra várias coisas:
O Dev vai se basear neles pra desenvolver.
O QA vai usar esses cenários para testar o que será construído.
Documentação do produto.
Lembra do fato do QA encontrar bugs porque ele pensa em cenários que não tinham sido compartilhados antes?
Note que com isso estamos trazendo esses cenários pro início do ciclo e todo o time vai ter acesso a eles na hora do desenvolvimento. Dessa forma estamos evitando bugs ao invés de encontrá-los. Mais eficiente, não?
Isso acaba reduzindo o tempo do desenvolvimento naquela fase “econtra bug + corrige + valida o ajuste” e o time ganha mais tempo pra desenvolver a feature.
Qual o melhor momento para fazer a reunião dos 3 Amigos?
Se essa reunião for feita na fase de discovery, antes de acontecer a planning ou o refinamento, você consegue iniciar o ciclo com o seu backlog muito mais definido e com um nível de informação melhor para começar o desenvolvimento. Mas sempre que houver uma nova ideia ou dúvida sobre algum fluxo em qualquer fase do ciclo, essa reunião sempre será bem-vinda e todos sempre estarão atualizados. Você pode incluir uma pessoa de UX nessa reunião também, caso seja interessante.
Concluindo
Depois de tudo isso, podemos notar que trazer a área de testes pro início do ciclo (mais conhecido como Shift-Left Testing) traz vantagens pro time todo.
O processo fica muito mais definido.
Aumentamos a previsibilidade de erros.
O produto é desenvolvido com muito mais conhecimento sobre o que ele deve ou não fazer.
Construímos qualidade ao invés de analisar a qualidade.
Fato! Em todos os times que participei (sou UX), sempre que adotamos a prática de reunir UX, PO, QA e ao menos 1 Dev na fase de discovery para discutir sobre a funcionalidade, a demanda saiu muito mais redondinha. Funciona super.
Super concordo! A Qualidade é (ou deveria ser) um valor compartilhado e não responsabilidade de uma só pessoa. Permitir que os profissionais da área de qualidade e testes percorram todas as fases do discovery ao delivery trazendo insights, pensamentos críticos e as perguntas certas é o mundo ideal.