Anand Naidu, our resident development expert, has a unique perspective that bridges the gap between the code and the business. Proficient in both frontend and backend systems, he offers deep insights not just into coding languages but into the entire software lifecycle, particularly where development velocity meets the unyielding demands of technology risk and operational resilience within financial services. This interview explores the critical disconnect between the push for rapid digital delivery and the necessity for robust safety measures. We’ll delve into the practical implications of regulations like DORA, the dual-edged sword of AI in both development and testing, and the evolution of quality assurance from a technical checkpoint into a strategic, board-level risk function.
Many financial firms optimize delivery velocity at the team level, yet treat resilience as a downstream control, leading to a gap between speed and safety. What specific organizational or process changes can leaders implement to embed resilience thinking directly into agile delivery pipelines from the start?
The core of the issue is that most organizations in the UK and Ireland see the risk, but their execution falls short. Velocity is a metric celebrated within individual teams, while resilience is often an afterthought, a gate that code must pass through later. This creates a structural disconnect. We see this in the data—two-thirds of financial firms admit to deploying code without comprehensive testing, and an alarming 68% fully expect business-impacting outages in the next year. It’s a false economy. To fix this, leaders must stop treating resilience as a separate function. It needs to be a shared objective, with integrated teams where developers, QA, and operations work together from day one. True velocity isn’t just about shipping fast; it’s about the ability to change safely and repeatedly without causing chaos downstream.
Research shows 81% of organizations delay releases due to a lack of confidence, yet two-thirds still deploy without comprehensive testing. What are the most critical, yet often overlooked, end-to-end testing scenarios that frequently expose risks that unit and functional tests miss?
That contradiction you mentioned—delaying releases out of fear, yet still pushing changes without full testing—is precisely where the biggest risks hide. The problem isn’t a total absence of testing; it’s the absence of the right kind of testing. Teams are generally quite good at unit and functional tests that check if a small piece of code does what it’s supposed to do in isolation. However, the most devastating outages I’ve seen often come from seemingly minor changes. Think about a simple configuration update, a small data schema change, or an upgrade to a third-party service. These things will pass local tests with flying colors, but they break spectacularly when they hit the real world with its complex system integrations and massive data volumes. The critical gap is in end-to-end business process testing and robust regression testing against realistic conditions, which are often skipped for the sake of speed.
The Digital Operational Resilience Act (DORA) is pushing firms beyond simple compliance checklists. Can you describe the practical differences between a mature, DORA-aligned quality engineering strategy and a less mature approach that only satisfies point-in-time audits?
The difference is night and day. A less mature firm sees DORA as a documentation chore. They’ll focus on point-in-time audits and attestations to satisfy an immediate regulatory query, but this does nothing to actually prevent an outage. A mature organization, on the other hand, understands that you can’t bolt on resilience after the fact. They treat DORA as a mandate to fundamentally modernize how they engineer quality. This means building resilience in from the start. In practice, they are aligning all their testing efforts directly to critical business services, automating regression suites based on the specific risk of a change, and ensuring there’s a crystal-clear, auditable trail from a business requirement all the way through to the tests and controls that validate it. They know resilience must be continuously tested and proven, not just documented.
While 96% of financial firms plan to expand AI use in testing, many hesitate due to concerns about trust and accountability. How can organizations practically implement AI-driven testing to augment human oversight, rather than creating a “hands-off” system that could introduce new risks?
The hesitation is completely understandable. It’s not about the AI’s capability; it’s about trust and control. We see significant concerns, with 43% of firms worried about biased AI outputs and a third citing data privacy risks. The key to successful adoption is framing AI as a powerful partner, not a replacement for human judgment. The most successful implementations use AI to do what humans can’t—analyze immense change risk in real-time, optimize test coverage across millions of permutations, and adapt testing to new code instantly. The human expert then retains oversight, applying their judgment and domain knowledge to the results. The moment “autonomous” is misinterpreted as “hands-off,” the project stalls. AI should augment human expertise at a scale we’ve never been able to achieve before, but accountability must always remain with people.
As developers increasingly use generative AI to write code, QA’s role is shifting from defect detection to “trust assurance.” What specific new skills or testing models must QA teams adopt to effectively interrogate the intent and behavior of AI-generated code, beyond simply validating its outputs?
This is a fundamental shift in mindset for QA. Generative AI models are built for speed and plausibility, not for regulatory precision or understanding the intricate dependencies of a core banking system. They can easily introduce logic that was never specified or create hidden decision paths a human developer would have avoided. Therefore, QA can no longer just validate that an output is correct. They have to interrogate the code’s intent and behavior. This means getting involved much earlier in the process to understand the why behind the code. Practically, it requires a much stronger emphasis on risk-based and complex scenario testing. It also means equipping testers with their own AI-powered tools to analyze and challenge the logic produced by the machine before it ever gets close to a production environment. QA’s new role is to be the guardian of trust, ensuring that AI-assisted development doesn’t introduce hidden operational or compliance time bombs.
With the financial impact of software issues becoming a board-level concern, QA leaders are now asked for evidence of resilience. What key metrics or dashboards should a QA leader present to the board to effectively communicate change risk, test effectiveness, and exposure across critical business services?
The conversation has absolutely elevated to the board level. When nearly half of UK firms are reporting annual losses between £773,000 and £3.9 million from software failures, and a quarter see customers leaving because of it, the board has no choice but to pay attention. A QA leader today can’t just talk about bug counts. They need to present a risk-centric view of quality. I would recommend a dashboard focused on three areas. First, a clear visualization of change risk: which critical business services are being modified and how extensive are the changes? Second, a measure of testing effectiveness: are we testing the right things, and how much of our risk is covered by automated regression? Finally, a metric for residual exposure: what is the potential business impact of the risks we haven’t mitigated? When you can show the board where digital risk is building up and how quality engineering is actively managing it down, QA transforms from a technical checkpoint into a strategic risk function.
What is your forecast for software quality and operational resilience in financial services for the next two years?
The defining difference between the leaders and the laggards will be whether quality is seen as a project outcome or as a continuous, living capability. The firms that succeed will be those that have invested deeply in automation, intelligence, and data-driven testing, allowing them to manage risk in real-time. They will have successfully broken down the silos between development, operations, and risk management, uniting them around shared resilience goals. In contrast, those that cling to manual processes and fragmented tools will find themselves drowning. Our research already shows that 32% of organizations directly link their poor software quality to mounting technical debt, which is simply an unsustainable model. In a world of accelerating change and intense regulatory scrutiny, the gap between these two groups will widen dramatically, and it will become very clear who built their systems on a foundation of resilient quality and who built on sand.
