Why BCI Bank is breaking testing bottlenecks

Mario Pereira, Head of DevOps Environments at BCI.

For banks with complex technology estates, software testing can be delayed long before a test is actually executed.

Critical downstream services may be unavailable, external providers may impose long waiting periods and generating suitable test data can take weeks, leaving development teams dependent on systems they do not fully control.

Banco de Crédito e Inversiones, commonly known as BCI, is a Chilean bank headquartered in Santiago. Founded in 1937, it provides services spanning savings and deposits, securities brokerage, asset management and insurance, while its international presence includes City National Bank of Florida in the US.

BCI’s HQ in Santiago

The bank’s testing teams needed to support delivery across systems handling sensitive customer and corporate information while meeting regulatory and certification requirements. Access to the services and data required for testing, however, had become expensive, slow and difficult to coordinate.

One bottleneck involved the generation of test data. When BCI needed a large data set for credit-card testing, preparing and delivering that information could take up to a month, delaying validation work and creating additional costs before testing could progress.

Dependencies on external services, including Previred and Sinacofi, created further delays and increased latency and cost. Certification could take between 30 and 70 days, with the availability and behaviour of third-party systems adding complexity to the process.

Internal dependencies presented similar problems. Tuxedo-based services required many hours of software engineering and support, yet the resulting arrangements provided only a temporary response to the bank’s test-environment constraints.

Working with technology company Technology Solutions Latam, BCI introduced service virtualisation using testing vendor Parasoft’s Virtualize platform.

The approach allowed development and QA teams to replace unavailable or constrained services with computer-generated virtual versions capable of reproducing the behaviour needed for testing.

Removing dependencies from the test path

Service virtualisation gives testers access to simulated services without requiring the corresponding production system, external provider or downstream component to be available. Teams can reproduce expected responses, errors and real-world conditions while continuing to develop and test other parts of an application.

For BCI, the objective was to shift testing earlier in the software-development lifecycle while improving test robustness, code coverage and the flow of work between development and QA teams.

The bank identified four priorities for the programme: stabilising its test environments, reducing cycle times, creating a more fluid testing process and introducing health checks that improve transparency across the software lifecycle.

A more stable environment was intended to reduce failures caused by unavailable or inconsistent dependencies. That, in turn, would allow automated tests to run more reliably and prevent developers from repeatedly investigating problems originating in the test infrastructure rather than the application itself.

“With service virtualization, the environment is more stable and available, while the results are more predictable,” said Mario Pereira, Head of DevOps Environments at BCI.

That distinction is important. A failed test does not always indicate a defect in the software being assessed. It may instead reflect missing data, an unavailable third-party service or instability elsewhere in the test environment.

When those external conditions are unpredictable, teams can lose time determining whether a failure is genuine. Virtual services give testers a controlled environment in which dependencies behave consistently, making test results easier to reproduce and investigate.

Testing earlier and more continuously

BCI also wanted to move testing further left. By removing the need to wait for connected services and data, development teams could test components earlier rather than postponing validation until a complete environment became available.

The model supported both manual and automated testing. Teams could adjust virtualised environments to the scenarios they needed, reducing roadblocks while retaining the flexibility to test different behaviours and conditions.

Health checks across the process were intended to provide greater visibility into the state of environments and improve knowledge sharing between teams. This helped BCI identify problems earlier and reduce the risk that an unavailable dependency would interrupt later certification work.


“The agility within the teams has produced the best cycle times, resulting in benefits in time to market.”

– Mario Pereira

Service virtualisation also allowed the bank to anticipate problems and increase code coverage. Instead of restricting testing to the conditions available from a live service, teams could reproduce a broader set of responses and failure scenarios within a controlled environment.

This is particularly relevant in banking, where a customer journey may rely on multiple internal systems and external providers. Payments, account services, identity checks and regulatory processes can all introduce dependencies that make end-to-end environments costly or difficult to access.

By virtualising those dependencies, BCI could continue testing even when a connected service was unavailable, expensive to use or subject to access restrictions.

Test cycles falling

BCI reported a reduction of more than 50% in test-flow cycles following the implementation. Test efficiency improved by 30%, while application delivery accelerated by 20%.

Certification time, which had previously taken between 30 and 70 days in some cases, was reduced by between 50% and 60%. The bank also cut weeks from its test-generation timeline.

“The agility within the teams has produced the best cycle times, resulting in benefits in time to market,” Pereira said.

“We reduced the testing load, which has been verified by different teams for its effectiveness in supporting validations and certification in different environments and different teams.”

The reported results show how test-environment availability can influence delivery performance as much as the speed of test execution itself. Automating a test provides limited benefit if a team must still wait weeks for data or access to a required downstream service.

BCI’s approach reduced those waiting periods by giving teams virtual alternatives that could be used repeatedly across different environments. It also streamlined manual and automated testing rather than treating service virtualisation as a capability limited to automation engineers.

Greater control

For financial institutions, the value of service virtualisation extends beyond faster delivery. Controlled virtual dependencies allow QA teams to test defined scenarios repeatedly, creating more predictable evidence for validation and certification.

They can also reduce the cost and disruption associated with using live external services during development. Where access is restricted or charged, virtualisation allows most testing to proceed independently before final validation against the real system.

The approach does not eliminate the need for end-to-end testing with genuine downstream services. Banks must still confirm that integrations work in the target environment and that virtual behaviour accurately reflects the systems being simulated.

It can, however, prevent those services from becoming a daily constraint on development and QA. Teams can complete a greater proportion of their testing earlier, then reserve access to the real dependencies for the scenarios that genuinely require it.

BCI’s results demonstrate that test-environment engineering can be a significant quality discipline in its own right. By addressing the availability of services, data and infrastructure, the bank reduced test cycles, accelerated certification and gave its teams a more stable foundation for continuous testing.

For other banks facing tightly controlled or expensive downstream systems, the lesson is clear: removing an environment bottleneck may deliver greater gains than simply making individual tests run faster.


NEXT MONTH

REGISTER TODAY – SIMPLY CLICK HERE


Why not become a QA Financial subscriber?

It’s entirely FREE

* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *

SIGN UP HERE TODAY


REGULATION & COMPLIANCE

Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.


READ MORE


QA FINANCIAL PODCASTS

CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS