Avaliando a Qualidade

Recentemente o tema “métricas” tem aparecido muito para mim a partir de diferentes situações dos meus últimos dias, na minha cabeça isso só poderia significar uma única coisa: um sinal de que eu deveria escrever um artigo sobre isso!

Eu não pretendo nesse artigo explicar a fundo o que é qualidade, apenas levantarei algumas observações sobre o conceito, porque senão duas coisas ocorreriam: o assunto ficaria muito grande (quero dizer, muito maior do que já ficou) e seria muito difícil manter o foco da discussão, portando isso deixo para outro artigo em outro momento.

Começo então explicando o título deste artigo, digo avaliação e não medição porque é exatamente disso que se trata: a qualidade não deve ser mensurada e sim avaliada e discutida.

Como tudo nessa vida, há algumas opiniões divergentes e contraditórias sobre isso, portando parto de imediato citando quais são minhas referências quando eu falo sobre o que eu falo: Gerald Weinberg, Douglas Hoffman, Cem Kaner (com esse artigo maravilhoso), James Bach, Michael Bolton, Rex Black, Lisa Crispin, Janet Gregory, Selena Delesie, Darrell Huff e toda a base teórica do Lean Six Sigma.

Mensurar e avaliar pode até parecer formas distintas de se dizer a mesma coisa, mas definitivamente não é, vamos tentar entender a diferença:

De acordo com o Vocabulário Internacional de Metrologia (VIM), que é utilizado como referência inclusive para o inmetro:

Medição: Processo de obtenção experimental dum ou mais valores que podem ser, razoavelmente, atribuídos a uma grandeza.

NOTA 1 A medição não se aplica a propriedades qualitativas.
NOTA 2 A medição implica a comparação de grandezas ou a contagem de entidades.
NOTA 3 A medição pressupõe uma descrição da grandeza que seja compatível com o uso pretendido dum resultado de medição, segundo um procedimento de medição e com um sistema de medição calibrado que opera de acordo com o procedimento de medição especificado, incluindo as condições de medição.

Alguns pontos a se entender sobre essa definição da VIM:

• Como grandeza podemos entender uma propriedade de um fenômeno, corpo ou substância, que pode ser expressada como um número e uma referência. Por exemplo: comprimento, tempo, massa e força, velocidade. Para cada grandeza física existe uma unidade que é utilizada para medir essa grandeza.
• Uma propriedade qualitativa carrega sempre uma dose de subjetividade, da avaliação do humano, já que envolve uma interpretação consciente ou inconsciente. Exemplos de propriedades qualitativas são a cor, o sabor, o odor, o timbre de um instrumento musical e a textura, por exemplo, que são propriedades respectivamente ligadas aos sentidos da visão, do paladar, do olfato, da audição e do tato.

A essência dessa definição é no final das contas que, medição é atribuir números de uma maneira que faça sentido para que então possamos fazer decisões que façam sentido.

E tendo isso em vista é necessário dizer que, ao contrário do ideal, no desenvolvimento de software as pessoas tentam contar coisas que não fazem o menor sentido de serem contadas, como casos de testes por exemplo.

Casos de testes é algo péssimo de ser mensurado (mas que é feito constantemente), porque é basicamente, um documento que contém algo relacionado a realização de testes, mas não é possível através da sua quantidade, saber que tipo de teste está sendo feito, se o teste faz sentido, se é relevante, se realmente está ajudando a ter um entendimento melhor do sistema e etc. É como medir o negócio de uma empresa pela quantidade de maletas, gavetas, armários e envelopes em um prédio: “Você tem 9472354 contêineres de coisas de negócios! Seu negócio é maravilhoso.”. Isso simplesmente não tem qualquer serventia prática.

Algumas considerações sobre medição da qualidade:

1. A qualidade não pode ser medida de forma objetiva e abrangente, apenas parcialmente.

Quando nós pensamos sobre qualidade, nos pensamos sobre quão “bom” é um produto. Mas isso não é um aspecto mensurável, como vimos nas definições ditas anteriormente.

O que é “bom” é subjetivo, é um conceito social, definido por uma sensação. Um sorvete gostoso para mim pode muito bem ser algo completamente diferente do que é um sorvete bom para você, já que isso é completamente relativo. O que faz a gente achar algo bom depende de infinitas variáveis que adquirimos ao longo da vida sob as lentes da percepção e da memória. Não existe um tipo único de valor para se focar e também não há uma fórmula confiável e sem controvérsias para isso.

Além disso, o que é bom depende de uma tripla relação entre pessoa, produto e contexto. Mesmo que o produto permaneça o mesmo, se mudarmos a pessoa que o avalia e contexto, ele deixa de ser bom: se experimento meu sorvete favorito no calor vou amá-lo, se experimento o mesmo sorvete no frio extremo, provavelmente vou odiá-lo, talvez só de pensar nisso, já me faça sentir calafrios.

Julgamentos sobre o que é “bom” também pode ter riscos sociais: Se eu te perguntar se um produto é bom ou ruim, e você considerá-lo ruim, mas souber que se disser isso abertamente pode me fazer cancelar o projeto e fazer com que isso cause a demissão de todos os seus amigos, você diria a verdade de forma direta? Se dependemos da honestidade de opinião para avaliar o que é “bom” não é algo que podemos mensurar adequadamente.

Apesar disso tudo, não é errado definir requerimentos de tal forma que possa facilitar medições. Ter medições que façam sentido é extremamente útil, mas é aí que entra a avaliação, ter essas medições não vai fazer com que a “medição da qualidade” seja objetiva e abrangente, só vai tornar possível fazer algumas analises, tentar a partir daí criar algumas percepções a respeito do produto. Talvez, se eu puder medir a pureza e a massa de uma pepita de ouro, eu não vou me importar se não houver alguma maneira mais técnica e assertiva de dizer se a pepita de ouro é realmente “boa” sob o aspecto de melhorar ou piorar a sociedade. Se tudo que eu quiser for vender o ouro, então suas medições quantitativas podem ser os únicos números que importam para mim.

Talvez, melhor que dizer que estamos medindo a qualidade, seja dizer que estamos medindo pistas a respeito da qualidade.

2. O real objetivo é conseguir uma avaliação útil sobre o status do produto

Mesmo que algumas métricas úteis não digam tudo que há sobre a qualidade de um produto, a análise desses valores e de outras avaliações subjetivas do produto feitas de forma sistemática, discutidas sobre diferentes visões e perspectivas, embora não deixem de ser subjetivas, podem tornar o entendimento sobre a qualidade do produto cada vez mais confiável.

Continuar realizando essas avaliações de forma sistemática é a chave aqui, e é um dos principais pontos que aprendi no Lean Six Sigma: analisar dois pontos distintos não é uma forma confiável de analisar dados, em especial sobre qualidade, é necessário que seja feita uma avaliação continua.

Avaliação, muito mais poderosa que medições, é extremamente importante porque, pode sim usar medições como parâmetros para um entendimento, mas não se limita a isso. É possível avaliar com qualquer tipo de evidência. Se o pneu do carro estiver obviamente murcho, é possível constatar isso sem nenhum tipo de métrica, sem precisar constatar a pressão dele, já que ele vai se parecer obviamente murcho.

Coisas que podemos avaliar (sem metrificações):

• Como nós testamos: O que foi testado e o que foi ignorado?
• O que foi encontrado: Quais foram os problemas ou a ausência de problemas (que as vezes pode ser significativo). E eu digo aqui sobre o que foi encontrado e não a quantidade de bugs reportados, que são coisas completamente diferentes.
• O que entendemos sobre os riscos do negócio: O objetivo final é sempre uma avaliação de risco. Como nossos entendimentos sobre o produto podem nos dizer coisas sobre os riscos que entendemos para o produto e os clientes?

3. Medições não devem ser usadas para punir e nem recompensar.

Talvez esse seja o ponto mais universal dentre todas as coisas que digo aqui. James Bach, Rex Black, Lisa Crispin, qualquer referência possível sobre melhoria com Lean Six Sigma e qualquer outra pessoa em sã consciência concorda com esse fato: métricas não podem ser utilizadas para punir e nem recompensar pessoas, caso contrário as pessoas vão encontrar maneiras de burlar o sistema para serem recompensadas ou evitarem serem punidas (talvez o melhor material que eu tenha para esse conteúdo seja este artigo). E devo dizer, é incrivelmente fácil usar números para maquiar um problema e o livro de Darrell Huff “Como mentir com estatística”, ironicamente, não me deixa mentir. Ter números maquiados e a sujeira escondida para debaixo do tapete não vai ajudar em nada entendermos a real situação do produto ou de qualquer outra coisa que seja avaliada. Métricas devem existir somente para entender um cenário, e sobre isso, não há muito o que debater.

Há inúmeros exemplos de como isso pode acontecer na área de qualidade propriamente dita. Por exemplo, vamos supor que as pessoas se sintam ameaçadas pela quantidade de bugs abertos que aparecem no sistema, sejam essas pessoas quem sejam, QA, Dev, Project Manager, etc. Elas poderiam:

• Deixar de reportar bugs, ou não trackear esses bugs.
• Dificultar o acesso dos clientes para reportar problemas.
• Criar bugs com severidade baixa para parecer que os problemas são menores do que são.
• Fazer com que somente bugs impeditivos sejam abertos e que o resto vire dívida técnica.
• Reportar diferentes problemas em um único bug.
• Pular etapas de teste (sem teste, sem bug).
• etc.

Infelizmente porém, muitas vezes o desejo de medições está motivado, não pelo amor ou necessidade de uma racionalidade fria, mas a um desejo de controlar as pessoas ou evitar o debate, já que muitas vezes o diálogo e a discussão (tão necessários na área de qualidade) podem ser bem difíceis. As discussões podem vir a ser algo extremamente politico e emocional, porque entramos na questão de: “quais e de quem são os valores que devem ser considerados para definir a qualidade?”, ou no exemplo que usei aqui mais cedo “A partir de qual paladar vamos definir se o sorvete é gostoso?” e o quanto isso é discutível. Isso me faz lembrar por exemplo de uma anedota que se conta sobre Ford, em uma reunião com designers e engenheiros onde ele diz: “Vocês podem escolher a cor do carro que quiserem, desde que seja preta.”

E digo aqui gestores porque, por mais que, às vezes ,discussões, diálogos e consensos podem ser difíceis para qualquer pessoa do time, são os gestores que, no final das contas tomam as decisões. Baseando-as em métricas ou não.

4. Outras maneiras de pensar sobre metrificações e avaliações em qualidade de software

Gerald Weinberg sugere que pensemos em duas grandes maneiras de avaliar a qualidade de software:

Na primeira, tentamos responder as perguntas: “O que parece estar acontecendo?” e “O que eu deveria fazer agora?”, fazendo como quando dirigimos um carro: Nós olhamos pela janela, escutamos o motor e sentimos a aceleração e desaceleração. Fazemos observações e comparações sem nos preocupar com números ou métricas. “A rua está seca. Está nebulosa. Tem trânsito a direita. Um carro com o farol quebrado, etc.”

Na situação proposta, se você sente que está indo rápido demais (isso acontece por uma grande gama de informações observadas, pela experiência e pelo sentimento fazendo sentido de forma sábia do significado e da significância das coisas), muito provavelmente você está indo rápido demais e é possível tomar uma decisão a partir dai: desacelerar.

Mas vamos supor que mesmo com todas essas observações não de pra saber o quão rápido se está indo. Esse é o momento das avaliações de segunda ordem tentando responder “O que mais eu deveria saber?”, “Onde eu deveria olhar?”, “O que realmente está acontecendo?”, “Como isso está mudando?” e tendem a ser baseadas em valores quantitativos. Essa é a hora de olhar para o velocímetro.

Segundo Gerald, em software, é o que usamos para construir coisas relativamente mais confiáveis como: fazer o sistema mais barato, potente, leve, confiável, rápido (ou devagar), etc.

De uma forma mais aplicada podemos entender por exemplo, uma métrica que geralmente tenta-se usar frequentemente como algo indiscutível sobre a qualidade de um produto: a cobertura de código.

O código não é o produto. O produto é um conjunto de relações entre o software, o hardware, as pessoas, seus desejos, anseios e necessidades (individuais e em grupo), etc. O código é só um modelo do produto. Cobertura de código é somente um jeito de entender quão bem realizamos os testes do produto.

Na maior parte do tempo é impossível mensurar a cobertura de uma maneira objetiva, valida ou confiável porque ao contrário de distância, ou votos, ou bolas de basquete, cobertura não possui uma unidade de medida que seja boa.

Há também uma terceira ordem das avaliações, que são medições extremamente precisas usadas principalmente pelas leis da física, em algo que é extremamente estável e previsível, ignorando completamente a infinidade de variáveis e envolvimentos subjetivos e humanos que ocorrem em um software.

5. Conclusão

Tentei o máximo que pude não deixar esse artigo gigantesco e falhei miseravelmente, mesmo deixando algumas coisas bem interessantes de lado. E isso pode ser percebido considerando o contexto de ser um artigo da internet e não um livro, o fato de eu acreditar (na verdade há varios materiais evidenciando sobre isso) que pessoas na internet não gostam/não tem paciência para ler textos longos. Pode ser percebido caso haja uma contagem de palavras, caso se olhe a correlação entre a estimativa de tempo de leitura fornecido pelo Medium em comparativo aos meus outros artigos, observando o tamanho da barra de rolagem ou simplesmente, lendo.

Mas se você chegou até aqui, obrigado pela leitura.

Espero realmente que eu tenha conseguido trazer algumas reflexões sobre métricas, sobre análise e um pouco a mais sobre a área de qualidade.