This post was co-written with Varun Valsan from Tata Consultancy Services (TCS).

Tata Consultancy Services (TCS) runs large-scale testing for Banking, Financial Services, and Insurance (BFSI) clients, where the slowest part of a release is rarely writing application code. The larger constraint is the chain of work that follows: interpreting requirements, designing scenarios, writing and maintaining automation, preparing execution environments, investigating failures, and assembling evidence for review.

BFSI clients need to increase testing throughput while preserving the controls expected in financial services. The objective wasn’t to replace quality engineers. It was to remove repetitive translation and execution work so that engineers could spend more time on risk analysis, exploratory testing, and release decisions. These industry needs generated four specific requirements for TCS. First, every test must be grounded in project-specific context rather than generic prompts. Second, it had to cover both API and browser-based UI testing to match how BFSI applications are built. Third, security is paramount, so every tenant’s data and knowledge store must be isolated. Finally, it must provide a repeatable path from requirement ingestion to test evidence and reporting, so the gains hold across teams and releases. In this post, we show how TCS built an agentic test orchestrator that turns requirements into executable, governed tests, and what it changed for its BFSI testing teams.

TCS already uses traditional test automation for its clients, and it does improve execution speed. But it leaves the slow work untouched: teams must still create the scenarios, convert them into scripts, maintain locators and dependencies, and diagnose failures.

Source link