How GitHub Saved My QA

(and Made Me Love It)

Rhian Davies

2026-09-08

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.”

How big should we build hospitals?

I work for The Strategy Unit, a research consultancy within the NHS. My team is responsible for the demand and capacity model for New Hospitals. Effectively trying to work out how big hospitals of the future should be. Obviously we want to make sure we get it right!

My team develops and maintains a large, open source statistical model used to estimate how big hospitals of the future should be. It won the Florence Nightgale Award last year.

“The award judges were impressed by the statistical robustness of the project - both in terms of the methodologies employed and the strong commitment to transparency”

However, it was a little different when I started…

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?

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.

We had great quality code but we couldn’t evidence or review that.

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.

Issue templates

GitHub issue templates can be useful for repeated QA tasks

Public Accounts Committee

youtube.com/watch?v=lw1id_4lXek

How can you be sure you stress test the assumptions in your model?

In February our model was reviewed by the House of Commons Public Accounts Committee.

Anna Dixon (MP and ex NHS Chief Analyst) asked a question about Quality Assurance. It was really nice to know that we can back up our Quality processes, and we got a good review from them.

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