Testar não é só encontrar bugs: como comecei a enxergar QA de outra forma

Quando comecei a estudar sobre QA e testes de software, eu tinha uma visão bem simples sobre o assunto: testar era procurar bugs.

Se encontrasse um erro, o teste tinha cumprido seu papel.

Com o tempo, fui percebendo que a coisa é bem maior.

Um sistema pode funcionar exatamente como foi programado e, mesmo assim, ter problemas que só aparecem quando alguém tenta utilizá-lo de uma maneira diferente daquela que foi imaginada durante o desenvolvimento.

É aí que comecei a entender melhor o papel do QA.

“Mas funciona”

Essa talvez seja uma das frases que mais fazem a gente parar para pensar.

Imagine um sistema com um botão para enviar um formulário.

Você clica nele, o formulário é enviado e aparece uma mensagem de sucesso.

Pronto. Funciona.

Mas será que acabou o teste?

E se o usuário deixar um campo obrigatório vazio?

E se colocar uma informação inválida?

E se clicar várias vezes no botão?

E se tentar fazer tudo usando apenas o teclado?

E se estiver utilizando um leitor de tela?

E se a conexão cair durante o envio?

O botão continua funcionando no cenário original, mas agora começamos a enxergar várias outras possibilidades.

E é justamente aí que testar fica interessante.

O usuário nem sempre usa o sistema como imaginamos

Quem desenvolve uma funcionalidade normalmente conhece muito bem o caminho que ela deveria seguir.

O problema é que o usuário não necessariamente vai seguir esse caminho.

Ele pode clicar onde não deveria, preencher os campos de uma maneira inesperada, voltar para uma página, atualizar o navegador ou simplesmente fazer alguma coisa que ninguém tinha pensado durante o desenvolvimento.

Isso não significa que o usuário está “usando errado”.

Significa que sistemas reais precisam lidar com pessoas reais.

Por isso, acredito que um bom teste precisa ir além do caminho feliz.

O chamado “happy path” é importante, mas não pode ser o único cenário testado.

E a acessibilidade?

Essa é uma parte que considero especialmente importante.

Uma funcionalidade pode estar funcionando perfeitamente para quem utiliza mouse e enxerga a tela.

Mas como ela se comporta para uma pessoa que navega somente pelo teclado?

O leitor de tela consegue identificar o botão?

A ordem de navegação faz sentido?

Os campos possuem informações que permitem entender o que deve ser preenchido?

Uma mensagem de erro é percebida pelo usuário?

Essas perguntas também fazem parte da qualidade do software.

Para mim, esse é um ponto interessante: acessibilidade não deveria aparecer somente depois que o sistema está pronto.

Ela pode fazer parte dos testes desde o início.

Então o que um QA realmente procura?

Não existe uma única resposta.

Um QA pode procurar desde um erro evidente até algo muito mais sutil: uma situação em que o sistema funciona, mas não entrega uma boa experiência para quem está utilizando.

Por isso, alguns testes podem confirmar que uma funcionalidade funciona, enquanto outros tentam justamente descobrir onde ela pode falhar.

E isso muda bastante a forma de olhar para um sistema.

Em vez de pensar apenas:

“O que deveria acontecer?”

também começamos a pensar:

“O que pode acontecer?”

Para mim, essa mudança de perspectiva é uma das partes mais interessantes de QA.

Testar é pensar em possibilidades

Quanto mais estudo sobre testes, mais percebo que não existe um teste perfeito que garanta que um sistema nunca terá problemas.

O objetivo é reduzir riscos, encontrar problemas antes que eles cheguem ao usuário e aumentar a confiança naquilo que está sendo entregue.

E talvez essa seja uma das coisas que mais gosto nessa área.

Você não precisa olhar para o sistema apenas como alguém que quer confirmar que ele funciona.

Você pode olhar e perguntar:

“E se...?”

E se o usuário fizer isso?

E se essa informação vier vazia?

E se a internet cair?

E se alguém utilizar apenas o teclado?

E se o leitor de tela interpretar essa informação de outra maneira?

E se essa funcionalidade for utilizada de uma forma que ninguém imaginou?

Cada “e se?” pode revelar um cenário que ainda não foi testado.

E é justamente por isso que, hoje, quando vejo alguém dizer que “o sistema está funcionando”, minha primeira pergunta provavelmente seria:

Funcionando em quais cenários?

Porque software de qualidade não é apenas software que funciona.

É software que foi colocado à prova.