A mesa redonda da Unidade de Engenharia da Qualidade reuniu para partilhar o tema “Como comunicar o valor da qualidade de software?”.
Convencer e investir continuamente em uma abordagem de qualidade exige a percepção do seu valor.
Frequentemente associada a uma função de suporte e redução de risco, a qualidade do software é considerada difícil de alinhar nos objetivos de negócios tradicionais.
A justificação de um retorno sobre o investimento também costuma ser solicitada pelas organizações, uma abordagem quase a reverter.
Compartilhamos os seguintes temas:
- O que comunicar, a quem, em que nível, com que frequência?
- Quais indicadores são relevantes de usar? Em que contexto?
- Quais formatos, ferramentas e visualizações podem ser usados?
Agradeço a todos os participantes pela sua participação e contribuição
- Luís Vicente, Lead QA Link na Mercedes-Benz.io
- João Santos, QA Freelancer
- Filipe Sousa, Consultor QA Sênior da Noesis
Pode encontrar o episódio em vídeo e áudio.
A qualidade do software deve trazer valor para a empresa.
Ser capaz de comunicar um valor para o negócio implica a sua presença.
Na verdade, alinhar o valor da qualidade do software com os objetivos valorizados pela empresa continua sendo um verdadeiro desafio.
Esse também é um problema que pode ser encontrado de forma mais geral em TI, sendo o alinhamento do negócio uma prioridade real para CIOs e arquitetos, entre outros.
É possível atingir isso na qualidade do software?
Continua a ser um exercício de comunicação e de colaboração, específico para cada contexto para identificar os pontos relevantes.
Uma coisa é certa: sem o foco em trazer valor para a organização, uma abordagem de qualidade não durará muito, com falta de contribuição, apoio e visibilidade.
A identificação e comunicação de valor é, portanto, um tema importante a ser abordado.
Quais parâmetros são valorizados pelo cliente?
Passamos a nos concentrar nas expectativas do cliente.
A primeira prioridade é entender o que é valorizado, esperado e imaginado pelos stakeholders.
Em uma primeira iteração, o valor esperado não surge diretamente.
Indicadores de suporte ou limitadores podem às vezes surgir na primeira iteração.
Os objetivos mencionados acima não são os únicos a serem considerados.
Demonstrar escuta ativa, empatia e reformulação são habilidades essenciais neste exercício.
Duas perguntas são úteis para uma primeira troca: “Por quê?” e “Para quê (para)?”.
O próximo passo é traduzir os objetivos em indicadores.
Bons indicadores de qualidade não são de QA.
Medir o desempenho de um sistema não é medir um subsistema só.
As métricas tradicionais de QA são úteis para essa função, mas precisam de ser contextualizadas de forma mais ampla.
Veja o exemplo da cobertura de teste.
Alguns desenvolvedores, por exemplo, buscarão otimizá-lo para 100% em seus testes unitários.
Além disso, um tester irá concentrar-se na cobertura da matriz de casos funcionais, seja manual ou automatizado.
A pergunta deve ser feita ao contrário: a cobertura de teste pode nos ajudar a atingir um objetivo de valor para o cliente?
Se procuramos a estabilidade da experiência do cliente, poderíamos, por exemplo, combinar vários indicadores:
- A cobertura dos testes nos casos de uso mais frequentes e com maior valor
- O número de bugs encontrados pelo cliente, que deve ser próximo de zero nestes casos
- O número de bugs detectados antes da entrega e analisados pelo ambiente, a fim de julgar a relevância da nossa integração
- O tempo para detectar e resolver um caso de uso crítico (também conhecido como MTTI e MTTR)
Essa combinação de indicadores permite julgar o desempenho do sistema de qualidade, em toda a cadeia de valor.
E a automação em tudo isso?
A automação não agrega valor por si só
O Filipe partilhou connosco uma experiência em que apenas o número de testes automáticos era o indicador de desempenho do cliente.
Neste caso, é aconselhável cumprir o dever de aconselhamento para identificar as razões deste enfoque especial e se outras questões não podem ser mais relevantes.
Neste caso específico, podemos encontrar uma forte necessidade de automação impulsionada pela administração para industrializar processos e agilizar as entregas.
No entanto, para atingir esse objetivo, pode ser contraproducente automatizar excessivamente, especialmente onde não é relevante.
O método “5 Why” pode ser usado, formal ou informalmente, dependendo do seu público, e até mesmo como um exercício de reflexão pessoal.
Tal como acontece com os indicadores, os critérios de automação devem ser analisados como um todo.
A automação está frequentemente ligada à necessidade de aceleração, otimização de custos e qualidade de execução do processo.
Várias hipóteses devem ser consideradas para a automação:
- Qual é o investimento necessário para iniciar a automação? (humano, organizacional, ferramentas)
- O escopo da automação está maduro em termos de processo, com relativa estabilidade?
- Qual é o número de execuções e a vida útil dos processos a serem automatizados?
Finalmente, qual é o valor da automação em relação à não automação?
A decisão de automação requer uma consideração cuidadosa do contexto.
Uma organização com uma base sólida de automação pode, com investimento inicial reduzido, capturar valor com mais facilidade, mesmo em áreas pequenas.
Mas a automação é sinônimo de aceleração?
A velocidade da equipa, um valor chave na qualidade do software
A qualidade é frequentemente vista como um fator de desaceleração.
É preciso admitir que, adicionar testes manuais ou automáticos que atrasam a capacidade de validar não parece atraente.
Experiências de teste ignoradas na primeira release instável e de pressão são comuns.
É por isso que uma abordagem de qualidade deve ter no seu prismo a realização de ciclos curtos integrando a qualidade.
Essa velocidade desejada representa dificuldades reais para os diversos atores.
Os desenvolvedores precisam de feedback rápido em suas iterações de desenvolvimento, a fim de entregar rapidamente um incremento de produto.
Posteriormente, as equipas de qualificação e de negócios devem ser capazes de avaliar rapidamente a resposta aos requisitos e a não regressão.
Por fim, a equipa deve ser capaz de medir o valor para o cliente final das funcionalidades entregues.
É este ciclo que deve ser acelerado garantindo a qualidade do produto para atingir a velocidade real.
Um exercício pode ser compartilhar um triângulo para equilibrar velocidade, qualidade e funcionalidade.
Isso na condição de que os testes sejam úteis.
Quantos bugs os seus testes encontraram?
Às vezes, essa é uma questão mal avaliada, em detrimento das “vanity metrics” que maximizam o código ou a cobertura do teste.
O custo adicional de desenvolver e manter testes desnecessários raramente é levado em consideração.
No entanto, é o que acontece facilmente em modelos organizacionais em silos com indicadores locais a serem otimizados.
Uma boa maneira de ter uma perspectiva é considerar vários fatores ao julgar a utilidade dos testes:
- Eles são relevantes para a experiência do cliente ou para os objetivos valorizados pela organização?
- Quantas vezes foram executadas no último mês, com qual índice de estabilidade?
- Quantas vezes eles conseguiram detectar um bug, com qual criticidade, taxa de falsos positivos?
Se os seus indicadores tendem a ser negativos para esses pontos, a relevância dos testes é questionável.
Em nota, os testes que validam os casos de erros e exceções não devem ser analisados pelo seu volume de utilização, com esperança para os clientes.
Calcular um custo por uso também pode ajudar a destacar o custo de otimizações prematuras.
Testar em produção pode ser útil?
Um bom motivo para não testar em produção seria ter um ambiente de não produção idêntico.
Sendo um ideal irreal, estou convencido de que a resposta é afirmativa, esclarecendo o ponto.
A execução de verificações somente de produção que deveriam ter sido feitas anteriormente não é claramente recomendada.
Por outro lado, podem ser muito relevantes e complementares, se bem escolhidos.
A noção de testes de produção baseados em valor deve ser diferenciada entre:
- Testes exploratórios reais destinados a descobrir defeitos por meio de experimentação em escala
- Testes funcionais automatizados regulares de não regressão, frequentemente associados ao supervisão da experiência do cliente
- Testes de disponibilidade, resistência baseados no “chaos engineering”
- Testes de verificação dos requisitos de tempo de resposta, tempo de carregamento de elementos ou de segurança por exemplo
Aqueles que podem ser realizados no início da cadeia devem ser mantidos para complementar os testes e especificidades da produção.
Um processo incremental para criar e comunicar métricas
Pode estar familiarizado com um projeto “Quality Dashboard V1” que está em andamento há meses, em efeito de túnel, sem nenhum dashboard disponível?
A agilidade é mais facilmente abordada para projetos com um componente de negócios, mas é negligenciada para projetos internos.
Definir, coletar e comunicar métricas é um processo que tem mais probabilidade de ser bem-sucedido por meio de uma abordagem iterativa.
Muitos pressupostos estão inicialmente presentes, sendo, portanto, necessário priorizar ações para poder se adaptar rapidamente.
Selecione primeiro as métricas com o maior valor e medi-las o mais rápido possível.
A primeira coleta de dados pode revelar problemas estruturais de qualidade, disponibilidade ou mesmo de relevância.
Portanto, não há necessidade de se perder em fluxos de dados automáticos e painéis coloridos, o foco deve ser a validação dos indicadores.
A segunda etapa é validar a percepção de valor das partes interessadas, que estão focadas nos objetivos do cliente e do negócio.
Usar reuniões de atualização da equipa existentes, retrospectivas e outros rituais é a melhor maneira de obter feedback, além de solicitações informais.
Uma vez alcançada essa primeira versão, após algumas iterações, pode-se iniciar a automação, a implantação em outros produtos e a adição de métricas.
O que apóia a promoção de uma distribuição mais global?
Qual é o valor dos relatórios?
Caso os objetivos estejam bem definidos, os meios de comunicação devem ser adaptados ao público.
Eu quase acrescentaria, sob medida para a pessoa ou os seus “personas”.
Como na vida real, é difícil agradar a todos.
Um diretor em constante movimento provavelmente preferirá um formato simples disponível em um aplicativo, a menos que prefira ter uma atualização de chamada telefônica diretamente.
Uma equipa de desenvolvimento normalmente gosta de painéis coloridos no “modo escuro”. Outros perfis preferiram uma planilha para explorar os dados.
Trabalhar em etapas, entregar o máximo possível e, em seguida, lidar com exceções é uma abordagem 80/20.
Um painel simples pode ser construído e disponibilizado para todos, como uma fonte de verdade.
Se possível, adicione uma capacidade de exportação e envie alertas por e-mail ou telefone para satisfazer o maior número de pessoas possível.
Uma boa prática, quando possível, é exibir este painel em um local por onde as equipas passam, compartilhá-lo com o stand-up diário e sugerir que as equipas o adicione como uma guia automática para abrir o navegador.
Por definição, os painéis têm valor se forem compartilhados, atualizados, regularmente enviados às equipas, adaptados aos canais de uso e utilizados na gestão.
Usando mecanismos existentes para comunicar qualidade
Pode-se desejar criar rapidamente instâncias específicas para falar sobre qualidade.
Uma abordagem pragmática, promovendo a mensagem da transversalidade, é agregar qualidade às reuniões existentes.
Tomemos como exemplo o stand-up diário da equipa, é uma grande oportunidade de partilhar e comunicar de qualidade.
Pontos regulares de retrospectiva e planejamento também devem ser usados para integrar a qualidade como um tema sistemático.
Adicionar indicadores e ações a um processo retrospectivo de incidentes também é uma boa maneira de identificar a necessidade de qualidade em toda a cadeia.
Enfim, com um bom trabalho de influência interna, as reuniões da empresa devem deixar espaço para a qualidade.
Como a publicidade, a qualidade deve estar presente, comunicada e valorizada regularmente para ter um impacto.