Testes funcionais vs não funcionais: o que cada um mede

A diferença cabe em uma única frase: os testes funcionais verificam o que o sistema faz; os não funcionais verificam como ele faz. Se um botão de "Pagar" cobra o valor correto, isso é funcional. Se esse mesmo botão responde em menos de um segundo com 5.000 pessoas comprando ao mesmo tempo, isso é não funcional. Um produto pode passar em cada teste funcional e ainda assim cair no dia do lançamento porque ninguém mediu a segunda parte.

Esse é o erro caro. As equipes preenchem planilhas de casos que verificam regras de negócio (funcional) e dão como certo que "funciona". Mas funcionar na máquina do desenvolvedor, com um único usuário e dados limpos, não é o mesmo que funcionar em produção com carga real, redes lentas e usuários que usam leitor de tela. Este artigo separa os dois eixos e mostra por que você precisa dos dois.

01 · o quêTestes funcionais: verificam o comportamento

Um teste funcional confirma que uma função do produto faz o que a sua especificação diz. Você dá uma entrada, espera uma saída concreta e compara. Se a regra diz "um carrinho com mais de três produtos recebe 10 % de desconto", o teste coloca quatro produtos e verifica que o total caia esses 10 %. Não importa quanto demorou nem quanta memória gastou: importa que o resultado seja o correto.

O padrão internacional de qualidade de produto de software, a ISO/IEC 25010, agrupa isso sob adequação funcional (functional suitability): que as funções estejam completas, sejam corretas e sejam apropriadas para a tarefa [1]. Na prática, quase tudo o que um analista de QA escreve como "caso de teste" com passos e resultado esperado é funcional.

Funcional responde a uma única pergunta: dado isto, o sistema devolve o que deveria?

Exemplos típicos de testes funcionais:

• Login: com credenciais válidas entra; com senha incorreta mostra o erro correto.
• Validações: um email sem arroba é rejeitado; um campo obrigatório vazio não deixa continuar.
• Regras de negócio: o imposto é calculado conforme o país; o frete grátis aplica acima de certo valor.
• Fluxos completos: cadastrar, confirmar por email, entrar e comprar do início ao fim.

02 · o comoTestes não funcionais: verificam a qualidade de serviço

Um teste não funcional não pergunta se o resultado é correto, mas se o sistema é bom enquanto o entrega: rápido, estável, seguro, usável, acessível. São as qualidades que o usuário sente mesmo sem nunca nomeá-las. Ninguém diz "que boa adequação funcional"; as pessoas dizem "isto voa" ou "isto cai o tempo todo".

A ISO/IEC 25010 nomeia essas características de qualidade além do funcional. Entre as mais usadas em QA [1]:

• Eficiência de desempenho (performance): tempos de resposta, uso de recursos, capacidade sob carga.
• Segurança: confidencialidade, integridade, autenticação, resistência a ataques.
• Confiabilidade: disponibilidade, tolerância a falhas, capacidade de recuperação.
• Usabilidade: quão fácil é aprender e operar o produto sem frustração.
• Compatibilidade, manutenibilidade e portabilidade: convive com outros sistemas, muda sem quebrar, move-se de ambiente.

A acessibilidade merece a sua própria linha. Um produto pode passar em todo teste funcional e ser inutilizável para alguém que navega com teclado ou com leitor de tela. As diretrizes WCAG do W3C dão critérios verificáveis (contraste de cor, texto alternativo, foco visível, ordem de tabulação) que transformam "acessível" em algo mensurável e não em uma opinião [3].

O funcional diz se o produto serve. O não funcional diz se ele sobrevive ao contato com usuários reais.

03 · juntosPor que você precisa dos dois eixos, não de um

A armadilha mental é tratá-los como níveis: "primeiro o funcional e, se sobrar tempo, o não funcional". Não são níveis, são eixos independentes. Um produto ocupa um ponto em ambos ao mesmo tempo. Você pode ter funcionalidade perfeita e desempenho desastroso, ou o contrário: algo velocíssimo que calcula mal o imposto.

Pense em um caixa eletrônico. Funcional: entrega o valor exato que você pediu e atualiza o seu saldo. Não funcional: faz essa operação em poucos segundos, não revela a sua senha, e continua funcionando mesmo que centenas de pessoas o usem no dia do pagamento. Se o eixo funcional falha, ele te dá dinheiro a mais ou a menos. Se o não funcional falha, demora cinco minutos, trava no horário de pico ou vaza a sua senha. Nenhuma das duas falhas é aceitável, e nenhuma quantidade de testes de um eixo detecta as falhas do outro.

O ISTQB, o corpo de certificação de referência em testes de software, classifica explicitamente os tipos de teste em funcionais, não funcionais, de caixa branca e de confirmação/regressão, justamente para que um plano de testes cubra ambos os eixos de forma deliberada e não por acaso [2].

Uma regra prática para saber diante de qual você está: se o teste pode ser descrito com "dado X, o sistema deve devolver Y", é funcional. Se é descrito com um advérbio ou uma qualidade ("rapidamente", "de forma segura", "sem cair", "de maneira acessível"), é não funcional, e então falta atribuir-lhe um número.

A lição para qualquer um que construa produto: passar em todos os casos funcionais é condição necessária, mas não suficiente. No dia em que o seu produto crescer, a carga, a segurança e a acessibilidade deixam de ser detalhes e passam a ser o que decide se as pessoas ficam ou vão embora. Meça-os antes que a produção o faça por você.