Além dos testes individuais: o próximo nível do QA automatizado
Garantir qualidade em produção vai muito além de executar testes isolados. Equipes de engenharia precisam organizar casos de teste em suítes de regressão, executá-los em lote e integrá-los a pipelines de Integração Contínua e Entrega Contínua (CI/CD) para que os resultados controlem automaticamente o avanço de deploys.
Em um post anterior, a AWS apresentou o QA Studio, uma solução de referência para automação de garantia de qualidade (QA) baseada em agentes, construída com o Amazon Nova Act. Naquela primeira parte, o foco foi em como definir casos de uso individuais em linguagem natural, executá-los sob demanda com navegação visual assistida por IA e inspecionar os artefatos de execução com visibilidade completa da trajetória.
Agora, nesta segunda parte, a AWS expande essa base para mostrar como o QA Studio resolve dois desafios centrais: a execução em lote com suítes de regressão e a integração com pipelines CI/CD por meio de uma interface de linha de comando (CLI).
Suítes de teste para regressão organizada
Com o QA Studio, é possível agrupar casos de uso individuais — cada um validando uma jornada específica do usuário — em coleções chamadas de suítes de teste, que são executadas em conjunto. Essas suítes suportam testes de regressão estruturados por áreas funcionais.
A execução das suítes acontece em lote com processamento paralelo: cada caso de uso roda de forma independente em sua própria tarefa worker no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate. Isso significa que uma suíte com 20 testes pode ser executada de forma simultânea, em vez de sequencial, reduzindo significativamente o tempo total de execução.
As suítes podem ser organizadas por área funcional, estágio de release ou propósito de teste. Exemplos práticos incluem:
- Smoke tests: validam os caminhos críticos a cada deploy
- Suítes de regressão: cobrem toda a aplicação
- Testes de integração: verificam fluxos entre funcionalidades antes de um release
Criando e gerenciando suítes
A criação de suítes é feita pela interface web do QA Studio: basta fornecer nome, descrição e tags opcionais, e então adicionar os casos de uso existentes à suíte. Cada caso de uso mantém sua própria configuração — URL de início, variáveis, segredos e cabeçalhos — e essas configurações são aplicadas de forma independente durante a execução da suíte.
Execução e resultados
Quando uma suíte é executada, o QA Studio cria registros individuais de execução para cada caso de uso e os despacha para a fila de workers. A página de execução da suíte oferece uma visão agregada: quantos casos passaram, falharam ou ainda estão em andamento. É possível detalhar os resultados individuais para revisar logs de trajetória, capturas de tela e gravações de sessão de qualquer teste que tenha falhado.
Cada suíte mantém seu próprio histórico de execuções, oferecendo uma visão longitudinal da estabilidade da regressão. Aprovações consistentes constroem confiança na funcionalidade testada, enquanto falhas intermitentes indicam áreas que precisam de atenção.
Integração CI/CD com a CLI do QA Studio
A interface web do QA Studio funciona bem para criação interativa de testes e execução sob demanda. Mas pipelines de CI/CD exigem uma abordagem diferente: execução por linha de comando, saída estruturada, autenticação não interativa e códigos de saída que se integrem com os orquestradores de pipeline.
A CLI do QA Studio (qa-studio) preenche exatamente essa lacuna. Ela se conecta ao mesmo backend de API da aplicação web, mas em vez de despachar testes para workers no Fargate, executa-os com o Amazon Nova Act diretamente na máquina onde a CLI roda — como um runner de CI/CD. Os resultados são reportados de volta para o deploy do QA Studio.
Instalação e autenticação
A CLI do QA Studio faz parte do repositório do projeto no GitHub. Após clonar o repositório, instale a CLI como pacote Python com suas dependências opcionais de runner:
pip install -e "./qa-studio-cli[runner]"
Para ambientes de CI/CD, a CLI suporta autenticação por credenciais de cliente OAuth 2.0. Você cria um cliente OAuth na interface web do QA Studio com os escopos necessários (api/suite.read, api/suite.write, api/executions.read, api/executions.write, api/usecases.read, api/usecases.execute), e então configura as credenciais como variáveis de ambiente do pipeline:
export OAUTH_CLIENT_ID="your-client-id"
export OAUTH_CLIENT_SECRET="your-client-secret"
export OAUTH_TOKEN_ENDPOINT="https://your-cognito-domain.auth.region.amazoncognito.com/oauth2/token"
A CLI solicita e armazena em cache os tokens de acesso automaticamente, renovando-os quando expiram. Nenhum login interativo via navegador é necessário.
Executando testes e suítes
O comando qa-studio run executa casos de uso individuais ou suítes inteiras:
# Run a single test
qa-studio run --usecase-id test-123
# Run a test suite
qa-studio run --suite-id suite-456
Sobrescrita de ambiente e variáveis
Pipelines de CI/CD frequentemente precisam rodar os mesmos testes contra ambientes diferentes. A CLI oferece mecanismos de sobrescrita que modificam o comportamento dos testes sem alterar as definições armazenadas no QA Studio.
A flag --base-url substitui o domínio da URL de início, preservando o caminho e os parâmetros de query. Um único teste pode então apontar para desenvolvimento, staging ou produção:
# Run against staging
qa-studio run --suite-id suite-456 --base-url https://staging.example.com
# Run against production
qa-studio run --suite-id suite-456 --base-url https://production.example.com
A flag --var sobrescreve variáveis de template definidas no caso de uso. Variáveis referenciadas nos passos de teste com a sintaxe {{NomeDaVariavel}} são substituídas em tempo de execução, permitindo configurações específicas por ambiente sem duplicar definições de teste:
# Override credentials for a specific environment
qa-studio run --usecase-id test-123 \
--var username=staging_user \
--var password=staging_pass \
--var api_key=staging_key_123
A flag --region controla em qual Região da AWS o navegador será executado, e --model-id seleciona a versão do modelo Amazon Nova Act:
qa-studio run --usecase-id test-123 \
--region eu-central-1 \
--model-id nova-act-v1.0
Cabeçalhos e segredos
Casos de uso podem definir cabeçalhos HTTP personalizados enviados em cada requisição durante a execução do teste — úteis para tokens de autenticação, feature flags ou identificadores personalizados que a aplicação testada exige. Os cabeçalhos são configurados nas definições do caso de uso e aplicados automaticamente tanto na interface web quanto na CLI.
Segredos oferecem armazenamento seguro para valores sensíveis como senhas, chaves de API ou tokens. Os segredos são armazenados no AWS Secrets Manager, criptografados em repouso. O QA Studio é projetado para que os valores dos segredos não sejam gravados em logs ou registros de execução. Os passos de teste referenciam segredos pelo nome, e os valores reais são recuperados em tempo de execução. Essa separação permite que pipelines de CI/CD executem testes que exigem credenciais sem expô-las nas configurações ou logs do pipeline.
Códigos de saída e integração com pipelines
A CLI utiliza códigos de saída que mapeiam diretamente para estados de sucesso e falha nos pipelines:
- Código 0: todos os testes passaram → pipeline continua
- Código 1: um ou mais testes falharam → pipeline falha (falha de teste)
- Código 2: erro da CLI (autenticação, configuração, API) → pipeline falha (erro de infraestrutura)
Esse modelo de três estados permite que pipelines distingam entre falhas de teste (código 1) e problemas de infraestrutura (código 2), possibilitando estratégias diferentes de notificação ou retry para cada caso.
A flag --format controla a formatação da saída. O formato padrão json oferece saída estruturada para consumo programático. O formato human fornece um resumo legível para logs de pipeline:
qa-studio run --suite-id suite-456 --format human
Durante a execução, a CLI cria registros no QA Studio, atualiza os status dos passos em tempo real e faz upload de artefatos, incluindo logs de trajetória e gravações de sessão. É possível monitorar execuções disparadas pela CLI pela interface web junto com execuções manuais, mantendo um histórico unificado independentemente de como os testes foram iniciados.
Exemplos de integração com plataformas CI/CD
A AWS apresenta exemplos de integração do QA Studio com as principais ferramentas de CI/CD do mercado. Em todos os casos, assume-se que as credenciais OAuth do cliente e as credenciais AWS estão armazenadas como segredos do pipeline.
GitHub Actions
name: QA Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
smoke-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install QA Studio CLI
run: pip install -e "./qa-studio-cli[runner]"
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- name: Run Smoke Tests
env:
OAUTH_CLIENT_ID: ${{ secrets.OAUTH_CLIENT_ID }}
OAUTH_CLIENT_SECRET: ${{ secrets.OAUTH_CLIENT_SECRET }}
OAUTH_TOKEN_ENDPOINT: ${{ secrets.OAUTH_TOKEN_ENDPOINT }}
run: |
qa-studio run \
--suite-id ${{ vars.SMOKE_TEST_SUITE_ID }} \
--base-url https://staging.example.com \
--format human
- name: Upload Artifacts
if: always()
uses: actions/upload-artifact@v3
with:
name: test-artifacts
path: ~/.qa-studio/artifacts/
A condição if: always() no passo de upload de artefatos garante que gravações e logs sejam preservados mesmo quando os testes falham, fornecendo o contexto de depuração necessário para investigar as falhas.
GitLab CI
stages:
- test
smoke-tests:
stage: test
image: python:3.11
before_script:
- pip install -e "./qa-studio-cli[runner]"
script:
- |
qa-studio run \
--suite-id $SMOKE_TEST_SUITE_ID \
--base-url https://staging.example.com \
--format human
variables:
AWS_DEFAULT_REGION: us-east-1
artifacts:
when: always
paths:
- ~/.qa-studio/artifacts/
expire_in: 7 days
only:
- main
- merge_requests
regression-tests:
stage: test
image: python:3.11
before_script:
- pip install -e "./qa-studio-cli[runner]"
script:
- |
qa-studio run \
--suite-id $REGRESSION_SUITE_ID \
--timeout 7200 \
--format human
variables:
AWS_DEFAULT_REGION: us-east-1
artifacts:
when: always
paths:
- ~/.qa-studio/artifacts/
expire_in: 7 days
only:
- schedules
As variáveis do GitLab CI (OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, OAUTH_TOKEN_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) devem ser configuradas como variáveis de CI/CD protegidas e mascaradas nas configurações do projeto. O job regression-tests usa o gatilho de agendamento do GitLab, rodando apenas quando acionado por um schedule de pipeline, e não por um push de código.
Jenkins
pipeline {
agent any
environment {
AWS_DEFAULT_REGION = 'us-east-1'
}
stages {
stage('Setup') {
steps {
sh '''
python3.11 -m venv venv
. venv/bin/activate
pip install -e "./qa-studio-cli[runner]"
'''
}
}
stage('Smoke Tests') {
steps {
withCredentials([
string(credentialsId: 'oauth-client-id', variable: 'OAUTH_CLIENT_ID'),
string(credentialsId: 'oauth-client-secret', variable: 'OAUTH_CLIENT_SECRET'),
string(credentialsId: 'oauth-token-endpoint', variable: 'OAUTH_TOKEN_ENDPOINT'),
string(credentialsId: 'aws-access-key-id', variable: 'AWS_ACCESS_KEY_ID'),
string(credentialsId: 'aws-secret-access-key', variable: 'AWS_SECRET_ACCESS_KEY')
]) {
sh '''
. venv/bin/activate
qa-studio run \
--suite-id ${SMOKE_TEST_SUITE_ID} \
--base-url https://staging.example.com \
--format human
'''
}
}
}
}
post {
always {
archiveArtifacts artifacts: '~/.qa-studio/artifacts/**/*', allowEmptyArchive: true
}
}
}
No Jenkins, o bloco withCredentials injeta os segredos no ambiente de build sem expô-los na saída do console. O bloco post.always arquiva os artefatos de teste independentemente do resultado do build.
O que isso representa para equipes de engenharia
As suítes de teste e a integração com CI/CD transformam o QA Studio de uma ferramenta interativa de criação de testes em uma plataforma de garantia de qualidade contínua. As suítes organizam a cobertura de regressão em coleções gerenciáveis com execução paralela. A CLI traz a execução de testes baseada em agentes para pipelines automatizados, com sobrescrita de ambiente, gerenciamento seguro de credenciais e códigos de saída que se mapeiam para estados de sucesso e falha nos pipelines.
Essas capacidades se constroem sobre a base descrita no post anterior: definições de teste em linguagem natural, navegação visual com IA e visibilidade completa da trajetória de ponta a ponta. Juntas, demonstram como a automação de QA com agentes usando o Amazon Nova Act pode se integrar aos fluxos de entrega de software existentes, fornecendo feedback automatizado de qualidade sem exigir que as equipes mantenham código de teste específico de frameworks.
A AWS indica que um próximo post explorará como a automação de testes com agentes pode se estender a aplicações móveis. A solução de referência do QA Studio, incluindo suítes de teste e integração com CLI, está disponível no GitHub. Para instruções de deploy e documentação detalhada, consulte o README do projeto.
Fonte
Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 2 (https://aws.amazon.com/blogs/machine-learning/accelerating-software-delivery-with-agentic-qa-automation-using-amazon-nova-act-part-2/)
