Qualidade de software é muito mais do que ausência de bugs

Durante muito tempo, quando eu ouvia a expressão qualidade de software, a primeira associação era simples: encontrar bugs antes que o sistema chegasse ao usuário.

Os testes realmente têm um papel importante, mas estudar qualidade de software mostra que essa visão é pequena demais. Um programa pode passar em todos os testes funcionais planejados e, ainda assim, ser lento, inseguro, difícil de usar, complicado de manter ou inadequado à necessidade real de quem o utiliza.

Por isso, qualidade não pode ser reduzida à pergunta “tem bugs?”. A pergunta mais completa é:

Este software atende às necessidades para as quais foi criado, nas condições em que será utilizado?

Qualidade depende da perspectiva

A palavra qualidade muda um pouco conforme o ponto de vista.

Na perspectiva do produto, observamos características que podem ser avaliadas: desempenho, confiabilidade, segurança e facilidade de manutenção, por exemplo.

Na perspectiva do usuário, a questão central é se o sistema resolve uma necessidade real e oferece uma experiência adequada.

Na perspectiva da conformidade, verificamos se o produto foi construído de acordo com requisitos, padrões e critérios previamente definidos.

Na perspectiva do valor, a qualidade também se relaciona ao equilíbrio entre benefícios, desempenho, prazo e custo.

Essas perspectivas não se anulam. Elas se complementam. Um produto tecnicamente sofisticado pode fracassar se não resolver o problema do usuário; um sistema útil pode gerar riscos se não proteger os dados; e uma solução muito boa pode se tornar inviável se seu custo de manutenção crescer continuamente.

Requisitos explícitos e implícitos

A qualidade começa antes do código, na compreensão das necessidades.

Os requisitos explícitos são aqueles declarados e documentados. Por exemplo: “o formulário deve salvar automaticamente os dados preenchidos”.

Já os requisitos implícitos talvez não apareçam escritos, mas são naturalmente esperados. O usuário pode não dizer “o sistema não deve perder meus dados”, porém essa expectativa existe.

Essa diferença explica muitos conflitos em projetos. A equipe pode entregar exatamente o que estava documentado e ainda ouvir que o produto não ficou bom. Em alguns casos, não houve defeito na implementação: houve uma compreensão incompleta da necessidade.

Qualidade exige transformar expectativas em critérios observáveis sempre que possível.

A cadeia entre requisito, projeto, processo e produto

O conteúdo estudado na pós-graduação ajuda a organizar a qualidade em quatro elementos:

Um erro no início da cadeia pode se propagar.

Se o requisito estiver ambíguo, o projeto pode representar a solução errada. Mesmo com um bom projeto, um processo desorganizado pode gerar defeitos, retrabalho e perda de conhecimento. O produto final carrega as consequências das decisões tomadas ao longo de todo o caminho.

É por isso que qualidade não pertence apenas à etapa de testes e tampouco somente à pessoa que ocupa o papel de QA. Ela envolve quem entende o negócio, especifica requisitos, projeta, desenvolve, testa, implanta, opera, atende usuários e mantém o sistema.

Um exemplo prático: uma extensão do navegador

Pense em uma extensão criada para registrar atendimentos. Sua principal função pode estar funcionando: ela recebe os dados e os armazena localmente.

Mesmo assim, vários problemas de qualidade podem existir:

A funcionalidade principal existe, mas a qualidade precisa ser analisada em mais dimensões. Usabilidade, confiabilidade, compatibilidade e manutenibilidade também influenciam o valor real da solução.

Teste e garantia da qualidade não são a mesma coisa

O teste de software busca revelar defeitos e fornecer informações sobre o comportamento do produto.

A garantia da qualidade tem um alcance maior: procura criar condições para que processos e produtos atendam aos requisitos e padrões definidos. Isso pode envolver revisões, critérios de aceite, gestão de configuração, análise de riscos, melhoria de processo, métricas e prevenção de defeitos.

Uma forma simples de lembrar é:

Testar ajuda a descobrir problemas no produto. Trabalhar a qualidade também busca impedir que esses problemas sejam introduzidos.

Isso não diminui a importância dos testes. Pelo contrário: posiciona os testes dentro de uma estratégia mais ampla.

Perguntas úteis para avaliar qualquer software

Antes de afirmar que um sistema “tem qualidade”, vale perguntar:

Essas perguntas transformam uma opinião vaga em investigação.

Conclusão

Ausência de bugs é desejável, mas não define sozinha a qualidade. Um software de qualidade precisa atender necessidades explícitas e implícitas, apresentar características adequadas ao seu contexto e ser produzido por um processo capaz de sustentar sua evolução.

A principal mudança de perspectiva é esta:

Qualidade não é uma inspeção realizada somente no final. Ela é construída desde a compreensão do problema até a operação e a manutenção do produto.

Nos próximos artigos desta série, vou aprofundar o ciclo de vida do software, os modelos de qualidade da ISO e os modelos de maturidade de processos.

Referência complementar

A ISO/IEC 25010:2023 apresenta um modelo de qualidade do produto com características que podem ser usadas na especificação, medição e avaliação de produtos de software e de TIC.

Este artigo organiza reflexões dos meus estudos na pós-graduação em Engenharia da Qualidade e Teste de Software. O objetivo é relacionar os conceitos estudados à prática, sem reproduzir literalmente o material das aulas.