Dando continuidade à série de artigos em que desdobro os principais KPIs que uma liderança de tecnologia deve utilizar em seu dia-a-dia, falaremos agora de um tema super importante: a qualidade do produto entregue. Dimensão que está intimamente relacionada às demais, pois:

• Etapas de verificação e garantia de qualidade são comuns nos fluxos de trabalho de um time de tecnologia. Confira os principais KPIs de acompanhamento para elaborar fluxos eficientes.

• Um produto entregue em produção com uma má qualidade seguramente vai trazer problemas à sua operação, impactando negativamente os seus respectivos indicadores. Confira quais são eles no artigo: Gestão Operacional de TI: Guia completo de métricas e melhores práticas
  
• Ter entregas constantes com qualidade é um importante sintoma que indica quando o time está bem estruturado, dentro de padrões que comentei aqui, além de “saudável”. (Falarei mais sobre essas métricas da saúde em um artigo futuro).
  
  
• Por último, entregas sem qualidade podem diminuir significativamente o retorno financeiro de um produto, trazendo enormes prejuízos à empresa. (Também pretendo abordar indicadores financeiros de tecnologia futuramente). 

Ufa! Muita coisa, não é mesmo? E, olha que eu trouxe apenas as correlações em relação aos temas que fazem parte desta série sobre KPIs de Tecnologia!

Qualidade é um ponto central em qualquer produto, em qualquer segmento de negócio. Impacta na sua reputação, satisfação do cliente e, consequentemente, nos resultados do seu Negócio. Portanto, aperte os cintos e vamos para o 3º e importantíssimo artigo da série sobre KPIs de Tecnologia.

Como rastrear a experiência do usuário para garantir a qualidade do software?

“Qualidade não é apenas uma ausência de erros, está totalmente relacionada a uma boa experiência do usuário”.

Antes de mais nada, gostaria de dizer que não há como saber se seu produto tem qualidade se você não for capaz de rastrear como está sendo a experiência do usuário final ao utilizá-lo.

Normalmente focamos muito em atacar bugs a partir de mensagens de erro ou “crashs” detectados pelo próprio time em um log ou ferramenta de monitoramento; do relato de uma pessoa da área de Qualidade quando testou; e no pior de todos os casos, a partir da reclamação de um usuário final que pegou o erro durante o uso.

Não que isso esteja errado, mas ter um erro “estourando” é sim o indício de uma possível grande crise. Uma interface pouco amigável, com poucas orientações e fluxos confusos, podem fazer seu usuário abandonar o uso do software antes de concluir a operação, o que indica problemas de qualidade no produto. 

É com esse foco mais amplo do que significa “qualidade” que bons times de produto analisam toda a experiência dos usuários através de ferramentas de Product Analytics, como o Amplitude ou o Google Analytics for Firebase, dentre outras.

A partir de inserções de “instrumentações” no código pelo(a) dev, podemos utilizar essas ferramentas para rastrear as ações realizadas pelos usuários e saber o passo-a-passo de como foi sua jornada de uso do software.

É como jogar “migalhas de pão” para saber o caminho percorrido por um usuário.

‍Veja um exemplo de rastreamento de jornada:

1. Usuário viu a tela de login
2. Usuário clicou em “Logar”
3. Usuário viu a tela de welcome (logo não teve nenhum problema de login, usuário, senha incorretos, etc)
4. Usuário clicou em “Comprar” (supondo que há um produto na tela inicial para ele comprar)
5. Usuário viu a tela de welcome (ao invés de ir para uma tela de checkout esperada, o que pode indicar um bug no sistema)
6. Usuário clicou em Sair - (usuário não conseguiu realizar a operação e consequentemente não gera retorno financeiro para seu produto)

Além de perceber exatamente onde está ocorrendo o problema (no exemplo, entre os passos 4 e 5 do fluxo), esse tipo de ferramenta também mostra a % de conversão total do fluxo, ou seja, o percentual de usuários que estão finalizando o fluxo corretamente e aqueles que não estão.

Esse valor é um baita insumo para ajudar a definir o tamanho do problema e priorizar corretamente a urgência da investigação.

Um exemplo ilustrativo do fluxo anterior pode ser visto abaixo:

Fazendo uma leitura rápida do gráfico acima, você pode perceber que dos 100% de usuários que visualizam a tela de login, 1% deles não clica depois no botão para logar no sistema (pode ser que foi para uma tela de recuperação de senha, por exemplo).

Daqueles que clicam em “login”, há alguma quebra, pois apenas 97% visualizam a tela de welcome na sequência (pode ser usuário e senha informados errados, ou algum bug).

Desses, apenas 20% clicam em “comprar” um produto (pode ser uma listagem de produtos confusa ou mesmo um produto não atrativo).

Porém, seguindo o fluxo que comentei acima, vemos que há uma quebra de 5pp daqueles que clicam em “comprar” e, que de fato, visualizam a tela de checkout.

Logo, podemos ter um problema ali e, para solucionar, é necessário fazer um drill down na ferramenta para entender exatamente quais erros ocorrem ou em quais cenários essas pessoas estão caindo.

Resumidamente, seja a partir da análise de um funil de conversão, ferramenta de monitoramento ou a partir do reporte direto de um usuário, temos um evento que precisa ser investigado, corrigido e, em igual importância, registrado, para futuras análises em relação à qualidade que aquele produto vem apresentando. 

Como registrar, avaliar e aprimorar bugs para manter a qualidade do software

O registro de bugs é a principal forma de se rastrear a evolução da qualidade de um produto ou sistema de software.

Já vi muita gente (desenvolvedores, gerentes de produto, etc) subestimarem esse registro, dizendo que “é mais rápido corrigir do que registrar”.

De fato, em algumas situações, principalmente as de crises, a prioridade é atacar o problema. Mas, sem o registro, mesmo que a posteriori do bug detectado - sua causa, ambiente encontrado e solução - , você nunca poderá de fato entender o momento atual da qualidade do seu produto e medir a efetividade de ações de melhoria nesse processo.

Não irei me ater às discussões sobre de quem é a responsabilidade pelo registro de bugs em um time.  Se é necessário ter uma pessoa QA responsável especificamente pela garantia da qualidade ou não, etc.

O importante aqui é saber que o devido registro dos bugs ocorridos no sistema é responsabilidade do time do produto. E para que você tenha boas métricas de qualidade é sugerido o registro das seguintes informações:

• Produto/Sistema em que o bug foi detectado
• Versão: qual a versão do sistema, aplicativo, etc em que o bug acontece
• Ambiente: indicar se o bug ocorreu no ambiente de desenvolvimento, homologação, pré-produção, produção, de acordo com o pipeline utilizado em sua empresa.
  

Essa informação é super importante para determinar o grau de maturidade do seu processo de desenvolvimento.

Times maduros tendem a ter um volume maior de bugs detectados em fases iniciais, desenvolvimento e homologação, enquanto equipes menos maduras, esses bugs surgem mais em fases finais, como pré-produção, regressão e, infelizmente, produção.

• Prioridade: mede a prioridade a ser dada para a correção do bug, normalmente direcionada pelo impacto do bug para o usuário final, medido em “BAIXO/MÉDIO/ALTO”, “1, 2, 3, 4”, etc.
  
  Existem diferentes formas de se obter o valor desse campo. Algumas pessoas utilizam uma classificação direta, mas também é possível através da combinação de outras classificações, como da Matriz GUT, na qual através das informações de gravidade, urgência e tendência do problema é determinada a prioridade a ser dada ao bug.
  
  Mais informações sobre essa ferramenta podem ser encontradas aqui

• Causa Raiz: à medida que você vai criando uma base histórica de bugs é importante ter uma classificação parametrizada das causas mais comuns.
  
  Isso auxilia a identificar e estabelecer planos de ação de melhorias baseados nas causas que ocorrem com mais frequência. Exemplos de causas raiz: “Erro na implementação”, “Quebra do layout”, “Regra de negócio ausente”, etc.

Existe outra infinidade de informações que podem ser coletadas durante o registro de bugs, dependendo da complexidade do seu processo e dos recursos disponíveis.

Contudo, entendo que esse seja o mínimo de informações necessárias para que seja realizada uma boa análise da qualidade do seu produto, com ações de melhoria.

Agora, falando sobre a construção dos indicadores: nada mais são do que a medida da volumetria de bugs por cada uma dessas variáveis descritas acima, Conforme explicado, esses indicadores direcionam a maturidade do time, planos de ação de melhoria, dentre outras tomadas de decisão.

Fechando essa seção, reforço novamente sobre a importância do registro dos bugs.

De nada adianta registrar apenas parte das ocorrências e deixar outras para trás.

Mesmo que o bug em si tenha sido corrigido pela pessoa desenvolvedora, a ausência do devido registro, provavelmente, irá te direcionar a fazer análises incompletas e/ou equivocadas na qualidade e oportunidades de melhoria do seu time.

Por último, não custa dizer também que é preciso ter um ambiente seguro para as pessoas reportarem essas falhas. Do contrário, bugs serão escondidos, seja por medo ou para se criar uma falsa visão de que o produto tem uma qualidade maior do que realmente tem. 

Como garantir a cobertura de testes de forma abrangente 

A cobertura de testes é uma medida do percentual do código-fonte do produto que está testada por testes codificados pelo próprio time em relação ao total, podendo ser focada em linhas de código, ramificações (branches), funções, etc.

Essa métrica desempenha um papel crucial no desenvolvimento, pois indica lacunas de código não testadas e que podem ser potenciais fontes de bugs em produção.

Essa métrica normalmente é obtida diretamente através de ferramentas de inspeção contínua de qualidade de código, plugadas em seu pipeline de desenvolvimento. Entre elas estão: Sonarqube, Code Climate, Codacy, etc.

Uma boa prática nesse contexto é definir nessas ferramentas limites mínimos de cobertura de testes como “quality gates”, a fim de impedir que o processo de desenvolvimento siga para a próxima etapa do pipeline, caso a cobertura dos testes esteja em valores inferiores ao estipulado.   

(fonte: https://www.sonarsource.com/products/sonarqube/)

Para encerrar este tópico, gostaria de expor uma opinião minha sobre a importância da cobertura de testes como métrica para aferir a qualidade de um produto.

Já fui questionado algumas vezes se ter uma alta cobertura de testes realmente indica que o produto tem qualidade, uma vez que a pessoa desenvolvedora pode simplesmente escrever um teste pouco elaborado, tanto por inexperiência, quanto só para “se livrar” do bloqueio do quality gate.

Para essa questão, sempre digo que:

Primeiro, é saudável que você estabeleça momentos de “auditoria” da qualidade do código de teste, assim como é feito para o código do software em si, a fim de mitigar esse problema.

Segundo,  não posso afirmar que um produto com 100% de cobertura de testes tem qualidade, porém posso afirmar que um produto com níveis baixos de cobertura não tem!

Como monitorar a taxa de reversão de código para melhorar a qualidade do software

Observar o que acontece no pipeline de integração/entrega contínua de software pode gerar boas hipóteses acerca da qualidade do produto, uma vez que todo código, com ou sem bug, passa por lá.

Sendo assim, uma métrica interessante de se ter é a Taxa de reversão de código, que pode ser medida através da quantidade de reversões de commits em relação ao total de commits realizados em um repositório de determinado produto/serviço.

A reversão de um commit pode acontecer por diferentes motivos, mas se você acompanhar, seguramente você vai detectar entre os mais frequentes bugs em produção devido a um deploy equivocado.

Essa métrica também “casa” bem com o indicador de % de Incidentes decorrentes de mudanças que já comentei no artigo sobre Kpis da Gestão da Operação de TI, que medem a quantidade de incidentes cuja causa raiz está relacionada com uma mudança realizada no ambiente.

Além disso, a Mentoria CTO do IFTL possui uma aula voltada para gestão de playbooks, o que auxilia no total acompanhamento das principais métricas do negócio. Confira alguns tópicos:

Gestão de playbooks

• Design de processos

• Os elementos de um playbook

• Exemplos de playbooks para um time de tecnologia

• Como criar playbooks eficientes

‍

Deployments frequentes: Indicador de maturidade e qualidade em software

“Times maduros lançam código em produção com mais frequência”.

Como comentei no artigo que origina essa série, segundo Nicole Forgren, em seu livro “Accelerate”, times maduros normalmente fazem um volume maior de deploys (geralmente de porções menores de código) em um período de tempo.

Isso se deve ao fato de que quanto mais frequentes são seus deploys, mais rapidamente você obtém feedback, aprende com o que está sendo implantado e lança features com maior qualidade.
‍
Então, analisar a frequência de deployments dos seus times pode ser um bom indicativo do quão maduro está seu processo de desenvolvimento e, dentro dele, o processo de garantia da qualidade.

É claro, se parte desses deploys for para reverter um código ou corrigir um bug, tem algo errado aí. Por isso, essa é uma métrica que nunca pode ser analisada individualmente, pois pode se tornar um “indicador de vaidade”.

Uma boa forma de complementar a visão acima é periodicamente avaliar o quão seguras e confortáveis as pessoas do time se sentem ao subir um código em produção, a métrica chamada deployment confidence. 

Ela parte do princípio que, quando existe um claro entendimento da arquitetura e das mudanças implementadas, acompanhado de testes bem estruturados, a equipe pode identificar e corrigir problemas rapidamente. Isso permite reverter o código sem dificuldades, caso necessário, reduzindo o estresse ao fazer o deploy para produção. A abordagem pode seguir a estrutura descrita abaixo:

Isso significa que, se seu time realiza deploys frequentemente, apresenta um baixo índice de reversão de código e poucos bugs em produção, além de se sentir confiante ao fazer deploys, parabéns: seu time possui processos de entrega de software altamente maduros e de qualidade.