Ditch the Spreadsheets

Make QA work for you

Rhian Davies

2025-11-13

The Gateshead Flyover was inspected regularly, but one critical test hadn’t been done for 28 years.

fig-alt=A huge flyover is held up by two concrete pillars. The image is taken from below. There are road signs underneath displaying the direction of travel. In the background are trees and parkland.”

Quality code ≠ Quality assured code

When I started my job at The Strategy Unit the first task I was given was can you build some QA processes for our model?

My team develops and maintains a large, open source statistical model used to estimate how big hospitals of the future should be. The code was clean, well structured, documentated and tested. It was quality, reproducible code.

Quality assurance, on the other hand, is about building trust. It ensures the right processes are followed, results are checked, and outputs are credible and interpretable.

Useful resources 📚

• Framework to review models, NAO
• AQuA book, HM Treasury

What was missing?

QA Component
Change log	✅ GitHub
Technical guide	✅ Code documentation
User guide	✅ Quarto website
Roles/responsibilities	✅ Quarto website
Assumptions log	✅ Quarto website
QA plan	❌
QA log	❌

To find the missing pieces, I turned to existing guidance across governement and auditing organisations:

All our code was version-controlled, so we already had a change log. We maintained a Quarto website with user guidance, and wrote documentation alongside the code, which served as our technical guide.

• QA plan, planned QA activities
• QA log,

I scoured the internet looking for examples from other organisations. Almost everything I found was in spreadsheets.

The most comprehensive example I came across was from the Department for Energy Security and Net Zero (DESNZ) in their Quality Assurance (QA) tools and guidance.

However, the templates were mostly designed for Excel-based models and still just big, colour-coded spreadsheets.

My heart sank at the thought of having to manage QA with an ugly spreadsheet. There had to be a better way.

Our team was already using Git and GitHub for the model code and had just started experimenting with using GitHub projects for planning.

So I thought: what if we used a GitHub project for our QA plan and log too?

github.com/orgs/The-Strategy-Unit/projects

I set up a new GitHub project with two views:

• Open issues ➡️ QA plan
• Complete issues ➡️ QA log

Then I browsed our repositories and added any quality assurance related issues to the board.

Our model spans multiple repos, mostly public, but some private. The project board handles this seamlessly, showing public issues to everyone and private ones only to those with access.

Now, whenever I’m working on something QA related, I simply add it to the project board.

When we prepare our monthly model releases, we use a GitHub issue template work through a release QA checklist.

Every six months, I also do an internal QA review using another issue template.

This works because QA happens where the work happens. Our developers already live in GitHub. Asking them to open a spreadsheet every time they make a model improvement just doesn’t fit how our team works. But asking them to add metadata to an issue they’re already working on, does.

CHecklists help make it even simpler

Instead of a static row in an abandoned spreadsheet, each QA item has its own discussion thread, links to relevant code or analysis, and version history.

Issue labels

• 📝 Documentation
• 🗃️ Data & Assumptions
• 🧪 Verification
• ❓Validation
• 📁 Structure & Clarity

I also decided to add labels to the QA issues, based on the QA type.

Verification checks that the model solves the equations correctly. Validation is checks that it’s solving the right equations.

“Creating and maintaining a strong culture of quality assurance is vital for ensuring analysis is robust and of a high quality.”

Make QA work for you

• QA is about building trust, not ticking boxes 🛡️

• Embed QA where you work 💻

• Make QA a habit, not a chore 🔄

There’s still plenty more to do, but moving our QA plan into GitHub has made QA part of daily coding, not an extra task at the end.

If you’ve found other ways of managing QA (without the colour-coded spreadsheets!), I’d love to hear from you.