Um artigo recente em Empresa rápida faz a afirmação “Graças à IA, o Coder não é mais o Rei. All Hail the QA Engineer.” Vale a pena ler, e seu argumento provavelmente está correto. A IA generativa será usada para criar mais e mais software program; a IA comete erros e é difícil prever um futuro em que isso não aconteça; portanto, se quisermos um software program que funcione, as equipes de Garantia de Qualidade ganharão importância. “Hail the QA Engineer” pode ser uma isca de clique, mas não é controverso dizer que os testes e a depuração ganharão importância. Mesmo que a IA generativa torna-se muito mais confiávelo problema de encontrar o “último bug” nunca irá embora.
No entanto, a ascensão do QA levanta uma série de questões. Primeiro, um dos pilares do QA é o teste. A IA generativa pode gerar testes, é claro — pelo menos pode gerar testes unitários, que são bastante simples. Testes de integração (testes de vários módulos) e testes de aceitação (testes de sistemas inteiros) são mais difíceis. Mesmo com testes unitários, no entanto, nos deparamos com o problema básico da IA: ela pode gerar um conjunto de testes, mas esse conjunto de testes pode ter seus próprios erros. O que significa “testar” quando o próprio conjunto de testes pode ter bugs? Testar é difícil porque um bom teste vai além de simplesmente verificar comportamentos específicos.
O problema cresce com a complexidade do teste. Encontrar bugs que surgem ao integrar vários módulos é mais difícil e se torna ainda mais difícil quando você está testando o aplicativo inteiro. A IA pode precisar usar Selênio ou alguma outra estrutura de teste para simular cliques na interface do usuário. Ele precisaria antecipar como os usuários podem ficar confusos, bem como como os usuários podem abusar (intencionalmente ou não) do aplicativo.
Outra dificuldade com testes é que bugs não são apenas pequenos deslizes e descuidos. Os bugs mais importantes resultam de mal-entendidos: mal-entendidos de uma especificação ou implementação correta de uma especificação que não reflete o que o cliente precisa. Uma IA pode gerar testes para essas situações? Uma IA pode ser capaz de ler e interpretar uma especificação (particularmente se a especificação foi escrita em um formato legível por máquina — embora isso seria outra forma de programação). Mas não está claro como uma IA poderia avaliar a relação entre uma especificação e a intenção unique: o que o cliente realmente quer? O que o software program realmente deve fazer?
A segurança é outra questão: um sistema de IA é capaz de red-teaming em um aplicativo? Eu admito que a IA deve ser capaz de fazer um excelente trabalho de penugeme vimos IA de jogo descubra “truques”. Ainda assim, quanto mais complexo o teste, mais difícil é saber se você está depurando o teste ou o software program em teste. Rapidamente nos deparamos com uma extensão de Lei de Kernighan: depurar é duas vezes mais difícil do que escrever código. Então, se você escreve um código que está nos limites do seu entendimento, você não é inteligente o suficiente para depurá-lo. O que isso significa para o código que você não escreveu? Humanos têm que testar e depurar códigos que eles não escreveram o tempo todo; isso é chamado de “manter código legado”. Mas isso não torna isso fácil ou (para esse assunto) agradável.
A cultura de programação é outro problema. Nas duas primeiras empresas em que trabalhei, QA e testes definitivamente não eram empregos de alto prestígio. Ser designado para QA period, no mínimo, um rebaixamento, geralmente reservado para um bom programador que não conseguia trabalhar bem com o resto da equipe. A cultura mudou desde então? As culturas mudam muito lentamente; duvido. Os testes unitários se tornaram uma prática generalizada. No entanto, é fácil escrever um conjunto de testes que dê boa cobertura no papel, mas que na verdade teste muito pouco. À medida que os desenvolvedores de software program percebem o valor dos testes unitários, eles começam a escrever conjuntos de testes melhores e mais abrangentes. Mas e quanto à IA? A IA cederá à “tentação” de escrever testes de baixo valor?
Talvez o maior problema, no entanto, seja que priorizar o QA não resolve o problema que tem atormentado a computação desde o início: programadores que nunca entendem bem o problema que estão sendo solicitados a resolver. Respondendo a uma pergunta do Quora que não tem nada a ver com IA, Alan Mellor escreveu:
Todos nós começamos a programar pensando em dominar uma linguagem, talvez usando um padrão de design que só pessoas inteligentes conhecem.
Então nosso primeiro trabalho actual nos mostra uma perspectiva totalmente nova.
A linguagem é a parte fácil. O domínio do problema é difícil.
Programei controladores industriais. Agora posso falar sobre fábricas, controle PID, PLCs e aceleração de bens frágeis.
Eu trabalhei em jogos de PC. Posso falar sobre dinâmica de corpo rígido, normalização de matriz, quaternions. Um pouco.
Trabalhei em automação de advertising. Posso falar sobre funis de vendas, double choose in, e-mails transacionais, drip feeds.
Eu trabalhei em jogos para celular. Posso falar sobre design de níveis. De sistemas unidirecionais para forçar o fluxo do jogador. De sistemas de recompensa escalonados.
Você percebe que precisamos aprender sobre o negócio para o qual codificamos?
Código é literalmente nada. Linguagem, nada. Pilha de tecnologia, nada. Ninguém dá a mínima (sic), todos nós podemos fazer isso.
Para escrever um aplicativo actual, você tem que entender por que ele terá sucesso. Que problema ele resolve. Como ele se relaciona com o mundo actual. Entender o domínio, em outras palavras.
Exatamente. Esta é uma excelente descrição do que realmente é programação. Em outro lugarEu escrevi que a IA pode tornar um programador 50% mais produtivo, embora esse número provavelmente seja otimista. Mas os programadores gastam apenas cerca de 20% do seu tempo codificando. Obter 50% de 20% do seu tempo de volta é importante, mas não é revolucionário. Para torná-lo revolucionário, teremos que fazer algo melhor do que gastar mais tempo escrevendo conjuntos de testes. É aí que a percepção de Mellor sobre a natureza do software program é tão essential. Produzir linhas de código não é o que torna o software program bom; essa é a parte fácil. Produzir conjuntos de testes também não é, e se a IA generativa pode ajudar a escrever testes sem comprometer a qualidade dos testes, isso seria um grande passo à frente. (Estou cético, pelo menos por enquanto.) A parte importante do desenvolvimento de software program é entender o problema que você está tentando resolver. Desenvolver conjuntos de testes em um grupo de QA não ajuda muito se o software program que você está testando não resolve o problema certo.
Os desenvolvedores de software program precisarão dedicar mais tempo a testes e QA. Isso é um dado adquirido. Mas se tudo o que obtemos da IA é a capacidade de fazer o que já podemos fazer, estamos jogando um jogo perdido. A única maneira de vencer é fazer um trabalho melhor de entender os problemas que precisamos resolver.