Como avaliar a qualidade de um software com métricas e evidências
Depois de conhecer as características de qualidade de um software, surge uma pergunta inevitável: como transformar essas características em uma avaliação concreta?
Afirmar que um sistema tem boa usabilidade, confiabilidade ou desempenho não é suficiente. É preciso esclarecer o que será observado, como será medido e qual resultado será considerado aceitável.
Essa é a diferença entre uma impressão e uma avaliação planejada.
Modelo de qualidade e processo de avaliação
Dois tipos de referência aparecem com frequência nos estudos de qualidade de software.
A ISO 9126 e a ISO/IEC 25010 ajudam a responder:
Quais características do produto devem ser observadas?
Já a antiga família ISO/IEC 14598 e a atual ISO/IEC 25040 ajudam a responder:
Como a avaliação deve ser planejada e conduzida?
O modelo organiza o objeto da avaliação. O processo organiza as decisões e atividades necessárias para produzir um julgamento sustentado por evidências.
Comece pelo propósito
Toda avaliação deveria começar explicando por que ela será realizada.
O propósito pode ser:
O propósito muda as características relevantes, o rigor necessário e o tipo de evidência.
Uma avaliação para escolher um aplicativo de anotações pessoais não precisa do mesmo nível de formalidade de uma avaliação de software médico. Ainda assim, ambas precisam de critérios coerentes com seus riscos.
Etapa 1: estabelecer os requisitos da avaliação
O primeiro passo é definir o escopo.
É necessário identificar:
Também é importante evitar um escopo genérico como “avaliar a qualidade do sistema”. Uma formulação melhor seria: “avaliar a confiabilidade do salvamento local e a facilidade de recuperação de atendimentos na versão 1.3 da extensão”.
Quanto mais claro o objeto, mais útil tende a ser o resultado.
Etapa 2: especificar métricas e critérios
Depois de selecionar as características, é preciso decidir como observá-las.
Considere o requisito “a extensão deve preservar os dados preenchidos”. Podemos derivar medidas como:
Em seguida, definimos o critério de aceite. Por exemplo:
Todos os campos persistentes devem ser recuperados corretamente em 100% dos cenários planejados de recarregamento e reabertura.
A métrica descreve o que será medido. O critério determina como interpretar o resultado.
Etapa 3: planejar a avaliação
O plano transforma as decisões anteriores em trabalho executável.
Ele pode incluir:
Planejar também significa controlar variáveis. Se o objetivo é comparar o desempenho entre versões, os testes devem usar condições equivalentes. Caso contrário, a diferença pode ser causada pelo ambiente e não pelo produto.
Etapa 4: executar, comparar e julgar
Na execução, a equipe coleta medidas e registra o que ocorreu.
O resultado bruto ainda não é o julgamento. Dizer que uma página levou 1,8 segundo para carregar é uma medida. Concluir que o desempenho foi aprovado exige compará-la ao critério definido, por exemplo, “até 2 segundos”.
Uma avaliação completa conecta três elementos:
Se o critério não foi definido antes, existe o risco de ajustá-lo depois para justificar o resultado.
Evidência vale mais do que “funcionou aqui”
No trabalho de QA, uma boa evidência permite compreender e, quando necessário, reproduzir o que aconteceu.
Ela pode registrar:
Isso não significa acumular documentos sem utilidade. A evidência deve ser suficiente para sustentar a decisão e proporcional ao risco.
Avaliar um pacote de software
Quando avaliamos um produto pronto para uso, a qualidade não está apenas no programa executável.
Também devem ser considerados:
Descrição do produto
As informações comerciais e técnicas permitem que uma pessoa avalie se a solução atende à sua necessidade antes da aquisição?
Prometer uma funcionalidade inexistente é um problema de qualidade, mesmo que o restante do software funcione.
Documentação do usuário
A documentação é completa, correta, consistente e compreensível?
Um sistema pode executar suas funções, mas causar erros se as instruções estiverem desatualizadas.
Programas e dados
O produto apresenta adequação funcional, confiabilidade, desempenho, segurança, capacidade de interação e outras características relevantes?
Essa visão amplia o objeto da avaliação.
O que mudou da ISO 14598 para a ISO 25040
A família ISO/IEC 14598 foi uma referência histórica para o processo de avaliação de produtos de software. Ela foi retirada e seu papel passou a ser tratado pela família SQuaRE.
A ISO/IEC 25040:2024 fornece o framework atual para avaliação da qualidade de produtos de TIC, produtos de software, dados e serviços de TI. Ela define conceitos, requisitos e recomendações para estruturar e melhorar processos de avaliação, mas não fornece um método específico de teste para cada característica.
Ou seja: a norma organiza a avaliação, mas a equipe ainda precisa selecionar técnicas adequadas ao seu objetivo.
Um roteiro simples para projetos pequenos
Mesmo sem um processo formal extenso, é possível aplicar a lógica:
Esse roteiro já reduz julgamentos improvisados.
Conclusão
Avaliar qualidade não é apenas executar testes. É construir uma linha de raciocínio entre necessidade, característica, métrica, evidência e decisão.
A pergunta deixa de ser “eu achei o software bom?” e passa a ser:
Quais critérios foram definidos, quais evidências foram coletadas e o que elas permitem concluir?
Essa mudança torna a avaliação mais transparente, repetível e útil para o negócio.
Referências complementares
Este artigo organiza reflexões dos meus estudos na pós-graduação em Engenharia da Qualidade e Teste de Software. As normas são apresentadas de forma didática; para uso formal, consulte o texto oficial da edição aplicável.