TCS builds AWS-based agentic test orchestrator for BFSI clients

A workflow designed for financial services testing

TCS says the slowest part of a release is often the work after application code is written. Teams still need to interpret requirements, design scenarios, create and maintain automation, prepare execution environments, investigate failures, and assemble evidence for review.

The objective was not to replace quality engineers. Instead, the orchestrator is intended to reduce repetitive translation and execution work, allowing engineers to spend more time on risk analysis, exploratory testing, and release decisions.

TCS identified four requirements for the platform. Tests had to use project-specific context, support both API and browser-based UI testing, isolate every tenant’s data and knowledge store, and provide a repeatable path from requirement ingestion to test evidence and reporting.

Specialized agents replace a single generative prompt

TCS already used traditional test automation, but that approach did not remove the work of creating scenarios, converting them into scripts, maintaining locators and dependencies, or diagnosing failures. Scripts could also become stale when a linked user story changed.

The Agentic Test Orchestrator divides the workflow into specialized tasks. Each task has its own agent, tools, validation rules, and context. A deterministic supervisor routes work, while an execution workflow manages retries, error classification, persistence, and reporting.

The platform includes generation, chat, dynamic task, incremental, and execution agents. The generation agent creates structured scenarios, Gherkin feature files, and Java or Python automation, then validates the generated code. The chat agent can answer questions or revise an active artifact. Other agents convert business requirement documents into user stories, extend work across linked Jira stories, and execute tests while classifying failures and saving results.

AWS architecture provides tenant isolation and test execution

TCS chose Amazon Bedrock AgentCore to run the agents. According to AWS, Amazon Bedrock provides a choice of models, allowing TCS to select models for tasks such as scenario design and code generation. AgentCore runtime scales with demand, and each session runs in its own isolated microVM.

The multi-tenant software as a service platform accepts inputs from Jira, business requirement documents, Swagger specifications, uploaded documents, GitLab source folders, and captured UI flows. It generates scenarios, Gherkin feature files, and executable Java or Python tests, then runs the tests on Amazon Elastic Container Service. Amazon S3 and Amazon DynamoDB store results, while Amazon CloudWatch captures logs.

The shared control plane uses Amazon Elastic Kubernetes Service, Amazon CloudFront, Amazon Cognito, and AWS WAF. Each tenant application plane receives its own Kubernetes namespace, Amazon Cognito user pool, AWS KMS key, Amazon S3 bucket, Amazon DynamoDB tables, and Amazon Bedrock Knowledge Bases. Retrieval is filtered by tenant, project, and session, so project context is kept separate.

The execution agent detects the test type from generated code. API tests are routed to Amazon ECS on AWS Fargate, while Selenium UI tests use an Amazon ECS cluster backed by Amazon EC2. For UI runs, the executor can capture a virtual display with FFmpeg and publish an HTTP Live Streaming stream to Amazon S3 for delivery through Amazon CloudFront.