Madhu Murty Ronanki on AI Testing, GCC Growth, and the Next Phase of Quality Engineering
In this StartupTalky GCC Leaders Insights Series interview, Madhu Murty Ronanki of QualiZeal discusses AI-led quality engineering, GCC transformation, agentic AI testing, DPDPA compliance, and the future of software quality assurance.
India's Global Capability Center (GCC) ecosystem is growing rapidly, with the industry expected to expand at a CAGR of around 11–13% through 2030. Meanwhile, the global Quality Engineering (QE) market is projected to grow at a CAGR of 8–10%, driven by AI adoption, automation, and cloud transformation.
In this edition of the StartupTalky GCC Leaders Insights Series, Madhu Murty Ronanki, Co-Founder & Head of India Operations at QualiZeal, shares insights on how AI is transforming quality engineering, the evolution of GCC testing strategies, DPDPA compliance, and the future of AI-led software quality.
StartupTalky: QualiZeal's CEO has described Hyderabad's convergence of GCC growth and AI driven software delivery as creating a demand for quality engineering unlike anything seen before. What specifically changed in GCC QE demand between 2023 and 2026 that is driving this?
Madhu Murty Ronanki: The expectations from Quality Engineering have undergone a significant shift between 2023 and 2026. Earlier, the focus was largely on test execution and automation. Today, GCCs own platforms, cloud modernisation initiatives, data products, AI features, and customer-impacting releases are influencing a drastic shift in quality expectations.
Organisations now look for faster release confidence, stronger production resilience, secure test data practices, domain-led validation, and responsible AI assurance.
The QE priorities have quickly evolved from questioning "How many tests did we run?" to "How confidently we can demonstrate that the product is reliable, safe, compliant, and ready for business use". This shift is evident across enterprises where QE is identified as a core engineering function.
StartupTalky: QMentisAI reduces test durations by nearly 60% and enables up to 95% test coverage. When a GCC engineering leader evaluates AI-assisted testing for the first time, what is the most damaging misconception they hold?
Madhu Murty Ronanki: A common misconception I have observed is equating AI-assisted testing to faster automation. The reality is more than this narrow assumption. Generative AI simplifies test requirements, scripts, and summary generation. However, its real impact lies in the way it influences the entire quality management lifecycle, accelerating the process from start to finish (test refinement analysis, test planning, risk identification through test design, coverage measurement, defect intelligence, and release readiness).
Also, adopting AI without domain context, high-quality data, human review, traceability, and governance can produce noise at scale. Organizations that view AI only as a productivity tool may miss the bigger picture and larger opportunities. In my view, GCC leaders should look at AI-assisted testing as a new quality operating model rather than just another automation accelerator.
StartupTalky: Everest Group notes that GCCs are only beginning to move from test automation to AI-led quality lifecycle management. What is preventing this shift from happening faster, and where are GCC engineering organisations most systematically under invested?
Madhu Murty Ronanki: Current market trends and observations reveal that the challenge is not tool availability. There are enough tools available. The bigger challenge is the operating model maturity.
Many GCCs measure QE through automation percentages, test case counts, and execution productivity. This playbook worked in the earlier phases of QE evolution. However, in the current times, with AI-led quality lifecycle management, there is a need for risk intelligence, better requirements quality, clean and governed data, observability, domain models, prompt governance, and evidence-based release decisions.
Unfortunately, organizations that have invested in automation also lack substantial investments in their underlying QE architecture. Areas such as test data platforms, AI assurance skills, service virtualization, production telemetry, and quality intelligence layers still need attention.
In essence, many organizations have automation islands, but their quality ecosystem is still not fully integrated into a single quality intelligence layer.
StartupTalky: GCCs are scaling agentic AI deployments where agents interact autonomously with other systems. What does testing an agentic AI pipeline look like compared to testing a traditional software application, and how underprepared is the average GCC QE team for this?
Madhu Murty Ronanki: Traditional software testing is largely about validating workflows, APIs, UI behaviour, business rules, performance, and security against known expectations.
Agentic AI systems introduce a different kind of challenge where we test how their agents interpret goals, plan, reason, leverage tools, retrieve work, escalate issues, and recover. Concurrently, we must assess them for bias, hallucinations, or unintended actions. We are not only testing outputs anymore; we are also testing autonomy and boundaries.
Most GCC QE teams are still building capabilities in this area because, historically, their strengths have been in functional testing and automation. Agentic AI systems require a stronger TEVV discipline. That means evaluating trust attributes, decomposing risks, defining meaningful metrics, creating adversarial scenarios, enabling monitoring and auditability, and ensuring appropriate human-in-the-loop review.
StartupTalky: QualiZeal serves GCC clients in insurance, travel, and transport. What quality engineering challenges are specific to the GCC operating model, arising from its distributed, dual-principal nature?
Madhu Murty Ronanki: The GCC model creates some unique QE challenges as it is inherently distributed. In many situations, engineering teams are based in India, while product ownership, architecture decisions, regulatory responsibilities, and customer accountability remain with global headquarters. As a result, quality risks emerge that go beyond testing itself.
Requirements can lose business nuance as they move across teams. Test data may be restricted. Environments may be controlled elsewhere. Release priorities may differ across geographies. In many cases, critical domain knowledge sits far away from the teams executing the work.
This is paramount, especially across industries such as insurance, travel, and transport with high-volume transactions, customer-focused workflows, and regulatory compliance pressures. Therefore, GCC QE teams must address alignment, context, traceability, environment readiness, and ultimately, enable shared release confidence across all stakeholders.
StartupTalky: India's DPDPA creates obligations around test data, including synthetic data generation and personal data masking in QA pipelines. How should GCC quality engineering teams redesign their test data strategies to comply while maintaining coverage?
Madhu Murty Ronanki: One change that organizations must make is moving away from production data copies as a convenient shortcut for testing. In the future, test data management must be built on privacy-by-design principles.
Personal data should be properly classified and then minimized, masked, tokenized, or synthetically generated before it is introduced in the QA pipelines. Every dataset should have a clearly defined purpose, an access policy, a retention policy, and an audit trail. At the same time, synthetic data should not come at the cost of quality. It must still preserve business rules, edge cases, negative paths, and domain-specific risk scenarios.
The other thing is that privacy gates, lineage checks, access controls, and automated expiry mechanisms must be increasingly embedded in CI/CD pipelines. And lastly, DPDPA compliance should not reduce test coverage. If implemented correctly, it will drive smarter and safer coverage.
StartupTalky: QualiZeal grew from zero to USD 50 million in revenue by 2025 without external funding, in a sector dominated by large IT services firms. What does being bootstrapped force you to understand about GCC client needs that a well-funded competitor might overlook?
Madhu Murty Ronanki: Being bootstrapped teaches a certain discipline that doesn’t come with the privilege of having large funding rounds, brand leverage, or broad market narratives. Every decision must connect back to a real customer problem and measurable outcome. What you learn very quickly is that GCC clients do not really buy narratives. Ultimately, they look for confidence in delivery.
These organizations operate under significant pressure, constantly balancing engineering complexity, release risk, cost expectations, stakeholder alignment, and business outcomes across multiple geographies.
Because of that, they value partners who understand those realities and can bring practical solutions rather than generic promises.
As a bootstrapped company, trust has to be earned account by account and engagement by engagement. In many ways, that creates a deeper understanding of what GCC clients truly value: reliable delivery, relevant IP, domain understanding, measurable outcomes, and proof before promise.
Apoorva Bajj
