Testes não funcionais: o que define se o sistema é bom além de funcionar

Um sistema pode passar em todos os testes funcionais e, ainda assim, ser um fracasso.

Ele faz exatamente o que a especificação pedia. Cada botão funciona, cada cálculo está correto, cada fluxo se completa. E mesmo assim é lento ao ponto de irritar, cai quando muita gente usa, vaza dados na primeira tentativa de ataque e é tão emaranhado que ninguém consegue mudá-lo sem quebrar três outras coisas. Funciona, e é ruim.

Essa diferença entre "faz o que deveria" e "faz bem o suficiente para ser usado de verdade" é exatamente o território dos testes não funcionais. Eles são, no meu modo de ver, a parte da qualidade que mais distingue produtos profissionais de protótipos disfarçados.

Funcional versus não funcional

A distinção é simples de enunciar e profunda nas consequências.

Testes funcionais verificam o que o sistema faz: dada uma entrada, ele produz a saída correta? O cadastro salva? O pagamento é processado? O relatório traz os números certos? São perguntas sobre comportamento e correção.

Testes não funcionais verificam como o sistema faz: quão rápido, quão seguro, quão confiável, quão escalável, quão fácil de usar e de manter. Não perguntam "funciona?", e sim "funciona bem?". Velocidade, segurança, estabilidade sob carga, acessibilidade, tudo isso é não funcional.

A armadilha é que o funcional é fácil de especificar e cobrar, então recebe quase toda a atenção. O não funcional é difuso, fácil de adiar, e por isso costuma ser negligenciado, até virar o motivo pelo qual o sistema falha em produção.

As dimensões que importam

"Não funcional" é um guarda-chuva grande. Vale conhecer as principais dimensões, porque cada uma é uma forma diferente de o sistema decepcionar mesmo funcionando.

Performance é a mais visível: tempos de resposta, velocidade sob uso. Um sistema correto mas lento perde usuários em silêncio. Escalabilidade e capacidade respondem se ele aguenta o crescimento e os picos de demanda, em vez de funcionar só quando poucos o usam.

Confiabilidade e disponibilidade tratam de continuidade: o sistema fica de pé ao longo do tempo, se recupera de falhas, não corrompe dados? Segurança verifica se ele resiste a uso malicioso, e aqui mora a categoria de defeito mais cara, porque uma falha de segurança não frustra o usuário, ela o expõe.

Usabilidade e acessibilidade perguntam se pessoas reais, com diferentes capacidades e contextos, conseguem de fato usar. E manutenibilidade, a mais invisível de todas, pergunta se o time consegue evoluir o sistema sem que cada mudança vire um campo minado.

Por que o não funcional é adiado (e por que é um erro)

Há uma razão estrutural para o não funcional ser negligenciado: ele não aparece na demonstração.

Quando você mostra o sistema para um cliente ou gestor, mostra funcionalidade. "Olha, faz isso, faz aquilo." Ninguém demonstra "olha como ele aguenta dez mil usuários" ou "olha como ele resiste a um ataque". Essas qualidades são invisíveis até o dia em que faltam, e aí aparecem como crise.

O resultado é uma economia falsa. Adia-se o teste de carga, de segurança, de acessibilidade, porque "primeiro precisa funcionar". Aí o sistema vai para produção, cai no primeiro pico, vaza dados ou exclui parte dos usuários, e o custo de corrigir tarde é múltiplas vezes maior do que teria sido testar a tempo.

No setor público isso é especialmente grave. Um sistema de serviço ao cidadão que funciona mas é lento, inseguro ou inacessível não atende a quem mais precisa. E quando lida com dados pessoais, a falha não funcional de segurança esbarra direto na LGPD, deixa de ser problema técnico e vira problema legal.

Testar o não funcional exige outra mentalidade

Testar funcionalidade é relativamente direto: definir entradas, verificar saídas. Testar o não funcional é mais difícil porque exige definir o que é "bom o suficiente", e isso é uma decisão, não um fato.

Quão rápido é rápido o bastante? Quantos usuários simultâneos é "aguentar"? Que nível de disponibilidade é aceitável? Essas perguntas não têm resposta universal; dependem do contexto do negócio e dos usuários. O primeiro trabalho do teste não funcional é, portanto, transformar qualidades vagas em metas mensuráveis. "Rápido" não se testa; "responder abaixo de tal tempo para os 95% dos casos" se testa.

A consequência prática é que requisitos não funcionais precisam ser definidos cedo, junto com os funcionais. Tratá-los como pensamento posterior é garantir que serão testados tarde demais ou nunca.

Os erros que tornam o esforço inútil

O primeiro erro é não definir as metas. Sem um alvo, "testar performance" vira coletar números sem saber se são bons ou ruins. A meta tem que vir antes do teste.

O segundo é testar em ambiente irreal. Medir performance numa máquina diferente da de produção, ou segurança sem cenários realistas de ataque, gera resultados que enganam. O não funcional é especialmente sensível ao ambiente, os números só valem se as condições se parecem com a realidade.

O terceiro é tratar como evento único. Performance, segurança e confiabilidade degradam com o tempo, a cada mudança no sistema. Um teste de segurança feito uma vez no lançamento diz pouco sobre a segurança seis meses e cinquenta releases depois. O não funcional precisa de recorrência.

Qualidade é o que sobra quando a funcionalidade é dada como certa

Há um momento na maturidade de um produto, e de uma organização, em que "funciona" deixa de ser conquista e vira ponto de partida. A partir daí, a qualidade real é definida pelo não funcional: é rápido, é seguro, aguenta, fica de pé, é acessível, é possível evoluir.

Times iniciantes celebram o "funciona". Times maduros sabem que isso é só o piso. O que distingue um sistema profissional de um amadorístico raramente está no que ele faz, está em quão bem ele faz, sob pressão, ao longo do tempo, para todo mundo. Esse "quão bem" é precisamente o que os testes não funcionais protegem.

Ignorá-los não economiza esforço. Apenas transfere o custo para o pior momento possível: a produção, com o usuário presente.

Se o seu produto "funciona" mas você nunca mediu o quão rápido, seguro ou resistente ele é, há provavelmente um risco não funcional esperando aparecer. Tenho outros artigos no blog sobre performance, segurança, confiabilidade e qualidade de software que tratam de cada uma dessas dimensões.