ISO/IEC 25010: o mapa do que significa “software de qualidade”

Em uma reunião de projeto, alguém diz: "o software tem que ser de qualidade". Todos concordam com a cabeça. Ninguém contesta. E esse é o problema: cada um concordou pensando em algo diferente. Um pensou em não travar. Outro, em carregar rápido. Outro, em ser entendido sem manual. A palavra "qualidade" os fez acreditar que estavam de acordo quando na verdade nem sequer falavam da mesma coisa.

A ISO/IEC 25010 existe para acabar com essa confusão. Não é uma regra que obriga você a nada: é um vocabulário. Ela decompõe essa coisa tão escorregadia que chamamos de "qualidade" em oito características concretas, cada uma com nome próprio. E quando algo tem nome, deixa de ser opinião e passa a poder ser medido.

01 · o problemaPor que "qualidade" sozinha não serve para acordar nada

A resposta curta: porque "qualidade" é um recipiente vazio que cada pessoa preenche com sua prioridade. O comercial preenche com "que fique bonito", o de infraestrutura com "que aguente a carga", o de suporte com "que ninguém ligue". Os três têm razão e nenhum se entende com os outros.

A ISO/IEC 25010 faz parte da família SQuaRE (System and Software Quality Requirements and Evaluation), a série de normas ISO/IEC 250xx dedicada a definir e avaliar qualidade de software [1]. Sua contribuição central é um modelo de qualidade do produto: em vez de uma palavra, oito características. E cada característica se subdivide em subcaracterísticas ainda mais concretas. Assim, em vez de pedir "qualidade", você pode pedir "tempo de resposta abaixo de 200 ms com 500 usuários simultâneos", que é uma frase com a qual uma equipe consegue de fato trabalhar.

A qualidade não se discute. Ela se nomeia, e só então se mede.

A norma não diz que todo software deva ser excelente nas oito. Ela diz algo mais útil: aqui estão as oito, escolha quais importam no seu contexto e com que nível de exigência. Um marca-passo e um jogo de celular não compartilham prioridades, e está certo que seja assim.

02 · o mapaAs oito características, na linguagem do dia a dia

Estas são as oito características do modelo de qualidade do produto segundo a ISO/IEC 25010 [1]. Eu as traduzo em perguntas que qualquer um entende.

1. Adequação funcional. Faz o que deve fazer? É a pergunta de se as funções existem, estão corretas e cobrem o que o usuário precisa. Um botão de "salvar" que não salva falha aqui, ainda que seja bonito e rápido.

2. Eficiência de desempenho. Faz isso usando recursos razoáveis? Cobre tempos de resposta, uso de memória e CPU, e capacidade diante da carga. Não é "que seja rápido" e ponto, mas rápido em relação aos recursos que consome.

3. Compatibilidade. Convive com o resto? Mede se o sistema coexiste com outros no mesmo ambiente sem atrapalhar (coexistência) e se troca informação com eles (interoperabilidade). Seu app que exporta para um formato que ninguém mais lê falha aqui.

4. Usabilidade. As pessoas entendem e usam sem sofrer? Reúne se é aprendido sem manual, se protege de erros, se é acessível. Um sistema poderoso que ninguém consegue operar tem um problema real de usabilidade, não um capricho de design.

5. Confiabilidade. Dá para confiar que continuará funcionando? Fala de maturidade (falha pouco), disponibilidade (está lá quando é preciso), tolerância a falhas e capacidade de se recuperar. É a diferença entre "funcionou na demonstração" e "funciona na terça-feira às 3 da manhã".

6. Segurança. Protege a informação e o acesso? Cobre confidencialidade, integridade, autenticidade e que as ações fiquem registradas. Aqui não se trata de o sistema funcionar, mas de ele não funcionar para quem não deve.

7. Manutenibilidade. Dá para mudar sem quebrar tudo? Mede o quão modular é, o quão fácil é testar, modificar e reutilizar. Um código que ninguém se atreve a tocar por medo do que possa quebrar falha aqui, mesmo que funcione hoje.

8. Portabilidade. Dá para mover para outro lugar? Fala de adaptar-se a novos ambientes, instalar sem dor e substituir outro sistema. Software preso a uma única máquina ou a um único fornecedor tem pouca portabilidade.

03 · o uso realNão persiga as oito: escolha quais importam no seu contexto

Aqui está o erro mais comum e também o mais caro: acreditar que um bom produto deve pontuar alto nas oito características ao mesmo tempo. Não. Perseguir as oito por igual é a receita para gastar o triplo e não se destacar em nenhuma. A norma é um cardápio, não uma lista de tarefas obrigatórias.

A pergunta que vale a pena é: neste produto, para este usuário, qual característica é inegociável e qual pode ficar no "suficiente"? Um sistema de pagamentos coloca segurança e confiabilidade acima de tudo, e aceitará uma usabilidade correta mas não deslumbrante. Um protótipo para validar uma ideia prioriza adequação funcional e usabilidade, e pode se dar ao luxo de uma eficiência medíocre porque nunca verá carga real.

É exatamente assim que na Qirava usamos o modelo: não como um checklist para aprovar, mas como o quadro onde uma conversa de produto se torna honesta. Antes de escrever um caso de teste, antes de brigar por uma data, colocamos as oito características sobre a mesa e decidimos, em voz alta, quais são as duas ou três que este produto não pode falhar. O resto é atendido, mas não perseguido até a perfeição.

Esse ato de escolher é o que separa uma equipe que "quer qualidade" de uma que sabe qual qualidade quer. A primeira discute sem fim porque ninguém definiu a palavra. A segunda aponta para o mapa, indica três casas e diz: aqui. Todo o resto é negociável.

Escolher em que ser excelente é uma decisão de produto, não uma renúncia à qualidade.

Na próxima vez que alguém pedir "software de qualidade", não concorde com a cabeça. Pergunte qual das oito. Transformar uma palavra vaga em uma escolha concreta é, provavelmente, o trabalho de QA mais barato e mais valioso que você pode fazer em todo o projeto.