Mostra exatamente onde começa a mudança
Um pedido útil começa pela localização e por uma diferença observável entre o que acontece e o que deveria acontecer. Indica o endereço da página, a ação do utilizador e o resultado encontrado. Se houver uma imagem de apoio, acompanha-a com uma explicação escrita que permita reproduzir a situação.
Imagina um site de formação onde queres melhorar a apresentação dos cursos. Dizer que a página precisa de ficar mais simples deixa várias interpretações em aberto. A IA pode reduzir texto, mudar a navegação ou retirar uma opção de compra que considerou redundante, apesar de essa opção ser importante.
Podes tornar o pedido concreto: na página de um curso, depois de escolher uma edição, a pessoa deve ver claramente a data, o preço e as opções de inscrição. Se existe a possibilidade de comprar um conjunto de cursos, essa escolha deve continuar disponível no mesmo percurso e com as regras atuais.
Repara que já estás a separar apresentação de funcionamento. Querer uma página menos carregada não significa querer menos modalidades de compra. A descrição deve tornar essa intenção explícita, para que a simplificação visual seja avaliada sem presumir uma alteração à forma como o negócio vende os seus produtos.
Guarda uma referência do estado anterior quando ela ajudar a comparação. Pode ser uma captura da página e uma descrição do percurso, usando dados de demonstração. A referência permite mostrar o que existia sem obrigar a reconstruir de memória todos os elementos depois de a alteração estar feita.
Para preparar o próximo passo, consulta Desenvolver aplicações com IA.
Diz o que deve continuar a funcionar
Uma alteração tem requisitos novos e compromissos que vêm do estado anterior. Identifica os comportamentos que não podem desaparecer, sobretudo os que só surgem em determinadas condições. Não basta pedir para manter tudo o resto: explica os percursos relevantes e as regras cuja preservação vai fazer parte da verificação.
No exemplo dos cursos, a opção de comprar um conjunto pode aparecer apenas quando existem edições compatíveis. Um teste com um curso isolado não a mostra. Se essa condição não estiver descrita, uma revisão rápida da página pode dar a impressão de que tudo continua correto, embora um percurso comercial tenha desaparecido.
O mesmo cuidado vale para informação guardada. Se pretendes mudar a ordem dos campos de um formulário, esclarece que os registos existentes devem continuar legíveis e utilizáveis. O pedido visual não concede, por si só, liberdade para alterar a interpretação dos dados que a equipa já recolheu e usa.
Esta preparação é uma extensão de planear uma aplicação antes de construir, aplicada a uma parte que já existe. Começas pelo que a aplicação faz hoje e acrescentas a diferença pretendida. Assim consegues avaliar a proposta de mudança sem voltar a discutir todas as decisões do produto.
Se não sabes quais são as dependências, pede primeiro uma análise do impacto. A resposta deve identificar os percursos potencialmente afetados e as dúvidas que precisam de decisão. Esse levantamento pode revelar que uma mudança aparentemente pequena toca em regras de acesso, disponibilidade ou cálculo que merecem tratamento próprio.
Separa correção, melhoria e nova funcionalidade
Uma correção repõe um comportamento esperado; uma melhoria altera a forma de o apresentar ou executar; uma nova funcionalidade acrescenta uma possibilidade. Distinguir estes pedidos ajuda a controlar o âmbito. Quando os misturas numa instrução genérica, torna-se difícil perceber qual das mudanças resolveu o problema e qual introduziu trabalho adicional.
Se as fotografias dos cursos não aparecem, começa por descrever essa falha. Pedir simultaneamente uma nova galeria, uma reformulação da página e outra forma de carregar imagens junta decisões diferentes. A primeira pergunta é se a imagem certa volta a aparecer nas condições em que deveria estar disponível.
Depois podes decidir se a galeria merece ser melhorada. Essa segunda tarefa terá um objetivo próprio, como permitir comparar imagens sem perder a escolha da edição. A separação permite discutir a utilidade da melhoria depois de confirmar que o conteúdo original voltou a funcionar, em vez de aceitar um redesenho por necessidade.
O tamanho do pedido também deve acompanhar a tua capacidade de o rever. Se não consegues verificar várias mudanças independentes numa entrega, reduz o lote. Uma sequência de alterações compreensíveis pode ser mais fácil de acompanhar do que uma transformação extensa cuja explicação se resume a ter ficado melhor.
Verifica a novidade e os percursos anteriores
A validação precisa de confirmar o que mudou e aquilo que devia permanecer. Escolhe exemplos que exercitem as condições relevantes, incluindo uma exceção próxima da mudança. Compara o resultado com o pedido escrito. Uma página que abre e parece correta ainda pode ter perdido uma ação importante para o utilizador.
Para a página de formação, podes verificar uma inscrição individual, a escolha de um conjunto e uma edição sem vagas. Cada situação responde a uma regra distinta. Se a alteração apenas foi observada no primeiro caso, o relatório deve dizer isso, sem apresentar os restantes percursos como igualmente verificados.
Pede evidência do comportamento, não apenas uma lista de ficheiros alterados. Interessa saber se a escolha se mantém ao avançar, se o preço apresentado corresponde à modalidade selecionada e se regressar à página conserva a informação esperada. Os detalhes técnicos só ajudam quando explicam o impacto de uma decisão.
É esta lógica que desenvolvo ao testar uma automação antes da entrega. O teste acompanha a tarefa real da pessoa, incluindo os caminhos menos frequentes que podem ter sido afetados. Não precisas de repetir indiscriminadamente todos os testes do projeto, mas de justificar os que cobrem a mudança.
Fecha a alteração com uma explicação verificável
Uma alteração fica pronta para decisão quando sabes o que mudou, o que foi verificado e o que permanece por confirmar. Pede um resumo ligado ao comportamento do utilizador e às regras preservadas. Se houver uma limitação, ela deve indicar o percurso afetado, para poderes decidir o passo seguinte.
Uma entrega útil diria que a apresentação das opções foi reorganizada, que a inscrição individual e o conjunto continuam disponíveis nas condições previstas e que a edição sem vagas foi verificada. Se a confirmação por email não foi observada, essa ausência precisa de ficar registada com clareza no fecho.
Guarda também a razão da alteração. Da mesma forma que interessa explicar por que uma automação alterou uma campanha, interessa relacionar uma mudança na aplicação com a necessidade que a motivou. Esse registo ajuda a evitar que uma revisão futura elimine uma decisão sem conhecer o seu propósito.
Se os testes revelarem uma regressão, volta ao requisito concreto e identifica o que deixou de funcionar. Preserva a possibilidade de recuperar uma versão conhecida enquanto se prepara a correção. O próximo pedido deve resolver a falha observada com o âmbito necessário, mantendo visíveis as escolhas que já estavam aceites.