Cadê o QA? - AguiarDev Talks #43

Em uma mesa redonda só com o pessoal da casa, Tiago Aguiar, Rafael Peixoto e Yuri Marcel discutem um movimento que os três vinham percebendo nas últimas empresas por onde passaram: cada vez menos QAs inseridos dentro do time de desenvolvimento. A pergunta que conduz a conversa não é se o QA está acabando, mas para onde essa peça está se deslocando — e o que isso custa em qualidade de produto.

O que foi discutido

• TI como custo — o histórico de tecnologia sendo vista como despesa, não investimento, e o QA como "o custo do custo" dentro dessa lógica.
• Automação de testes — os tipos de teste praticados hoje (unidade, integração, estresse, mutação) e se a automação está absorvendo o trabalho do QA.
• QA dentro do squad vs. QA vertical — comparação entre o modelo brasileiro de QA embutido no time e a estrutura internacional de QA como camada separada, atendendo várias squads.
• Dev testa ou escreve testes? — a diferença entre escrever casos de teste automatizados e efetivamente testar um software de forma exploratória.
• Pressão de prazo e dívida técnica — como testes são o primeiro item sacrificado quando o prazo aperta, e como isso vira dívida técnica.
• Qualidade como visão de negócio — a ideia de que o valor do QA vai além do código, envolvendo usabilidade e a experiência real do cliente.
• Futuro da profissão — se a mudança é um ciclo (como o "web designer que virou front/back") ou uma expansão de escopo.

Principais pontos

A automação não elimina a necessidade de uma "cabeça pensante"

Peixoto argumenta que, mesmo com boa parte do trabalho de teste automatizado, alguém ainda precisa manter e evoluir essa automação conforme o software muda. Para ele, a automação ajuda a ganhar tempo, mas não substitui a interpretação humana sobre o que testar e por quê — especialmente quando o cenário do produto muda e os testes precisam mudar junto.

"Ainda precisa de uma cabeça pensante para evoluir aquilo, para fazer uma manutenção um dia, porque por mais que aquilo a gente vai ganhar um tempo com essa automatização, mas, sendo ou tarde, aquilo vai precisar ser evoluído ou alterado, porque se o software muda, o teste muda" por Rafael Peixoto

Escrever testes não é a mesma coisa que testar

Um dos pontos mais discutidos é a distinção entre desenvolvedores que escrevem testes automatizados e o ato de efetivamente testar um software de forma exploratória. Tiago descreve o testar como uma interação humana com o sistema — experimentar, explorar, aprender com o comportamento da aplicação — algo que uma máquina, programada para checar comportamentos predefinidos, não reproduz.

"Os Devs eles testam ou eles escrevem testes? Parece igual, mas acho que tem um caminho muito grande ali (...) Testar é uma tarefa que exige uma interação da pessoa que está testando com aquele software. Ela experimenta, ela explora, ela aprende com aquele software, uma máquina não faz isso" por Tiago Aguiar

Quando o QA sai do squad, o produto perde contexto

Yuri relata duas experiências distintas: um time de QA automatizando testes dentro da squad, e uma estrutura internacional em que o QA vira uma camada vertical, atendendo várias squads ao mesmo tempo. Nesse segundo modelo, o QA ganha visão macro do negócio, mas perde a profundidade de cada produto — o que, segundo ele, explica bugs que "passaram na qualidade" e discussões sobre de quem é a responsabilidade.

"Quanto mais distante ele for (...) pior a qualidade do produto, esse é o meu ponto de vista" por Yuri Marcel

O dev sacrifica teste sob pressão, e o QA existe para cobrir essa lacuna

Peixoto é direto ao admitir que, sob pressão de entrega, testes são o primeiro item sacrificado — às vezes nem a funcionalidade completa é entregue no prazo, quanto mais os testes. Para ele, isso reforça por que o QA é necessário: o desenvolvedor foca em entregar um código funcional, escalável e performático, e espera que o QA traga o olhar de qualidade que não coube no tempo da sprint.

"A gente deve, passa por esse tipo de situação (...) o papel do QA é importante porque o deve, ele tem o papel de entregar um código, um código de qualidade (...) a gente espera do que há com a sua visão especializada entrar com esse nível de qualidade" por Rafael Peixoto

O valor do QA está na visão de negócio, não só na técnica

Para os três, o papel do QA não vai desaparecer, mas está ganhando uma camada de responsabilidade ligada a negócio — entender se a solução resolve o problema real do cliente, e não apenas se o código está livre de bugs. Yuri reforça que cabe ao próprio profissional de QA mostrar onde gera valor, inclusive para convencer empresas que ainda não entendem bem sua função.

"A gente desenvolve soluções pra pessoas, a gente tem que tratar as pessoas como pessoas, e nada melhor do que um QA ali pra olhar com atenção o que aquela pessoa precisa" por Yuri Marcel

Frase de destaque

"O QA apesar de não ser tratado dessa forma em muito lugar é uma peça importantíssima do ponto de vista de negócio, assim como desenvolvedor tem que entender (...) se a empresa não entende, você como profissional é o primeiro a ter que entender pra poder abrir os olhos da empresa e mostrar meu valor aqui não é somente técnico, mas do ponto de vista de negócio" por Yuri Marcel

Lições do episódio

1. Automatizar testes não elimina a necessidade de alguém pensando sobre o que testar — a automação só entrega valor se for mantida e evoluída junto com o produto.
2. Escrever testes automatizados e testar exploratoriamente são atividades diferentes; um dev que só escreve testes pode não estar de fato testando o comportamento do sistema.
3. Separar o QA da squad para atender várias equipes ao mesmo tempo tem um custo real: a perda de profundidade e contexto sobre cada produto específico.
4. Sob pressão de prazo, teste costuma ser o primeiro item sacrificado — reconhecer isso é o primeiro passo para tratar a dívida técnica gerada, em vez de escondê-la no backlog.
5. O valor de um profissional de QA não está apenas em achar bugs, mas em entender se a solução resolve o problema do cliente — e cabe ao próprio profissional comunicar esse valor para a empresa.