The National Archives: five weeks with the Transfer Digital Records team

The Transfer Digital Records (TDR) service supports the secure transfer, validation, and management of digital records into The National Archives, who ensure that government digital information is preserved, accessible, and trustworthy over time.

As digital services and systems grow in size and complexity, maintaining consistent quality across an end-to-end service becomes increasingly challenging. For the TDR team, quality practices were in place, but they were distributed across tools, environments, and delivery stages, making it harder to build a clear view of overall risk, testing maturity, and delivery confidence.

This was the position the TDR team were working within. The service is a critical entry point into a wider end-to-end user flow spanning multiple services, and as it evolves, the team wanted greater clarity on testing maturity, risk, and alignment with the Government Service Standard.

While quality was already valued and checks existed across delivery, there was no clear baseline of “what good looks like” or consistent visibility of how testing, environments, observability, and delivery confidence should evolve as the service scales.

Over five weeks, we worked closely with the TDR team to assess the current state and develop a bespoke QA strategy and roadmap designed to be practical and realistic given constrained developer capacity - providing clear direction for how their QA processes could be strengthened over the next 12 months.

Phase one: Listening, observing and taking notes

We began with stakeholder interviews across the team and wider stakeholder groups, including development, delivery, and external collaborators. These conversations covered a broad range of topics, from story refinement and testing practices through to supporting tools, environments, and delivery workflows. Due to the size and complexity of the service, this assessment spanned the full development lifecycle.

Our interviews are intentionally conversational and exploratory, as this is often where the most valuable insights emerge. This approach helped surface how quality was actually being considered and applied across the service, rather than how it was formally defined.

From these conversations, we built a clear picture of the current state of quality across the team, focusing on:  

• existing quality checkpoints.
• where gaps were.
• where improvements could be made.

We consolidated these findings into a structured risk assessment and shared it back with the TDR team. This created space to validate our understanding, challenge assumptions, and refine the emerging picture before moving into strategy design.

Phase two: pulling the threads together

Once the current state was clearly understood, we turned our focus to shaping the QA strategy and roadmap. Importantly, this wasn’t a documentation exercise - it was a process of alignment. The team already had valuable practices in place, so the focus was to connect what existed, suggest improvements for gaps and make prioritisation explicit.

Using the risk assessment as the anchor, we worked with the team to define:

• where focus should sit first based on risk and impact.
• what “good” looks like for their context and constraints.
• how testing, environments, and observability should evolve over time.

This phase was highly collaborative. Rather than producing recommendations in isolation, we worked through options with the team, discussing trade-offs and grounding decisions in real delivery constraints, including limited developer capacity, schedules and budgets.

The result was a QA strategy that didn’t sit outside the team’s work but reflected it. It was shaped, challenged, and refined until it could realistically be used, not just referenced.

Phase three: quick wins and light enablement

In the final phase, we focused on turning the strategy into lightweight practical improvements that the team could start using immediately. The goal was to set the team up for success in a way that made sense for them. 
Working with the team, we identified and delivered a small set of targeted improvements, including:

• a session to align on tester mindset across roles.
• introducing structured test cases to improve consistency in coverage.
• creating a shared approach for discussing quality earlier in delivery.

The aim was not to drive large-scale change, but to build confidence in how quality was approached day-to-day, and to give the team practical tools they could continue to evolve after the engagement.

My reflections on the five weeks

This was a short but intensive engagement, but the openness and collaboration of the TDR team made it both effective and rewarding.

Too often, QA strategies are shaped around idealised delivery conditions. In reality, services operate under constraints - limited capacity, competing priorities, and evolving technical complexity. The TDR team’s willingness to explore how quality was working in practice, not just how it was documented, allowed this work to stay grounded in those conditions, focusing on what was feasible rather than abstract recommendations.

With a shared understanding of quality, clearer visibility of their risks, and practical next steps in place, they’re now well positioned to continue evolving their QA practices and embedding quality more deeply as their service and team grow.