Uma nova conversa na Cantina Horizonte
Depois das primeiras observações, a equipe faz alguns ajustes e pergunta: “Agora está bom?”
Antes de responder, imagine quatro situações diferentes. Em todas elas o sistema continua abrindo e aceitando pedidos.
Situação 1 · O resultado está certo, mas demora
O atendente finaliza um pedido. O valor está correto, mas a confirmação leva 15 segundos para aparecer.
O sistema funcionou? Sim. Essa demora seria aceitável no intervalo, com uma fila de alunos esperando?
Perceba a diferença: o resultado pode estar correto e, mesmo assim, a experiência ser ruim.
Situação 2 · O sistema percebe o problema, mas ninguém entende a mensagem
Um usuário digita uma quantidade inválida e recebe:
Erro 1047
O sistema percebeu que algo não está certo, mas não ajudou a pessoa a entender o que fazer.
Compare com:
A quantidade deve estar entre 1 e 10.
As duas mensagens podem nascer do mesmo problema técnico. Para o usuário, porém, a diferença é enorme.
Situação 3 · No computador está ótimo
No computador da cantina, os botões aparecem perfeitamente. No celular, o botão Finalizar pedido fica apertado, parte do conteúdo sai da tela e é preciso arrastar para os lados.
O sistema deixou de existir? Não. Mas ele continua adequado ao ambiente em que as pessoas realmente vão usá-lo?
Situação 4 · Ontem estava lá
No fim do dia, os pedidos aparecem normalmente. Na manhã seguinte, alguns sumiram.
Agora a pergunta fica ainda mais fácil:
Um sistema pode ser considerado de boa qualidade se não conseguimos confiar que ele manterá os dados registrados?
Qualidade é um conjunto de características
Esses exemplos mostram por que a palavra qualidade é maior do que “o cálculo deu certo”.
Quando avaliamos um software, podemos observar perguntas diferentes:
Ele faz o que precisa fazer?
Os cálculos, regras e funções entregam o resultado esperado?
Ele responde bem?
O tempo de resposta é adequado para a situação real?
As pessoas conseguem usar?
A interface e as mensagens ajudam, em vez de atrapalhar?
Podemos confiar nele?
O sistema mantém seu funcionamento e seus dados de forma consistente?
Convive com o ambiente?
Funciona onde precisa funcionar e conversa corretamente com outras partes?
Consegue evoluir?
Uma mudança pode ser feita sem transformar cada correção em um novo problema?
Você não precisa decorar uma lista agora. O objetivo é perceber que qualidade tem várias dimensões.
Existe uma referência internacional para organizar esse olhar
Quando profissionais precisam conversar sobre qualidade, ajuda ter uma linguagem comum.
Uma referência importante é a ISO/IEC 25010:2023.
Antes da sigla, o significado
ISO é o nome curto internacional da International Organization for Standardization, a Organização Internacional de Normalização.
IEC é a sigla de International Electrotechnical Commission, a Comissão Eletrotécnica Internacional.
A ISO/IEC 25010:2023 apresenta um modelo de qualidade de produto com nove características. Não vamos transformar essas características em uma lista para decorar. Vamos voltar a elas quando situações reais do módulo pedirem esse olhar.
O ponto principal por enquanto é simples:
Qualidade pode ser especificada, observada e avaliada por características — não apenas por uma impressão de que “parece bom”.
Mas qualidade não começa quando o sistema fica pronto
Imagine duas equipes.
Equipe A
Cada pessoa trabalha de um jeito. Testes são feitos quando sobra tempo. Decisões importantes ficam em mensagens soltas. Quando alguém sai do projeto, parte do conhecimento vai embora junto.
Equipe B
As regras importantes são registradas. Alterações têm histórico. Defeitos são acompanhados. Há revisões, testes e formas de verificar se o processo está melhorando.
Mesmo antes de olhar para o produto final, já existe uma diferença importante na forma de trabalhar.
Isso nos leva a outra ideia:
Qualidade também depende de como o software é produzido, acompanhado e melhorado.
Duas expressões que você pode encontrar no mercado
Em equipes de software, é comum aparecerem as expressões QA e QC. Vamos apresentá-las sem transformar isso em disputa de siglas.
QA · Quality Assurance
Garantia da Qualidade. Olha fortemente para processos e práticas que ajudam a prevenir problemas e produzir software de maneira mais controlada.
QC · Quality Control
Controle da Qualidade. Olha para o produto e para as evidências que ajudam a descobrir se ele atende ao esperado. Testar software é uma atividade importante dentro desse trabalho.
Na prática, nomes e responsabilidades variam entre empresas. Para nós, a mensagem essencial é esta: qualidade não começa no último teste.
E onde entram CMMI e MPS.BR?
Esses nomes aparecem na formação de Qualidade e Teste de Software porque ajudam a olhar para a capacidade e a melhoria dos processos de uma organização, e não apenas para uma tela ou uma função específica.
CMMI
Capability Maturity Model Integration, ou Modelo Integrado de Maturidade e Capacidade. É um modelo usado para apoiar melhoria de desempenho e de processos organizacionais. A linha atual é o CMMI V3.0.
MPS.BR
Melhoria de Processo do Software Brasileiro. É uma iniciativa brasileira coordenada pela Softex. Quando aparece MPS-SW, o SW indica a referência voltada a software. A versão de referência atual é o MPS-SW:2024.
Não vamos decorar níveis nem transformar esta etapa em um curso de modelos de maturidade. Por enquanto, guarde a diferença:
ISO/IEC 25010 nos ajuda a organizar características da qualidade do produto. CMMI e MPS.BR ajudam a olhar para a forma como a organização estrutura e melhora seus processos.
Vamos voltar à Cantina Horizonte
Leia cada situação e diga qual pergunta sobre qualidade ela provoca. Não precisa usar um nome técnico perfeito.
| Situação | O que você perguntaria? |
|---|---|
| O total calculado está errado. | O sistema faz corretamente aquilo que deveria fazer? |
| Finalizar um pedido leva 15 segundos. | O tempo de resposta é adequado? |
| Uma mensagem mostra apenas “Erro 1047”. | A pessoa consegue entender o que aconteceu e como agir? |
| No celular, parte da tela fica escondida. | O sistema funciona adequadamente no ambiente esperado? |
| Pedidos desaparecem no dia seguinte. | Podemos confiar que os dados serão mantidos? |
Agora aparece uma pergunta que não dá para evitar
Volte ao experimento da quantidade zero da etapa anterior.
Você pode achar estranho comprar zero salgados. Mas imagine que o desenvolvedor responda:
“Ninguém me disse qual era a quantidade mínima.”
Então precisamos separar duas coisas:
o que uma pessoa fez durante o desenvolvimento e o comportamento que apareceu quando o sistema foi executado.
É nesse ponto que palavras como erro, defeito e falha deixam de ser sinônimos e começam a ajudar de verdade.
Antes de seguir
Você deve conseguir explicar, com suas próprias palavras:
- por que “funciona” não é sinônimo de “tem qualidade”;
- por que qualidade envolve tanto o produto quanto a forma de produzi-lo;
- o que representam, em linhas gerais, ISO/IEC 25010, CMMI e MPS.BR;
- por que testar é importante, mas não resume sozinho todo o trabalho de qualidade.
Referências desta etapa
ISO/IEC 25010:2023 — modelo de qualidade do produto