A conversa sobre qualidade de software quase sempre começa com ferramentas. Deveria começar com as consequências. Existe uma versão da conversa sobre qualidade de software que a maioria das equipas de engenharia já teve muitas vezes. Decorre mais ou menos assim: a cobertura de testes é demasiado baixa, o processo de QA é demasiado lento, as ferramentas não estão bem integradas, e algo precisa de mudar antes da próxima versão.
Essa conversa é útil até onde vai. Mas tende a parar ao nível do sintoma, na fricção visível e nos estrangulamentos imediatos, sem chegar à questão subjacente que realmente determina se uma equipa melhora: quanto custa realmente a má qualidade e estamos a medir esse custo corretamente? Construir Qualigentic impeliu-nos a pensar nisto mais cuidadosamente do que o tínhamos feito anteriormente. Eis o que descobrimos.
Os custos visíveis não são os mais caros
Quando as organizações tentam calcular o custo dos problemas de qualidade de software, geralmente começam com o que conseguem medir: o número de bugs reportados, o tempo gasto em retrabalho, os tickets de suporte que remontam a um defeito em produção. Estes números são reais e importantes. No entanto, subestimam sistematicamente o custo real da má qualidade, pois não incluem os custos que não geram um ticket. O engenheiro que passa duas horas a depurar algo que uma suite de testes melhor teria detetado em dois minutos, esse tempo não aparece como um custo de qualidade. Aparece como tempo normal de desenvolvimento. A decisão do produto que é adiada porque a equipa não tem confiança suficiente na base de código existente para adicionar uma nova funcionalidade em segurança, isso também não aparece como um custo de qualidade. Aparece como uma velocidade mais lenta. O cliente que não renova, ou a decisão de aquisição que vai para um concorrente, porque o software teve três incidentes em seis meses, isso pode refletir-se nas receitas, mas raramente é rastreado até ao processo de engenharia que permitiu que esses incidentes ocorressem.
Quando se somam os custos invisíveis aos visíveis, o quadro muda substancialmente. Problemas de qualidade são quase sempre mais caros do que parecem e a diferença entre o custo aparente e o custo real tende a aumentar com a complexidade e criticidade do software.
Porque a abordagem padrão à qualidade não resolve o problema
A resposta padrão para problemas de qualidade de software segue um padrão previsível: investir em melhores ferramentas de teste, aumentar as metas de cobertura de testes, adicionar uma fase de QA ao processo de desenvolvimento e medir o número de bugs detetados antes do lançamento. Estas são intervenções razoáveis. Elas melhoram os resultados. Mas tratam a qualidade como uma atividade a jusante, algo que acontece depois de o código ser escrito, para verificar se o que foi construído está correto.
O problema fundamental deste modelo é que trata a qualidade como uma função da verificação em vez de uma função do design. E quando a qualidade é primariamente uma atividade de verificação, estará sempre em tensão com a velocidade de entrega porque a verificação demora tempo, o tempo é escasso e a escassez leva a atalhos. As equipas que produzem consistentemente software fiável fizeram uma escolha diferente. Elas tratam a qualidade como uma atividade de design – algo que acontece enquanto o sistema está a ser concebido e construído, não depois.
As questões são diferentes: não “funciona isto?” mas sim “sob que condições isto falha e planeámos contra essas condições?”. Esta mudança altera a economia da qualidade.
Quando os modos de falha são considerados durante o projeto, o custo para abordá-los é baixo. Quando são descobertos em produção, o custo é elevado. A diferença não é a complexidade da correção, mas sim a fase em que ocorre.
O problema de manutenção que ninguém orçamenta
Existe um custo específico que merece mais atenção do que geralmente recebe: o custo de manter um conjunto de testes existente a funcionar.
A maioria das equipas, quando pensa no investimento necessário para a qualidade, concentra-se no custo de escrever testes. Essa é a parte visível e orçamentável do trabalho. O que é mais difícil de contabilizar é o custo contínuo de manutenção desses testes à medida que a base de código evolui: atualizar scripts após alterações no código, remover testes redundantes que agora não testam nada, diagnosticar se uma falha representa um defeito real ou um teste desatualizado que já não reflete como o sistema funciona.
Os dados da indústria colocam consistentemente a proporção de esforço do QA dedicado à manutenção entre 60 e 70 por cento. Esta é uma alocação significativa de tempo de engenharia, não destinada a encontrar novos problemas, mas a manter a infraestrutura de deteção existente funcional.
Este encargo de manutenção agrava-se em indústrias regulamentadas. Em ambientes sujeitos a DORA, Solvência II ou PSD2, a qualidade não é apenas uma preocupação interna de engenharia, é um tópico de auditoria. Os reguladores querem cadeias de provas, não capturas de ecrã. Querem ver uma linha rastreável desde o requisito até à execução do teste e ao resultado arquivado, e querem ser capazes de recuperar essa prova sob demanda. Construir e manter essa cadeia de provas manualmente, para além de uma função de QA já sobrecarregada, é um custo significativo e frequentemente subestimado.
Este é um dos problemas Qualigentic foi concebido para responder diretamente. A capacidade de manutenção autónoma, que deteta testes desatualizados, quebrados e redundantes e os refatora automaticamente, existe precisamente porque vimos quanta capacidade de engenharia estava a ser consumida por esse trabalho. E a camada completa de rastreabilidade de auditoria, desde o requisito até ao resultado de execução arquivado, existe porque reconhecemos que, em indústrias regulamentadas, a cadeia de evidências não é uma infraestrutura opcional. É um requisito com um custo, e esse custo deve ser planeado em vez de absorvido.
Aquilo que a Qualigentic nos exigiu que confrontássemos
Qualigentic É um sistema que tem de ser fiável. A natureza das suas funções implica que os problemas de qualidade não ficam isolados: propagam-se, agravam-se e têm consequências que vão além da falha técnica imediata. A sua construção exigiu que fôssemos mais explícitos do que estamos habituados a ser quanto à relação entre qualidade e arquitetura. As decisões tomadas na fase inicial do processo de conceção sobre a forma como os componentes interagem, sobre onde ocorre a validação e sobre como as falhas são detetadas e tratadas têm consequências que se fazem sentir ao longo de meses e anos, e não apenas no sprint atual.
Três aspetos destacaram-se nesse processo e que acreditamos ter uma aplicabilidade mais vasta.
Esse modelo funciona quando o ciclo de feedback é rápido e a equipa de QA tem contexto suficiente para detetar o que é importante. Na prática, geralmente cria um gargalo e uma dinâmica cultural onde a qualidade é vista como responsabilidade de outra pessoa, até se tornar uma emergência. Quando a qualidade é distribuída, com todos os engenheiros a sentirem uma genuína responsabilidade pela fiabilidade daquilo que entregam, a conversa muda. Os problemas são levantados mais cedo, as compensações são feitas de forma mais consciente e o custo acumulado de pequenas cedências na qualidade não cresce silenciosamente até se tornar uma crise.
Esse modelo funciona quando o ciclo de feedback é rápido e a equipa de QA tem contexto suficiente para detetar o que é importante. Na prática, geralmente cria um gargalo e uma dinâmica cultural onde a qualidade é vista como responsabilidade de outra pessoa, até se tornar uma emergência. Quando a qualidade é distribuída, com todos os engenheiros a sentirem uma genuína responsabilidade pela fiabilidade daquilo que entregam, a conversa muda. Os problemas são levantados mais cedo, as compensações são feitas de forma mais consciente e o custo acumulado de pequenas cedências na qualidade não cresce silenciosamente até se tornar uma crise.
A questão da medição
Se a má qualidade é mais cara do que aparenta, a implicação é que o investimento necessário para a resolver também é superior ao que as organizações orçamentam tipicamente. Isto cria um problema prático: como justificar esse investimento a pessoas que trabalham com os números de custos visíveis? A resposta é mudar o que se mede. As métricas que a maioria das equipas de engenharia acompanham: A cobertura de testes, os contadores de erros e o tempo médio de resolução são indicadores retardados. Eles dizem o que aconteceu, mas não o que custou ou o que acontecerá a seguir. As métricas mais úteis são as que capturam os custos invisíveis: a proporção de tempo de desenvolvimento que é reativa em vez de produtiva, a frequência com que o desenvolvimento de novas funcionalidades é retardado por preocupações com a estabilidade do sistema existente, a correlação entre métricas de qualidade e a velocidade de entrega ao longo do tempo. Estes números são mais difíceis de produzir. Mas contam uma história mais precisa sobre a economia real da qualidade e tornam a conversa sobre investimento muito mais tratável.
| O que está a medir | O que a maioria das equipas monitoriza | Aquilo que realmente importa |
|---|---|---|
| Cobertura de testes | % de linhas abrangidas | ✓ Modos de falha cobertos |
| Contagem de bugs | Bilhetes registados | ✓ Erros que nunca chegaram a um bilhete |
| Investimento em QA | Ferramentas e pessoal | ✓ Carga de manutenção + custo invisível |
| Velocidade de entrega | Pontos de história por sprint | ✓ Perda de velocidade devido à ansiedade de qualidade |
| Custo do incidente | É hora de resolver | ✓ Impacto nas receitas e na confiança a montante |
| Propriedade de qualidade | Responsabilidade da equipa de QA | ✓ Todos os engenheiros, todos os sprint |
O que isto significa na prática
A implicação prática de pensar na qualidade desta forma é que as intervenções que valem a pena fazer são diferentes das que tendem a ser priorizadas. As ferramentas importam, mas importam menos do que o design do processo. Uma equipa com ferramentas médias e um processo de qualidade bem concebido superará consistentemente uma equipa com ferramentas excelentes e um mal concebido.
O design do processo é importante, mas é menos importante do que quando o pensamento de qualidade entra no ciclo de desenvolvimento. As equipas que consideram a qualidade durante o design terão um desempenho consistentemente superior às equipas que consideram a qualidade durante a verificação, independentemente de quão bom seja o processo de verificação. E, em última análise, ambos derivam da cultura, onde as pessoas que desenvolvem o software sentem uma propriedade genuína sobre a sua fiabilidade, e se a organização ao seu redor recompensa essa propriedade ou a penaliza silenciosamente em favor da velocidade de entrega. A qualidade é um problema técnico no sentido de que requer competências técnicas para ser resolvido. Mas as decisões que determinam se uma equipa produz software fiável não são, na sua maioria, decisões técnicas. São decisões organizacionais, decisões de processo e decisões culturais tomadas antes do código, com consequências que se manifestam muito depois do lançamento.
Na Caixa Mágica, é assim que encaramos a qualidade não como uma fase do processo de desenvolvimento, mas como uma forma de trabalhar. Qualigentic impulsionou-nos a sermos mais rigorosos. As lições desse processo informam como abordamos todos os projetos que construímos.
Apresentação das provas às entidades reguladoras dentro de 6 a 8 semanas.
