Teste funcional ou não funcional: o que realmente muda?

Uma verificação não se torna não funcional apenas porque foi automatizada. Um teste continua sendo funcional quando verifica uma funcionalidade do sistema, independentemente de sua execução manual ou automatizada.^[1]

A relação inversa também não deve ser presumida. Testes não funcionais podem ser executados manualmente ou por automação. Assim, encontrar um script, uma ferramenta ou uma ação humana não basta para classificar o teste sem examinar o que está sendo medido.^[2]

Essa separação evita usar automação como sinônimo de categoria. “Funcional” e “não funcional” descrevem o objetivo avaliado nas fontes fornecidas, enquanto “manual” e “automatizado” indicam como a verificação é executada.^{[1, 2]}

O teste unitário verifica isoladamente o comportamento de métodos ou unidades de código. Embora seja automatizado e realizado em baixo nível, ele pode ser considerado funcional quando valida a função executada por aquela unidade.^[3]

Isso mostra por que nível e categoria não são equivalentes. “Unitário” informa que a observação está concentrada em uma unidade de código; não determina sozinho se o aspecto avaliado é funcional ou não funcional. Quando a unidade é verificada para confirmar seu comportamento, a classificação funcional permanece possível.^[3]

Portanto, chamar um teste de unitário não resolve toda a classificação. Ainda é necessário observar o propósito da verificação: confirmar uma função executada pela unidade é o caso funcional explicitamente sustentado pela fonte.^[3]

Uma verificação manual de desempenho pode observar quanto tempo uma operação leva para responder. Também pode acompanhar a velocidade de transferências, como uploads e downloads, ajudando a identificar respostas ou movimentações de arquivos excessivamente lentas.^[4]

Carga amplia a observação para a capacidade do sistema e para seu comportamento sob níveis elevados de acesso. As fontes relacionam avaliações de carga e estresse à verificação de que os ambientes suportam a quantidade prevista de usuários.^{[2, 5]}

Essas avaliações não aparecem como responsabilidade exclusiva de profissionais de QA. Equipes ligadas à infraestrutura e a DevOps também podem executar testes de carga e estresse, especialmente quando a capacidade dos ambientes faz parte do que precisa ser observado.^[5]

A participação de outras áreas decorre, nas fontes, do aspecto examinado. Confirmar o comportamento funcional de uma operação não fornece, sozinho, a observação de tempo, volume de acessos ou capacidade do ambiente exigida por avaliações de desempenho e carga.^{[1, 2, 5]}

Considere uma funcionalidade de envio de arquivo. Verificar se a unidade responsável executa isoladamente a função esperada pode ser um teste unitário e funcional, mesmo que automatizado.^[3]

Observar manualmente quanto tempo o upload leva muda o aspecto avaliado para desempenho. Medir o comportamento do sistema diante de muitos acessos ou verificar se o ambiente suporta a quantidade prevista de usuários direciona a avaliação para carga ou estresse.^{[2, 4, 5]}

A proteção de dados também representa uma pergunta diferente da simples confirmação de que a função executou seu comportamento. Entretanto, as fontes fornecidas não descrevem critérios, técnicas, ferramentas ou participantes para testes de segurança. Por esse limite documental, não é possível detalhar aqui como essa avaliação deve ser planejada ou executada.

A distinção central permanece verificável: a forma de execução e o nível do teste não substituem a identificação do aspecto avaliado. Uma automação unitária pode confirmar comportamento funcional, enquanto tempo de resposta e capacidade sob carga exigem observações próprias e podem envolver infraestrutura ou DevOps além de QA.^{[3, 4, 5]}

A relação desta distinção com os módulos introdutórios de Quality Assurance pode ser consultada no conteúdo relacionado do curso.