AWS Adds Team Controls to QA Studio

AWS published the third installment of its QA Studio guide on October 28, 2026, describing how the Amazon Nova Act reference solution adds application health metrics and team-based access controls for organizations scaling automated software testing. Applications group use cases and test suites under one owner, so teams can manage their own tests instead of sorting through a shared, flat list. Each application is configured with a name, base URL and optional development, staging and production environments.

QA Studio records every test execution as an Amazon CloudWatch custom metric, labeled by application and environment. Its application page shows pass rate for a selected period, total executions and current failures, plus a health score from 0–100 that starts with pass rate and subtracts a penalty for flaky tests that alternate between passing and failing. A metrics view charts executions, successes, failures and average duration over either 7 days at hourly intervals or 30 days at daily intervals; users can filter by environment to compare, for example, staging and production.

A flaky-tests view ranks use cases by how often they switched between passing and failing over the last seven days. A recent-failures list links each failed run to Amazon Nova Act trajectory logs and session recordings, allowing teams to inspect what the agent encountered.

Access is organized by teams, and each application belongs to exactly one team. QA Studio defines five roles with cumulative permissions: Admin has studio-wide access to teams, applications and users and can create teams and assign applications; Team Lead manages team members and creates applications; Editor creates and edits use cases and test suites; Executor runs tests without modifying them; Viewer has read-only access to applications and results. Access to tests follows their application, so permissions can be managed at that level rather than across thousands of individual tests.

In the reference deployment, four users span two teams: two Team Leads, one Viewer and one studio-wide Administrator. Administrators can review users, roles, teams and application counts across the studio. Team Leads manage members, applications, use cases and sharing for their own team, including changing member roles and granting, revoking or changing another team’s access to an application. Sharing can be view, execute or full access; a recipient’s effective permission is limited to the lower of the grant and their own role. For example, an Editor on a team given view access remains read-only on the shared application.

The solution uses Amazon Cognito groups for team roles and an AWS Lambda authorizer to translate group membership into API scopes and team context. Amazon DynamoDB stores teams, memberships, application ownership and share grants. Amazon CloudWatch stores execution metrics in the QAStudio/Executions namespace, labeled by application and environment. AWS Lambda and Amazon API Gateway enforce role scopes and check whether a caller’s team owns or has access to an application. CI pipelines can authenticate through the OAuth client credentials flow as machine identities with only the required scopes.

AWS offers QA Studio as a reference solution deployed in the customer’s AWS account using the AWS Cloud Development Kit (AWS CDK); test data, results and metrics remain within that account. After deployment, an administrator creates teams, assigns members and roles, and assigns applications. Metrics populate as tests run. AWS directs users to the QA Studio GitHub repository for deployment instructions and configuration details. The third installment builds on natural-language test authoring from Part 1 and test suites and CI/CD integration from Part 2.

AWS published the third installment of its QA Studio guide on October 28, 2026, describing how the Amazon Nova Act reference solution adds application health metrics and team-based access controls for organizations scaling automated software testing. Applications group use cases and test suites under one owner, so teams can manage their own tests instead of sorting through a shared, flat list. Each application is configured with a name, base URL and optional development, staging and production environments.

QA Studio records every test execution as an Amazon CloudWatch custom metric, labeled by application and environment. Its application page shows pass rate for a selected period, total executions and current failures, plus a health score from 0–100 that starts with pass rate and subtracts a penalty for flaky tests that alternate between passing and failing. A metrics view charts executions, successes, failures and average duration over either 7 days at hourly intervals or 30 days at daily intervals; users can filter by environment to compare, for example, staging and production.

A flaky-tests view ranks use cases by how often they switched between passing and failing over the last seven days. A recent-failures list links each failed run to Amazon Nova Act trajectory logs and session recordings, allowing teams to inspect what the agent encountered.

Access is organized by teams, and each application belongs to exactly one team. QA Studio defines five roles with cumulative permissions: Admin has studio-wide access to teams, applications and users and can create teams and assign applications; Team Lead manages team members and creates applications; Editor creates and edits use cases and test suites; Executor runs tests without modifying them; Viewer has read-only access to applications and results. Access to tests follows their application, so permissions can be managed at that level rather than across thousands of individual tests.

In the reference deployment, four users span two teams: two Team Leads, one Viewer and one studio-wide Administrator. Administrators can review users, roles, teams and application counts across the studio. Team Leads manage members, applications, use cases and sharing for their own team, including changing member roles and granting, revoking or changing another team’s access to an application. Sharing can be view, execute or full access; a recipient’s effective permission is limited to the lower of the grant and their own role. For example, an Editor on a team given view access remains read-only on the shared application.

The solution uses Amazon Cognito groups for team roles and an AWS Lambda authorizer to translate group membership into API scopes and team context. Amazon DynamoDB stores teams, memberships, application ownership and share grants. Amazon CloudWatch stores execution metrics in the QAStudio/Executions namespace, labeled by application and environment. AWS Lambda and Amazon API Gateway enforce role scopes and check whether a caller’s team owns or has access to an application. CI pipelines can authenticate through the OAuth client credentials flow as machine identities with only the required scopes.

AWS offers QA Studio as a reference solution deployed in the customer’s AWS account using the AWS Cloud Development Kit (AWS CDK); test data, results and metrics remain within that account. After deployment, an administrator creates teams, assigns members and roles, and assigns applications. Metrics populate as tests run. AWS directs users to the QA Studio GitHub repository for deployment instructions and configuration details. The third installment builds on natural-language test authoring from Part 1 and test suites and CI/CD integration from Part 2.