Um botão desabilitado não comprova que uma tarefa do agente de IA terminou. Ele informa uma condição da interface: naquele momento, a ação não está disponível por aquele controle. Para encerrar o trabalho, o agente precisa observar o resultado esperado, como um registro criado, um documento salvo ou um pedido identificado no histórico.
Defina antes de executar quais sinais representam espera, erro e conclusão. Depois de clicar, acompanhe esses sinais e verifique o efeito da operação. Se a tela ficar ambígua, consulte o estado do item antes de repetir o comando. Esse procedimento ajuda a evitar tanto relatórios de sucesso prematuros quanto pedidos duplicados.
Resumo rápido
- Separe botão disponível, pedido enviado e resultado confirmado.
- Não use cor cinza ou animação encerrada como prova de conclusão.
- Associe a confirmação ao item e à conta corretos.
- Defina uma espera limitada e o que fazer ao atingir esse limite.
- Antes de repetir, procure o efeito da primeira tentativa.
O que significa um controle indisponível
No padrão HTML, um controle de formulário desabilitado impede determinados eventos de clique de interação do usuário. Essa definição trata do comportamento do controle. Ela não diz por que a aplicação o desabilitou, nem informa que uma gravação no servidor foi concluída.
Um aplicativo pode desabilitar um botão enquanto valida campos, espera um anexo ou processa uma solicitação. Também pode mantê-lo indisponível porque a conta não tem permissão ou porque falta uma informação obrigatória. Esses são cenários de avaliação propostos: a razão concreta precisa ser identificada na ferramenta utilizada.
A aparência sozinha é uma evidência fraca. Um botão pode ter estilo acinzentado sem comunicar corretamente seu estado, e uma interface pode usar um componente personalizado. Quando o agente tiver acesso à estrutura da página, ele pode examinar propriedades e mensagens. Quando depender de visão, precisará de sinais visuais suficientes e verificáveis.
Nos dois casos, a regra de encerramento deve apontar para o resultado da tarefa. “O botão ficou cinza” descreve uma observação. “O orçamento foi criado com o identificador esperado” descreve um efeito que pode ser conferido. Registre essas duas informações separadamente, sem transformar a primeira em prova da segunda.
Modele estados da tarefa antes de automatizar
Uma forma prática de organizar o fluxo é usar estados explícitos: preparado, aguardando resposta, concluído, recusado e inconclusivo. São categorias operacionais propostas para sua equipe, não estados universais de qualquer aplicativo. Cada uma precisa de um critério observável.
Preparado significa que os dados e a autorização foram conferidos. Aguardando resposta significa que a ação foi iniciada e ainda falta observar o efeito. Concluído exige evidência do resultado correto. Recusado exige uma indicação de falha ou impedimento. Inconclusivo descreve uma tentativa cujo resultado não pôde ser determinado com os sinais disponíveis.
| Sinal observado | O que permite afirmar | Próxima conferência |
|---|---|---|
| Botão desabilitado antes do envio | Controle indisponível | Campos, permissões e instruções da tela |
| Indicador de processamento | Interface informa atividade | Resultado ou erro associado à operação |
| Botão habilitado novamente | Ação voltou a ficar disponível | Se houve conclusão, recusa ou apenas reinício |
| Registro com identificador confirmado | Efeito localizado | Conteúdo, conta e estado final desse registro |
| Tempo de espera esgotado | Verificação não terminou no prazo | Histórico antes de qualquer repetição |
Associe a transição ao mesmo item. Uma mensagem de sucesso de uma operação anterior pode continuar visível. Antes de iniciar, registre o contexto relevante; depois procure a confirmação da tentativa atual. Se o serviço fornece um identificador, use-o para ligar a execução ao resultado consultado.
A autorização também faz parte desse contrato. Corrigir dados de um formulário não autoriza mudar permissões da conta para liberar o botão. O roteiro de permissões de agentes de IA ajuda a separar o que o agente pode observar do que pode alterar.
Use sinais da interface sem atribuir significado excessivo
O atributo de acessibilidade aria-busy indica que um elemento está sendo modificado. A especificação WAI-ARIA explica que tecnologias assistivas podem aguardar o fim dessas mudanças antes de apresentá-las. Isso pode ajudar a reconhecer uma região em atualização, quando a aplicação implementa o atributo corretamente.
O valor falso desse atributo não é um certificado de sucesso comercial. Ele se refere à atualização do elemento. Uma região pode parar de mudar depois de exibir um erro. Por isso, combine esse sinal com uma mensagem final e com a verificação do objeto que a tarefa pretendia produzir.
Para um agente visual, procure texto descritivo junto ao indicador de atividade. “Preparando arquivo”, “enviando” e “concluído” têm papéis diferentes no roteiro. Se o aplicativo mostrar apenas uma animação sem informação suficiente, registre essa limitação e defina uma conferência alternativa, como abrir o histórico permitido.
Para quem desenvolve a interface, forneça estados com nomes claros e uma confirmação vinculada ao item. Evite que o único sinal seja mudança de cor. Um resultado identificável atende melhor pessoas, tecnologias assistivas e automações. Mesmo assim, avalie se a mensagem corresponde ao efeito persistido no sistema.
Quando a tarefa depender de aprovação, diferencie processamento de espera por uma pessoa. Uma solicitação pode ter sido enviada corretamente e continuar pendente por decisão humana. O desenho de uma fila de aprovações para tarefas de IA ajuda a representar esse outro tipo de espera sem declarar a aprovação como obtida.
Espere pela condição certa e trate o prazo
O Playwright realiza verificações antes de ações, incluindo, para um clique, visibilidade, estabilidade, recebimento de eventos e habilitação. Essa espera automática ajuda a executar a interação. Ela não substitui a verificação de que a tarefa de negócio terminou depois do clique.
Em uma automação de teste, use verificações posteriores ligadas ao resultado. A documentação de assertions do Playwright descreve verificações que voltam a consultar o elemento até que a condição esperada ocorra ou o prazo termine. A condição pode ser um texto de confirmação ou outra propriedade do elemento, desde que represente o resultado que se deseja testar.
Separe os dois momentos no roteiro: antes, a ação deve estar disponível; depois, o efeito esperado deve ser comprovado. Não reutilize “botão habilitado” como único teste dos dois momentos. Um formulário pode liberar o envio novamente após rejeitar a primeira tentativa.
Defina um prazo de observação compatível com o processo e uma ação ao esgotá-lo. Não há um tempo universal adequado para toda ferramenta. Use comportamento observado no ambiente de teste e as instruções do serviço. Ao atingir o limite, registre a tentativa como inconclusiva e procure seu resultado antes de considerar nova execução.
Se a interface não oferecer histórico ou outro meio autorizado de verificação, entregue a pendência com evidências suficientes para uma pessoa revisar. Não remova um atributo de desabilitação para forçar o caminho. Uma restrição de interface pode representar uma condição real que ainda não foi satisfeita.
Exemplo: locadora de equipamentos em Recife
Considere um exemplo ilustrativo de uma locadora de equipamentos em Recife. Um agente deve registrar uma reserva interna a partir de dados aprovados. Ele pode preencher e enviar a solicitação, mas não pode alterar estoque nem confirmar uma retirada sem a etapa prevista pela equipe.
A responsável define a evidência de conclusão: uma reserva com identificador, nome do equipamento e período correto, localizada na conta da empresa. O botão indisponível após o envio será interpretado apenas como sinal intermediário. Uma mensagem de erro ou uma reserva com dados diferentes não atende ao critério.
No teste, o agente preenche o formulário e inicia o envio. O botão fica desabilitado e a tela mostra processamento. Nesse ponto, ele registra espera. Se surgir uma mensagem de confirmação, consulta a reserva e compara equipamento e período. Só então informa que o registro foi criado.
Em outro cenário do ensaio, a tela permanece sem confirmação até o prazo combinado. O agente consulta a lista de reservas antes de repetir. Se encontrar o registro correto, encerra com a referência desse item. Se encontrar uma rejeição, relata o motivo exibido. Se não conseguir estabelecer o que ocorreu, entrega resultado inconclusivo e preserva os dados da tentativa.
Inclua também um teste em que o formulário volta a habilitar o botão após mostrar um erro de preenchimento. O agente deve reconhecer que disponibilidade renovada não significa sucesso anterior. Ele corrige somente o que está autorizado e mantém a rejeição no histórico do teste.
Não se atribui ganho numérico a esse exemplo. A utilidade do exercício é verificar se o agente acompanha a transição de estados e sabe interromper uma repetição arriscada. Se uma ferramenta falhar reiteradamente, o procedimento de interrupção de falhas repetidas em agentes oferece um complemento para o controle operacional.
Erros comuns
Declarar sucesso quando a animação desaparece. O fim da animação pode acompanhar uma mensagem de erro ou uma atualização parcial. Leia o estado final e confira o objeto produzido. Registre a ausência de evidência quando o resultado não estiver disponível.
Repetir o clique para acelerar. Uma solicitação pode continuar em processamento mesmo sem resposta clara na tela. Procure o resultado da primeira tentativa. Repetição deve ser uma decisão baseada no estado observado e na autorização, não uma reação automática à demora.
Usar apenas uma captura de tela. Uma captura pode documentar um momento intermediário. Para avaliar o fluxo, registre o contexto anterior, a ação e o estado posterior associado ao item. Preserve somente as informações necessárias à investigação e evite dados pessoais nos exemplos de teste.
Confundir bloqueio com trabalho em andamento. Um campo obrigatório vazio ou uma permissão insuficiente pode impedir o início da operação. Confira a mensagem e os requisitos da tela antes de iniciar uma espera que nunca resolverá essa condição.
Alterar o controle para contornar a aplicação. Retirar a desabilitação ou forçar uma interação não comprova que os requisitos foram atendidos. Mantenha o teste alinhado ao caminho autorizado e investigue o impedimento. O objetivo é executar uma tarefa válida, não apenas produzir um evento de clique.
Esconder resultados inconclusivos. Inclua no relatório a última observação e a consulta necessária para resolver a dúvida. Isso permite uma continuidade segura sem tratar uma hipótese como registro confirmado.
Perguntas frequentes
Botão cinza significa que o agente terminou?
Não. É uma observação sobre a interface. O procedimento deve exigir evidência do resultado esperado, como o documento salvo ou o registro correto. A cor não explica se houve espera, recusa, falta de permissão ou conclusão.
É suficiente esperar o botão habilitar novamente?
Não para comprovar sucesso. Ele pode voltar a ficar disponível depois de um erro. Confira a mensagem final e o efeito da tentativa atual. O sinal de disponibilidade serve para orientar uma ação, não para certificar a anterior.
O que aria-busy informa ao agente?
Informa que um elemento está sendo atualizado, quando implementado pela aplicação. É um sinal relacionado à apresentação acessível do conteúdo. Combine-o com informações da tarefa; não o trate como um status universal de processamento no servidor.
O Playwright já espera a tarefa acabar?
Ele oferece espera automática para condições das ações e verificações que podem repetir consultas. Cabe a quem escreve o fluxo escolher uma condição posterior que comprove a tarefa. Esperar a possibilidade de clicar e esperar a confirmação são verificações diferentes.
O que fazer quando o prazo de espera termina?
Registre o que foi tentado e consulte o estado do item por um caminho permitido. Se não houver evidência suficiente, mantenha o resultado inconclusivo e encaminhe a revisão. Não considere a demora uma autorização automática para reenviar.
