Uma road trip pela Irlanda, um adesivo no painel e uma reflexão sobre Shift Left, Quality Intelligence e o papel do profissional de qualidade na era dos agentes de IA.
Há uma semana eu estava fazendo uma road trip pela Irlanda.
Saímos de Dublin, passamos por Wicklow para visitar um grande amigo que vive lá, seguimos até Cork, depois Galway, passando pelos Cliffs of Moher e finalmente voltamos para Dublin, parando em algumas pequenas cidades ao longo do trajeto para conhecer um pouco mais da cerveja cultura Irlandesa.
Dirigir pela esquerda não era novidade para mim. Já havia dirigido assim outras vezes, inclusive na própria Irlanda e na ilha de Chipre, que foi uma colônia do Reino Unidopor quase 100 anos. Malta também adota a circulação pela esquerda, embora lá eu tenha usado transporte público e Uber em vez de dirigir.
Portanto, não foi a chamada “mão inglesa” que chamou minha atenção naquela viagem.
Foi um pequeno adesivo no carro alugado, bem próximo ao volante:
STAY LEFT.
Provavelmente estava ali para lembrar turistas acostumados a dirigir pela direita de uma regra que pode ser esquecida em alguns segundos de distração.
Mas eu trabalho com qualidade de software.
E, depois de tantos anos ouvindo e falando sobre Shift Left, era impossível olhar para aquelas duas palavras e pensar apenas no trânsito.
Especialmente porque elas apareceram justamente em um momento em que eu estava repensando o meu próprio papel como profissional de QA.
Durante muito tempo, testar significava esperar
Por muitos anos, um fluxo bastante comum no desenvolvimento de software podia ser resumido assim:
Requisito → Desenvolvimento → Testes → Correções → Release
O problema dessa abordagem é conhecido.
Quando o profissional de testes entra somente depois que grande parte das decisões já foi tomada, muita coisa chega até ele como fato consumado.
O requisito já foi interpretado.
A solução já foi desenhada.
O código já foi escrito.
Às vezes, até a data de entrega já está praticamente definida.
E só então alguém pergunta:
“Está funcionando?”
O movimento de Shift Left surgiu justamente para combater essa lógica: trazer atividades de qualidade, teste e feedback para momentos anteriores do ciclo de desenvolvimento.
Em vez de esperar uma implementação para descobrir que um requisito é ambíguo, questionamos antes.
Em vez de descobrir durante os testes que ninguém definiu determinado comportamento, discutimos critérios de aceite antes.
Em vez de pensar em testabilidade depois do código pronto, tentamos construí-la desde o início.
O próprio conceito aparece em padrões de teste que tratam Shift Left como a antecipação do processo de testes no ciclo de desenvolvimento, buscando feedback e detecção de defeitos mais cedo.
Mas, depois de alguns anos trabalhando dessa forma, percebi que existe uma interpretação de Shift Left que merece ser questionada.
Eu fui cada vez mais para a esquerda
Historicamente, boa parte da minha atuação sempre esteve muito próxima da execução.
Verificação de requisitos e regras de negócio, criação e execução de cenários, investigação de comportamentos, automação e, principalmente, aquela curiosidade quase inconveniente que faz parte do trabalho de quem testa software:
“E se eu fizer isso?”
Em um projeto novo no qual estou trabalhando atualmente, porém, minha atuação mudou bastante.
Passei a dedicar muito mais energia à qualidade antes da implementação.
Requisitos precisam estar suficientemente claros e testáveis.
Critérios de aceite precisam representar o comportamento esperado.
Riscos precisam ser identificados.
As informações necessárias para validação precisam acompanhar a demanda.
Definition of Ready, quando adotada pelo time, precisa representar mais do que um checklist burocrático.
Definition of Done não pode significar simplesmente “o código foi mergeado”.
Backlog, user stories, epics e tasks precisam carregar contexto suficiente para que desenvolvimento, validação e aceite não dependam de reconstruir a intenção original depois.
Em outras palavras:
estou fazendo cada vez mais Quality Assurance e Quality Engineering.
E, curiosamente, executando menos testes da maneira como estava acostumado.
Isso começou a me incomodar.
Não porque eu considere errado atuar dessa forma. Muito pelo contrário.
Mas porque surge uma pergunta legítima:
se eu sou um profissional de qualidade, quanto do meu tempo ainda deveria estar efetivamente testando o produto?
Foi justamente nesse contexto que aquele STAY LEFT apareceu diante de mim.
Então chegaram os agentes de IA
Essa reflexão ficaria relativamente simples alguns anos atrás.
Hoje, não fica.
Porque estamos começando a colocar agentes de inteligência artificial justamente nas atividades para as quais passamos décadas tentando mover QA para a esquerda.
Um agente pode analisar uma demanda.
Pode confrontá-la com documentação existente.
Pode identificar ambiguidades.
Pode sugerir perguntas.
Pode ajudar a transformar intenção em requisito.
Pode propor critérios de aceitação.
Pode analisar riscos e impacto.
Pode propor um plano de mitigação.
Pode produzir uma especificação.
Pode ajudar a criar uma estratégia e um plano de testes.
Pode gerar cenários e casos de teste.
Pode escrever automação.
Pode executar checks.
Pode analisar resultados e produzir documentação.
Isso não é mais apenas uma hipótese conceitual para mim. Tenho trabalhado diretamente com esse tipo de fluxo.
E foi exatamente esse problema que me levou recentemente a palestrar em um meetup aqui em Amsterdam:
When AI Builds the Software, Who Governs the Builder?
A pergunta da palestra não era se IA consegue produzir software.
Consegue.
A pergunta era outra:
Se IA interpreta a solicitação, escreve o requisito, produz a especificação, implementa a funcionalidade e cria os testes... o que, exatamente, foi verificado de maneira independente?
E essa pergunta muda bastante a discussão sobre Shift Left.
Coerência não significa correção
Imagine um agente interpretando uma necessidade de negócio.
A partir dessa interpretação, ele gera o requisito.
Outro agente produz a especificação.
Depois temos código.
Testes.
Automação.
Documentação.
Tudo perfeitamente rastreável.
Tudo consistente.
Pipeline verde.
E tudo errado.
Porque a interpretação inicial estava errada.
Essa foi uma das conclusões mais importantes da discussão sobre Quality Intelligence:
Consistency across AI-generated artifacts is not the same as correctness.
A IA pode criar uma cadeia extremamente coerente a partir de uma premissa incorreta.
Pior: os testes podem ajudar a aumentar nossa confiança nessa premissa.
O requisito diz X.
O código implementa X.
Os testes verificam X.
Todos passam.
Verde.
Mas talvez o usuário precisasse de Y.
Um pipeline verde não é um veredito de qualidade
Essa foi outra das ideias centrais da minha palestra:
A green pipeline is evidence. It is not a quality verdict.
Um teste que passa prova alguma coisa.
Mas precisamos ser muito cuidadosos para definir o quê.
Ele prova que, dadas determinadas condições, aquela verificação produziu o resultado esperado.
Não prova automaticamente que a regra de negócio está correta.
Não prova que a experiência é boa.
Não prova que exploramos todos os riscos relevantes.
Não prova que o usuário compreenderá a interface.
Não prova que aquilo que ninguém especificou funciona adequadamente.
Não prova sequer que fizemos as perguntas certas.
É por isso que gosto de outra formulação que surgiu durante a preparação daquela palestra:
Testing produces evidence. Quality governance decides whether that evidence is sufficient.
E aqui começo a enxergar de outra forma a transformação que estou vivendo profissionalmente.
Talvez não precisemos mover o humano cada vez mais para a esquerda
Precisamos mover qualidade para a esquerda.
Parece uma diferença pequena.
Não é.
Se temos agentes capazes de ajudar na análise de requisitos, especificação, estratégia, planejamento, geração de cenários, automação e execução, não faz sentido medir a relevância do profissional de QA pela quantidade desses artefatos que ele produz manualmente.
Da mesma forma, não faz sentido competir com uma máquina para descobrir quem consegue gerar mais casos de teste.
O valor começa a migrar.
Do volume para o julgamento.
Da execução repetitiva para a investigação.
Da produção de artefatos para a avaliação da qualidade desses artefatos.
Do “o teste passou?” para:
“Essa evidência é suficiente para confiar que podemos avançar?”
Essa é a mudança que comecei a chamar, no contexto da palestra, de evolução de QA para QE e, então, Quality Intelligence.
Quality Assurance procura estabelecer confiança por processos, padrões, revisão e validação.
Quality Engineering incorpora qualidade à própria engenharia e busca prevenir problemas enquanto o produto é construído.
Quality Intelligence adiciona outra questão:
o trabalho conquistou o direito de avançar?
Shift Left continua correto. Mas talvez não seja suficiente.
Na palestra, propus um conceito complementar:
Shift-Up Quality Governance.
Shift Left move atividades de qualidade e validação para momentos anteriores do ciclo.
Shift Up coloca governança sobre o próprio sistema de entrega.
Isso significa olhar não apenas para quando testamos, mas para contexto, risco, evidência, autoridade e progressão.
A pergunta deixa de ser somente:
“Testamos cedo o suficiente?”
E passa a incluir:
“Quem pode decidir? Que contexto é necessário? Qual é o risco? Que evidência é suficiente? Quem tem autoridade para avançar esse estado? Em que momento o sistema deve parar?”
Essa diferença se torna especialmente importante quando agentes começam a ganhar autonomia.
Porque existe uma regra que considero fundamental:
Capability is not authority.
Um agente ser capaz de escrever código não significa que possa aprovar o significado daquela mudança.
Ser capaz de gerar um plano de testes não significa que possa decidir que o plano é suficiente.
Ser capaz de executar todos os checks não significa que possa aceitar o risco residual.
E ser capaz de declarar “done” definitivamente não significa que o trabalho esteja concluído.
Então, onde entra o humano?
É aqui que minha inquietação sobre estar executando menos testes começa a encontrar uma resposta.
Não quero parar de testar.
Muito menos acredito que profissionais de QA devam abandonar Software Testing para virar administradores de processos.
Mas talvez precisemos ser muito mais intencionais sobre onde usamos nossa capacidade humana de testar.
Um agente pode gerar vinte cenários baseados no comportamento especificado.
Eu quero investigar o comportamento que ninguém especificou.
Pode executar centenas de combinações conhecidas.
Eu quero descobrir a combinação que ninguém percebeu que importava.
Pode verificar que cada botão faz aquilo que o requisito determina.
Eu quero perceber que nenhum usuário entenderia por que aquele botão existe.
Pode validar fluxos previstos.
Eu quero sair deles.
Pode encontrar inconsistências sintáticas e semânticas em requisitos.
Eu quero conversar com Product e perguntar:
“Mas isso faz sentido para quem vai usar?”
É aí que entram exploratory testing, experiência do usuário, acessibilidade, diferentes interfaces, fluxos alternativos, estados inesperados, edge cases, border cases e comportamentos emergentes.
Não porque IA seja incapaz de contribuir nessas áreas.
Ela pode — e cada vez mais poderá.
Mas existe uma diferença fundamental entre executar aquilo que conseguimos formular e investigar aquilo que ainda nem percebemos que deveria ser formulado.
Durante a preparação da palestra, chegamos a uma frase que hoje considero ainda mais importante:
Automação verifica o que conseguimos formular. Exploratory testing desafia o que ainda não conseguimos prever.
Talvez aí esteja uma parte importante do futuro do Software Testing.
O QA não desaparece. A abstração sobe.
Já vimos esse movimento antes.
Quando automação cresceu, não eliminou testing.
Mudou aquilo em que fazia sentido gastar esforço humano.
CI/CD não eliminou QA.
Mudou a velocidade e a posição do feedback.
Shift Left não eliminou testes posteriores.
Expandiu a responsabilidade pela qualidade para momentos anteriores.
Agora os agentes de IA estão fazendo algo semelhante em outra escala.
Eles aumentam brutalmente nossa capacidade de produzir, analisar e verificar artefatos.
E justamente por isso precisamos aumentar nossa capacidade de questionar a confiança produzida por esses sistemas.
Quanto mais rápido produzimos evidência, mais importante fica saber se estamos produzindo a evidência certa.
Quanto mais autonomia damos aos agentes, mais importante fica separar capacidade de autoridade.
Quanto mais artefatos conseguimos gerar, mais importante fica distinguir consistência de correção.
Quanto mais verde fica o pipeline, mais importante fica lembrar que:
verde responde apenas às perguntas que fizemos.
Talvez o futuro não seja Shift Left ou Shift Right
Existe ainda outra consequência dessa reflexão.
Qualidade não mora em uma posição do pipeline.
Precisamos atuar antes da implementação.
Durante a implementação.
Depois dela.
E, cada vez mais, também em produção.
Precisamos observar comportamento real, feedback, telemetria, incidentes e aquilo que usuários fazem com nosso produto — inclusive aquilo que jamais imaginamos que fariam.
Então talvez a discussão sobre “esquerda” e “direita” tenha cumprido uma função histórica importante, mas esteja começando a ficar pequena demais para representar o problema.
O que precisamos é de qualidade atravessando todo o sistema e governança acima dele.
Algo próximo de:
Shift Left → Build Quality In → Shift Up → Continuously Validate.
E o profissional de QA deixa de ser simplesmente alguém posicionado em determinada etapa desse fluxo.
Passa a ser alguém capaz de navegar por ele.
Stay Left
De volta à Irlanda, aquele adesivo continuava no painel:
STAY LEFT.
Ele estava ali porque hábitos são poderosos.
Mesmo alguém que sabe perfeitamente que deve dirigir pela esquerda pode, em uma situação de distração, retornar ao comportamento mais familiar.
Talvez nós também precisemos desses pequenos lembretes em qualidade de software.
Durante muitos anos, precisávamos lembrar:
não espere o software ficar pronto para pensar em qualidade.
Stay Left.
Hoje, com agentes de IA participando de praticamente todas as etapas do desenvolvimento, talvez precisemos acrescentar outro lembrete:
não confunda automação com compreensão.
Não confunda consistência com correção.
Não confunda atividade com progresso.
Não confunda um check verde com um veredito.
E, principalmente:
não confunda capacidade com autoridade.
Na palestra da MuTest, comecei com uma pergunta:
When AI Builds the Software, Who Governs the Builder?
Hoje eu acrescentaria outra:
When AI Can Also Test the Software, What Is the Human QA For?
Minha resposta ainda está evoluindo.
Mas cada vez mais acredito que nosso valor não estará em competir com agentes para descobrir quem escreve mais casos de teste, quem produz mais documentação ou quem executa mais checks.
Estará naquilo que sempre esteve no coração do bom Software Testing:
curiosidade, pensamento crítico, investigação, contexto, dúvida e julgamento.
A IA pode nos ajudar a ir para a esquerda.
Pode nos ajudar no meio.
Pode nos ajudar à direita.
Pode produzir e executar uma quantidade de trabalho que seria impraticável manualmente.
Mas alguém ainda precisa decidir se estamos fazendo as perguntas certas.
Talvez, portanto, a evolução do Shift Left não seja mover o profissional de QA cada vez mais para a esquerda.
Talvez seja libertá-lo para estar exatamente onde seu julgamento agrega mais valor.
Stay Left.
But know where the human belongs.
Comentários
Postar um comentário