AIMA: como expandir a atuação de QAs através de indicadores

Com mais empresas se utilizando de KPI’s (Key Success Indicator) para mensurar sua taxa de qualidade em softwares, surgem novas oportunidades para pessoas analistas de qualidade. As possibilidades são diversas: quando nos inserimos em times ou organizações com práticas pouco definidas ou onde o papel de QA ainda não é compreendido.

Sabemos que as atividades desenvolvidas por QA’s dependem do contexto, mas existe um método que você pode utilizar para visualizar pontos de melhoria de forma fácil, assim, agregando valor à empresa e ao seu time rapidamente. Quando aceitamos a oportunidade de atuar em uma equipe sem processos bem definidos de qualidade, precisamos estar prontos para responder as duas seguintes perguntas: "Como você vai agregar valor ao time?" e "Quais são as atividades que vai desempenhar?"

A resposta será sempre a mesma: entender o contexto e identificar pontos de melhoria. Desta forma, você pode trabalhar para ser estratégico em suas ações, pois qualquer afirmação não fundamentada em fatos e dados tem grandes possibilidades de não se concretizar, além de demonstrar que as decisões não foram tomadas em conjunto com o time.
 

Análise

Neste primeiro momento, colete o máximo de informações possíveis e faça anotações. Ao observar intencionalmente, conseguimos identificar pontos de melhoria, que podem ser encontrados por meio de qualquer interação com a equipe, em reuniões ou cerimônias. Além disso, uma forma que gera trocas virtuosas é por meio do pareamento. Esta prática vai acelerar o entendimento das tecnologias utilizadas no projeto e na empresa.

Essa etapa gera insumos para identificação dos pontos que podemos gerar valor com o menor esforço possível.

Impacto

Para impactar precisamos gerar uma atuação valorosa solucionando os problemas cotidianos mais evidentes e que requerem um retrabalho frequente. Fortes pontos a serem melhorados serão sempre aqueles que exigem maior investimento de esforço e tempo, mas caso não sejam realizados podem ter impacto negativo para o produto ou negócio.

Você pode guiar suas ações a partir dos seguintes pontos:  

• Crie relações de confiança com seu time;
• Coloque a experiência da pessoa usuária final no centro das decisões;
• Argumente a partir das KPI's escolhidas;
• Sempre que necessário alinhe as expectativas com as stakeholders do projeto.

A partir desta postura, você ganhará mais espaço para propor mudanças e novas soluções, contribuindo significativamente para a qualidade das entregas.

Metrificação

"O que não é medido não pode ser melhorado". Então, quando pensamos em qualidade de software, mensurar impacto é importante para sabermos se estamos no caminho certo. Caso contrário, podemos mudar a estratégia para alinhar com os objetivos do negócio. As métricas a serem mapeadas vão depender de quais metas foram elencadas para serem alcançadas, como por exemplo: taxa de cobertura de código, defeitos encontrados em produção, complexidade ciclomática.

Por meio de métricas podemos atestar a confiabilidade e consistência do trabalho desenvolvido, utilizando isso como insumo para tomar decisões estratégicas.

Apresentação

Este é um momento crucial em nosso ciclo, pois é por meio dele que demonstramos nossa taxa de sucesso utilizando os indicadores elencados no início do planejamento. Neste ponto, devemos realizar a apresentação das metas trabalhadas durante o período estipulado, expondo o resultado dos impactos causados pelo plano de ação do time.

Além dos pontos trabalhados, devemos dar visibilidade de quais foram as lições aprendidas a partir dos resultados já obtidos e quais serão próximos passos a serem desenvolvidos no próximo ciclo.

 

O método AIMA na prática

Contexto:

Isabelle foi contratada por uma empresa do setor financeiro e recebeu a informação que se juntará a um time recém formado, responsável por realizar o desenvolvimento de uma nova funcionalidade para seu sistema principal. A funcionalidade deverá compensar o pagamento de boletos em até 1h.
 

Passo 1: análise

Após ser incorporada no time, Isabelle inicia suas observações, tomando nota de tudo que pode ser relevante. Ao interagir com o time, ela realiza questionamentos sobre a nova funcionalidade, de que modo funciona o fluxo de compensação atual, quais os motivos da mudança, qual é o prazo para implementação e como funciona a arquitetura do projeto.

Entre as interações, ela recebe a informação que seu time foi incumbido de realizar um aumento da taxa de qualidade do projeto, tendo como primeiro objetivo ter uma cobertura de código de 30% .Ao conversar com o time, Isabelle percebe que hoje não são realizados testes em nenhuma camada da aplicação, percebendo que existe um desalinhamento entre a KPI estabelecida pela gestão e postura do time em relação a mesma.

Isabelle descobre que no início do projeto, uma desenvolvedora chamada Fernanda chegou a iniciar a criação de testes unitários, mas que acabou por não dar continuidade por conta da demanda de entregas e falta de engajamento do restante do time.
 

Passo 2: impacto

Isabelle conversa com Fernanda e apresenta uma estratégia de testes embasada na KPI proposta, iniciando por um ponto de grande risco que é o módulo responsável por realizar a compensação do pagamento de boleto em até 1h, sendo que o prazo anterior era de até 3 dias. Com o apoio de Fernanda, Isabelle argumenta junto ao time a importância da realização dos testes e quais seriam os impactos do mesmo caso ocorresse uma falha na compensação dos pagamentos.

Assim, o time acorda em iniciar o desenvolvimento de testes unitários para o módulo responsável por compensar os pagamentos. Então, Isabelle e Fernanda ficam responsáveis por iniciar a atividade no próximo ciclo de desenvolvimento.

Logo ao iniciar a criação dos primeiros testes, Isabelle e Fernanda percebem que ao testar nos períodos do anos que anteriormente eram atribuídos ao inicio e fim do horário de verão, o sistema se comporta de maneira inesperada, descobrindo, assim, que havia uma inconsistência no sistema, que ainda estava considerando horário de verão em sua lógica.
 

Passo 3: metrificação

Para poder medir qual o nível de cobertura de código atingido, Isabelle e Fernanda utilizam uma ferramenta de code coverage para gerar um report da porcentagem de linhas cobertas por teste. Esta pratica além de expor o que não está coberto por testes, possibilita ao time tomar decisões estratégicas ao identificar quais pontos estão menos cobertos por testes e, em conjunto com uma estratégia de analise de riscos, detectar quais são as áreas do sistema que devem ser priorizadas ao criar testes.
 

Passo 4: apresentação

Após final do ciclo de desenvolvimento, Isabelle e Fernanda utilizam as informações coletadas para realizar uma apresentação aos stakeholders demonstrando a evolução em relação à meta estabelecida. Demonstram que obtiveram um aumento da taxa de cobertura em 8% e que o próximo passo será implementar uma step de testes na rotina da pipeline do projeto.

Com a apresentação, mais membros da equipe tomaram conhecimento da importância de testes nos projeto e estimaram tempo de desenvolvimento, já incluindo os testes.

Podemos concluir que para alinhar o resultado dos processo de qualidade de software com as expectativas das stakeholders e KPI's propostos, é necessário demonstrar visibilidade sobre o processo a ser utilizado. Desta forma, conseguimos receber feedbacks para aprimorar as ações a cada novo ciclo que rodamos. Quando sabemos onde queremos chegar, alcançar o objetivo é só questão de tempo.