Por Ernani Ferrari.
O movimento Ágil priorizou o software codificado em detrimento de suas especificações funcionais detalhadas. Depois de mais de duas décadas, as organizações ainda têm dificuldade em explicar os papéis de gerentes de produto, product owners, analistas de negócios, analistas de sistemas de negócios e especialistas em UX. Frequentemente discute-se o que um desenvolvedor deve ou não fazer. Muitas práticas disseminadas promoveram mudança significativa no processo de teste de software, diminuindo a importância de artefatos como desenhos de teste, cenários de teste gerenciados, bancos de dados controlados e ferramentas de automação black-box. A ordem tornou-se ‘teste isso” e, da próxima vez, comece tudo de novo. Na prática, inúmeras organizações de software chegaram até mesmo a eliminar os testadores (ou QAs) por completo. Agora, a IA está apresentando a conta dessas abordagens que, embora adequadas para alguns cenários, podem ser consideradas míopes para a maior parte do mundo do software comercial e de ciclos de vida longos.
Nada acontece sem uma causa. Desenvolvedores de software abraçaram e impulsionaram a adoção das práticas ágeis e gestores aceitaram inúmeras práticas sem entender completamente as consequências da mudança de paradigma que viriam com elas. Regras de ouro da gestão, como “você não pode gerenciar o que não pode medir” ou “não há melhoria de processo sem documentação de processo”, foram deixadas de lado. Enquanto muitos adeptos das abordagens ágeis logo perceberam que as especificações funcionais eram mais relevantes do que alguns agilistas pregavam, e outros continuaram investindo em testes estruturados, a grande maioria das organizações de software não o fez. Quase sempre por falta de experiência ou pela ânsia de resultados rápidos. A história se repete. Profissionais veteranos da indústria de software – entre os quais eu me incluo – passamos por múltiplas revoluções tecnológicas e grandes rearquiteturas e reescritas de sistemas. A maioria dos desenvolvedores de software não passou. Os mais experientes foram levados a entender que é possível criar código a partir de especificações funcionais, mas o contrário é difícil, e na maioria das vezes impraticável.
Sim, IA comete erros
Os recursos de IA estão fazendo maravilhas ao simplificar e agilizar o desenvolvimento e a manutenção corretiva e evolutiva de software. A IA sabe programar. Rápido, barato e repetidamente. Mas comete erros. Muitos erros, às vezes irrelevantes, outras altamente prejudiciais. E IA não tem bola de cristal para descobrir qual deveria ser determinada funcionalidade do software. Não questiona como um desenvolvedor experiente. Simplesmente assume o que seu algoritmo manda.
As máximas do Ágil – “código pronto é mais importante do que especificações’ ou “não perca tempo com especificações porque você não vai usá-las depois que o código estiver pronto” – estão se mostrando altamente equivocadas. As especificações funcionais são a única coisa capaz de dizer à IA o que fazer. Elas podem ser escritas de uma só vez ou fornecidas aos poucos em uma conversa com a IA, mas precisam ser escritas de alguma forma e fornecidas a ela. Sem adivinhação, caso contrário a funcionalidade necessária não existirá. E sim, muita coisa já foi detalhada e escrita antes, então a IA consegue, por exemplo, criar um formulário para coletar dados pessoais, mas o que diferencia o seu software não é o que já está disponível na internet, fonte da maioria dos recursos de IA.
IA não cria conhecimento
No campo dos testes, a IA também está economizando muito tempo das equipes. Mas, similarmente, ela não pode saber o que não está escrito. Consegue analisar seu código e criar um caso de teste unitário, ou analisar suas especificações e criar múltiplos casos de teste. Mas não consegue saber se o software como um todo – resultado do conhecimento humano transformado em design, especificações e código, compilado e instalado – vai fazer o que o negócio ou o usuário precisa. Não consegue avaliar isso tudo e afirmar coisas como “sim, seu usuário conseguirá faturar metade de um pedido, aplicar um desconto a uma fatura, recuperar um e-mail que já foi enviado, ou mudar a cor de um texto marcado”. Cabe a analistas e testadores humanos, munidos de cenários de negócio e artefatos de teste estruturados, chegar a essa conclusão – com ou sem recursos de IA.
Ao final das contas, software é a manifestação de conhecimento transformado. A IA não consegue criar conhecimento, apenas manipular, combinar, calcular e rearranjar conhecimento existente. Se você está criando algo novo, escrevê-lo é o começo de tudo. Faça sua organização aprender a fazer isso. E depois teste o que foi criado para garantir que tal criação foi realizada corretamente. Seus clientes e usuários vão agradecer.
