O problema que aparece quando a automação de QA cresce
Quando a automação de Garantia de Qualidade (QA) começa a se expandir dentro de uma organização, um novo desafio surge — e ele não tem nada a ver com escrever testes. Um time de plataforma sobe a infraestrutura de automação, um segundo time quer aderir, depois mais uma dúzia. Em pouco tempo, centenas de casos de teste pertencem a produtos e squads diferentes, todos visíveis para todos. E ninguém consegue responder, de relance, a uma pergunta simples: a cobertura de testes desta aplicação está saudável agora?
Escrever testes deixa de ser o gargalo. Organizar testes e controlar quem pode alterá-los passa a ser o trabalho real. Uma segunda questão surge logo na sequência: quem é o dono desta aplicação e seus testes, e quem responde quando a cobertura cai? Sem um responsável claro, os problemas de saúde não têm para onde ir.
A AWS publicou a terceira parte da série sobre o QA Studio, solução de referência construída com o Amazon Nova Act. Na primeira parte, o QA Studio foi apresentado como uma ferramenta que permite definir testes em linguagem natural e executá-los por meio de navegação visual com IA. Na segunda parte, foram adicionados suítes de testes e uma Interface de Linha de Comando (CLI) para regressão em lote em pipelines de Integração Contínua e Entrega Contínua (CI/CD). Nesta terceira parte, o foco está em duas capacidades que ajudam o QA Studio a escalar por toda uma organização: aplicações e gerenciamento de usuários por times.
Organizando testes com Aplicações
No QA Studio, uma aplicação representa o sistema em teste: um site, um aplicativo web, um front-end de serviço. É o contêiner que dá um lar e um dono a uma coleção de testes. Os casos de uso (testes individuais da Parte 1) e as suítes de testes (coleções de regressão da Parte 2) pertencem a uma aplicação e herdam sua propriedade.
Em vez de uma lista plana com todos os testes do ambiente, cada time trabalha dentro das aplicações que possui. Criar uma aplicação exige um nome, uma URL base e um conjunto opcional de ambientes — como desenvolvimento, homologação e produção. A partir da página da aplicação, os times criam novos casos de uso diretamente no contexto, adicionam casos existentes e os agrupam em suítes de testes.
Entendendo a saúde das aplicações com métricas
Testes produzem resultados. Entender esses resultados ao longo do tempo é o que diz a um time se o ciclo de desenvolvimento de uma aplicação está saudável — e não apenas se um build específico está pronto para ir a produção.
O QA Studio registra o resultado de cada execução como métricas customizadas no Amazon CloudWatch, dimensionadas por aplicação e por ambiente. Essas métricas alimentam uma visão de saúde na página da aplicação. O topo da página responde à pergunta imediata com três números: a taxa de aprovação no período selecionado, o total de execuções e a contagem atual de falhas.
Junto a esses números, o QA Studio calcula um health score (pontuação de saúde) de 0 a 100. A pontuação parte da taxa de aprovação e desconta uma penalidade por testes instáveis — aqueles que alternam entre aprovado e reprovado de forma intermitente. Assim, uma aplicação cujos testes passam mas oscilam não apresenta uma imagem falsamente perfeita. Um time que analisa um portfólio de aplicações consegue identificar as estáveis e as que precisam de atenção sem precisar abrir cada resultado individualmente.
A aba de métricas vai além do snapshot atual e mostra tendências. Os times escolhem uma janela de 7 dias com granularidade horária ou uma janela de 30 dias com granularidade diária. O QA Studio exibe gráficos de execuções, sucessos, falhas e duração média nesse período. Como as métricas carregam a dimensão de ambiente, é possível filtrar a visão para um único ambiente — por exemplo, comparar o comportamento da homologação com o de produção para o mesmo conjunto de testes.
Duas visões específicas miram nos testes que mais custam tempo aos times:
- Testes instáveis (flaky tests): classifica os casos de uso pela frequência com que alternaram entre aprovado e reprovado nos últimos sete dias, revelando falhas intermitentes que corroem a confiança na suíte antes de virar um problema em produção.
- Falhas recentes: lista as últimas execuções com falha para triagem rápida. Cada item leva diretamente aos logs de trajetória do Amazon Nova Act e às gravações de sessão descritos na Parte 1 — ou seja, sair de “este teste está falhando” para “aqui está exatamente o que o agente viu” é questão de um clique.
Controlando o acesso com times e papéis
Métricas dizem a um time como suas aplicações estão indo. O gerenciamento de usuários por times decide quais aplicações são deles para começo de conversa.
O QA Studio organiza o acesso em torno de times, e uma aplicação pertence a exatamente um time. Os membros daquele time trabalham com suas aplicações; todos os outros não as enxergam. Cada membro do time ocupa um dos cinco papéis, e cada papel inclui as permissões dos papéis abaixo dele na hierarquia:
- Admin: acesso amplo a todos os times, aplicações e usuários do estúdio, incluindo criação de times e atribuição de aplicações. É um papel de nível de estúdio, não por time.
- Team Lead (Líder de Time): gerencia os membros do próprio time e cria aplicações para o time.
- Editor: cria e edita casos de uso e suítes de testes dentro das aplicações do time.
- Executor: executa casos de uso e suítes, mas não os modifica.
- Viewer (Visualizador): acesso somente leitura às aplicações e resultados do time.
Como os papéis são cumulativos, um Team Lead tem tudo que um Editor tem, e assim por diante até o Viewer. O acesso a um caso de uso ou suíte de testes segue a aplicação que o contém — se um membro pode trabalhar com a aplicação, pode trabalhar com seus testes, dentro dos limites do seu papel. Isso mantém o gerenciamento de permissões no nível da aplicação, e não em milhares de testes individuais.
Um administrador enxerga o estúdio inteiro. A página de usuários lista todas as contas com seus times e papéis em um só lugar. A página de times apresenta os mesmos dados agrupados por time, mostrando a contagem de membros e aplicações lado a lado — o que permite identificar quais times estão crescendo antes mesmo de abrir qualquer um deles.
Compartilhando aplicações entre times
Times raramente trabalham em isolamento completo. Um time de plataforma pode ser dono de uma aplicação que um time de funcionalidade precisa executar testes — sem precisar transferir a capacidade de modificá-la.
O QA Studio suporta isso com acesso compartilhado: o time proprietário concede a outro time acesso a uma aplicação em nível de visualização, execução ou acesso completo. O acesso compartilhado segue uma regra de teto: a permissão efetiva de um usuário em uma aplicação compartilhada é o menor valor entre o seu próprio papel e o nível do compartilhamento concedido. Um Viewer que recebe acesso completo a uma aplicação compartilhada permanece somente leitura, porque o seu papel é o teto. Assim, um time proprietário pode compartilhar amplamente sem conceder mais do que o papel do destinatário permite.
O que um Team Lead visualiza
Um Team Lead trabalha dentro de um único time, não do estúdio inteiro. A visão “Meu Time” apresenta quatro abas que cobrem tudo que o líder controla: Membros, Aplicações, Casos de Uso e Acesso Compartilhado.
A aba de Membros lista as pessoas do time. O líder pode alterar o papel de qualquer membro diretamente ou adicionar novos, mantendo o gerenciamento de acesso do dia a dia com quem está mais próximo do trabalho.
A aba de Aplicações mostra apenas as aplicações que o time possui, cada uma com a contagem de casos de teste e o horário da última execução — mantendo o líder focado na sua própria superfície, não no inventário completo do estúdio.
A aba de Acesso Compartilhado é onde o compartilhamento entre times se concretiza. É possível conceder, revogar ou alterar o nível de acesso que outros times têm sobre as aplicações do time. A regra de teto descrita anteriormente se aplica na prática: um Editor do time convidado que recebeu acesso no nível de visualização ainda vê a aplicação compartilhada como somente leitura.
Como funciona por baixo dos panos
O QA Studio constrói o controle de acesso por times e as métricas sobre a mesma base serverless descrita nas partes anteriores, adicionando alguns serviços AWS ao mix:
- Amazon Cognito: cada time é mapeado para um conjunto de grupos do Cognito, um por papel. Um autorizador do AWS Lambda resolve os grupos de um chamador em escopos de API e contexto de time a cada requisição.
- Amazon DynamoDB: times, membros, propriedade de aplicações e concessões de compartilhamento entre times são armazenados no design de tabela única já existente.
- Amazon CloudWatch: cada execução emite métricas customizadas no namespace
QAStudio/Executions, dimensionadas por aplicação e ambiente. A API de métricas as lê para construir a visão de saúde e os gráficos de tendência. - AWS Lambda e Amazon API Gateway: o backend aplica o controle de acesso em duas camadas — o escopo que o papel do chamador concede e uma verificação de recurso que confirma se o time do chamador é dono ou tem compartilhamento com a aplicação.
Como o acesso é derivado da associação a grupos do Cognito, o fluxo de credenciais de cliente OAuth da Parte 2 se encaixa no mesmo modelo. Um pipeline de CI/CD se autentica como uma identidade de máquina com os escopos que precisa — e nada além disso.
Como começar
Aplicações, métricas e controle de acesso por times fazem parte da solução de referência do QA Studio, que é implantada na própria conta AWS do usuário com o AWS Kit de Desenvolvimento em Nuvem (AWS CDK). Todos os dados de teste, resultados e métricas permanecem dentro dos limites da conta.
Após a implantação, um administrador cria times, atribui membros e papéis, e associa aplicações aos times. As métricas de saúde de cada time começam a ser preenchidas conforme os testes são executados. Para instruções de implantação e detalhes de configuração, consulte o repositório GitHub do QA Studio.
Conclusão
Esta terceira parte da série mostra como o QA Studio escala a automação de QA com agentes de IA — de testes individuais para uma organização inteira. As aplicações dão a cada time um lar para seus casos de uso e suítes de testes. Elas reportam saúde por meio de taxa de aprovação, gráficos de tendência, pontuação de saúde ajustada por instabilidade e triagem de falhas construída sobre métricas do Amazon CloudWatch. O gerenciamento de usuários por times, sustentado pelo Amazon Cognito, mantém cada equipe trabalhando dentro das aplicações que possui, com compartilhamento entre times limitado por uma regra de teto clara.
Essas capacidades se somam à autoria de testes em linguagem natural da Parte 1 e às suítes e integração com CI/CD da Parte 2. Juntas, elas permitem que a automação de QA cresça por muitos times sem perder visibilidade nem controle. Para experimentar no seu próprio ambiente, implante a solução de referência a partir do repositório GitHub do QA Studio e execute alguns casos de uso para ver as métricas tomando forma. Para saber mais sobre o agente por trás de tudo isso, acesse a página do Amazon Nova Act.
Fonte
Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 3 (https://aws.amazon.com/blogs/machine-learning/accelerating-software-delivery-with-agentic-qa-automation-using-amazon-nova-act-part-3/)
Leave a Reply