Why your wealth management firm should write its test strategy early

A common design process mistake

Most programmes begin with this sequence:

The firm defines the problem – perhaps it’s a new platform, a regulatory requirement or an operating model change. Then requirements are gathered, vendors are shortlisted, architecture is shaped and delivery plans are agreed. The programme gains momentum quickly because there is pressure to move.

At this stage, the firm is focused on making big decisions that will shape everything that follows: how the system will work, how data will move, how processes will change and how quickly delivery needs to happen.

Testing is unlikely to be completely absent from those conversations, but it’s rarely central. It tends to sit slightly to the side, assumed rather than designed. That’s when the mistake begins.

Then, at some point – usually once delivery is already underway – the need for a test strategy becomes explicit. It might come from governance, or audit, or from within the programme itself as complexity increases.

And that’s when the mistake is completed: the test strategy is written to work on a design that already exists.

It doesn’t feel like a mistake has been made at the time. The test strategy document gets written. It describes the scope, the approach, the environments and the responsibilities. It looks complete. It gets signed off. But by then, the important decisions have already been made without it.

Its potential to help shape original design has already been lost.

What is a test strategy meant to achieve?

If you ask delivery leaders to define the purpose of a test strategy, you’ll mostly get sensible answers. They’ll probably reply that test strategies set expectations, align stakeholders, support governance and define how testing will be carried out.

All of that is accurate. But it describes testing only as a reporting mechanism rather than as a design function too.

A test strategy, at its most useful, is a document that answers a harder question: what needs to be true for testing to give you real confidence?

In a financial services context, confidence is not simply whether a system works. It is whether you can prove it works, under the conditions that matter, in a way that stands up to regulatory scrutiny and senior stakeholder challenge.

To get there, certain things need to be designed deliberately. You need requirements that can be tested clearly, systems that can be observed and interrogated and data that reflects real-world scenarios, including the edge cases that matter most in your business. You need environments that behave consistently. You need traceability between what was asked for, what was built and what was tested.

None of those are testing activities. They are design decisions. And if they are not influenced early, testing becomes an exercise in working around constraints rather than validating outcomes.

A useful question to ask at this point: would your current test strategy give a senior stakeholder genuine confidence in your programme? Or would it tell them how testing is being managed without telling them whether the right things are being tested in the right way?

Why having a test strategy early changes everything

The easiest way to understand the impact of establishing a test strategy early is to consider what becomes difficult to change once a programme is underway.

Architecture decisions harden quickly. Once systems are built, changing how components interact or how data flows is expensive and disruptive. Data models become embedded: if key attributes are missing or structured poorly, fixing that later affects multiple parts of the system simultaneously. Delivery timelines create pressure, and as milestones approach, there is less appetite for revisiting earlier decisions – even when issues emerge. Vendor contracts introduce constraints around responsibilities for testing, environments, and data that can be difficult to renegotiate once agreed.

When a test strategy arrives after these elements are already in place, it has limited influence. It can describe how testing will navigate those constraints, but it cannot remove them.

That is where risk begins to accumulate – not because testing is ineffective, but because it is being asked to validate something that was not designed with validation in mind.

If your programme is already underway, it is worth mapping the constraints your test team is currently working around. Each one is likely traceable to a decision made before the test strategy was in place. That mapping exercise is not about assigning blame. It is about understanding where your current risk actually lives, rather than where your test metrics suggest it does.

How late-stage testing problems appear in practice

From the outside, programmes affected by late-stage test strategy don’t look broken. Testing still happens. Test cases are written. Defects are raised. Progress is reported. From a governance perspective, everything appears to be in place.

The issues are more subtle, and if you are seeing any of the following in your programme right now, they are worth taking seriously.

Testing cycles are taking longer than expected, with repeated rework required to get stable results. Business and technology teams are in disagreement about whether something is working correctly, often because the requirements were not precise enough to make the answer clear. Confidence is fluctuating as new issues emerge late in the process rather than earlier when they would be cheaper to address. The team is relying on headline metrics – high pass rates, declining defect counts and completed test phases – to signal readiness, but those metrics are not answering the question that matters: are you testing the right things in the right way to achieve the level of confidence your firm needs?

Each of those signals, on its own, might be manageable. Together, they usually point to the same root cause: testing is adapting to the programme rather than shaping it.

The hidden cost of late-stage testing

One of the reasons this issue persists is that the cost of late-stage test strategy is not always obvious at the point it begins to accumulate.

Programmes continue to move forward, milestones are still met and testing still produces results. The cost emerges gradually, in ways that are easy to attribute to other causes.

For instance, time is lost resolving issues that clearer requirements would have prevented, or effort increases as teams work around environment or data limitations that were not identified early enough to be designed out – or confidence becomes harder to establish because the evidence base is fragmented, inconsistent or incomplete.

The impact is often only fully visible at the point firm decisions need to be made. Go-live readiness discussions become more complex than they should be. Stakeholders ask for reassurance that the programme cannot straightforwardly provide. Decisions get made on judgement rather than evidence. At that point, the programme is no longer just delivering technology – it’s also managing risk under pressure.

The cost of that position is rarely captured in retrospectives. It’s absorbed into contingency, extended timelines and the quiet exhaustion of teams who have been working harder than they should have needed to.

What changes when quality engineering starts earlier?

When test strategy is brought forward and treated as part of design, the shape of the programme changes in ways that are not always immediately visible but become significant over time.

Conversations shift. Instead of asking how something will be tested once it is built, teams start asking what needs to be true for it to be testable at all. That is a more demanding question, and it surfaces ambiguity earlier – which is exactly when it is cheapest to resolve.

Requirements become more precise because they need to support validation. Architecture decisions are made with observability in mind: systems are designed so that behaviour can be interrogated, not just executed. Data is considered as a testing asset, not just an input – the question becomes whether it can represent the scenarios that genuinely matter, including the ones that have caused problems in the past.

Delivery plans account for validation as part of the process rather than as a phase at the end. This changes expectations around timelines and iteration in a way that tends to reduce late-stage pressure rather than front-load it.

None of this requires a fundamentally different set of skills. It only requires those skills to be applied at a different point in time.

If you are at the start of a programme or about to begin one, the most practical thing you can do is bring quality engineering into the design phase explicitly. Not as a reviewer of what has been decided, but as a contributor to how decisions are made. Define testability requirements alongside functional requirements. Agree data and environment needs before contracts are signed. Make traceability a design principle, not a documentation task. These are not large changes to programme structure, just changes to sequencing and involvement, and the return on them compounds throughout delivery.

The role of leadership in shifting testing left

For this approach to take hold, it needs to be actively supported by how programmes are led.

If testing is still positioned as something that follows delivery, it will continue to arrive too late – regardless of how capable the test team is. If success is measured primarily by speed of delivery, early-stage quality engineering will feel like friction rather than investment.

Leadership decisions shape these dynamics directly: who is involved in early design discussions, what questions are asked when plans are reviewed, how risk is defined and assessed and what evidence is required before significant decisions are made.

A practical starting point for any delivery leader: in your next programme review, ask the test lead when quality engineering first had meaningful input into how the system was designed, not just how it would be tested. If the answer is after architecture was agreed, you’ve identified where your current constraints originated. If they struggle to answer the question at all, that’s an even more important signifier.

When quality engineering is present in design conversations, it influences outcomes. When it arrives after those conversations have concluded, it adapts to them. Why your firm might be in one position rather than the other is a leadership question, not a testing question.

Why early testing is becoming even more important

The environment your firm is operating in has changed in ways that make late-stage correction significantly more difficult than it was five years ago.

First, regulatory expectations are higher. The FCA's operational resilience requirements, Consumer Duty obligations and SMCR accountability frameworks all increase the level of evidence your firm needs to demonstrate control and confidence in change.

Second, programmes are more complex, typically involving multiple systems, multiple vendors and data flows that cross organisational boundaries. Timelines have not become more forgiving to compensate for that complexity.

This combination means that when issues emerge late in delivery, there is less room to address them without impacting go-live dates or increasing risk in ways that attract regulatory attention. The tolerance for uncertainty at the point of readiness decisions is lower. And the personal accountability frameworks now in place mean that 'we thought it was ready' is a harder position to defend than it once was.

In that context, the timing of test strategy is not a process detail, but a material factor in how confidently your firm can deliver change and account for it.

Where to start if this resonates

The idea that test strategies are written too late is something many delivery leaders recognise immediately when they see it described. The challenge is acting on it, particularly mid-programme when the constraints are already in place.

If you are mid-programme, the priority is visibility. Map the constraints your test team is currently working around and trace them back to the decisions that created them. That exercise will tell you more about your actual risk position than your current test metrics will. It will also help you make a more informed case for the resource or time needed to address the highest-impact issues before go-live.

If you are at the start of a programme, the opportunity is greater. Bring quality engineering into the design phase as a participant, not a reviewer. Define what 'good enough to test' means for requirements, data and environments before delivery begins. Agree traceability expectations early so the evidence base for readiness decisions is being built throughout the programme, not assembled under pressure at the end.

If you’re in a leadership position that can shape how programmes are structured, the most useful question to ask is a simple one: at what point does quality engineering currently start to influence what is being built, rather than describe how it will be tested? The answer will tell you more about your firm's current change delivery risk than most programme status reports.