Who is CAT for?

CAT is a testing toolkit for data teams. Strong enough to hold an entire data solution together, light enough to install in a minute and use the same afternoon.

“Data team” here means a role, not a headcount. If you are responsible for data that other people rely on, you are the data team — whether that is you on your own or two hundred people across four countries.

The question CAT answers — can we ship it, and did we break something? — is the same at every size. So is what answering it is actually worth: a data team that sleeps at night, and an organisation that trusts its data and the people producing it.

The team size changes. The practice does not.

The four situations CAT is built for #

Most data teams recognise themselves in one of the four below. The situations differ considerably; the practice underneath them does not.

One person, one data solution #

You are the entire data team, and everything downstream depends on you noticing.

• Typical case: a single Power BI model, a handful of pipelines, one data mart nobody else touches.
• The constraint: no QA function to ask, no test environment worth the name, and no budget to create either.
• What CAT gives you: installation on your own machine — no admin rights, no IT ticket. A check that the figures in your model still match the source they came from, run before you publish.
• This is a complete testing practice, not a reduced version of one.

Testing assigned to a junior #

Ownership of quality lands on the newest person, and everyone hopes it works out.

• Typical case: the most recent member of the data team is given “quality” — because it matters, and because the seniors have no time for it.
• The constraint: she is not a data-QA specialist. Almost nobody is; there are very few on the market.
• What CAT gives her: a check states what should be true, and CAT proves whether it is. That is learnable in a morning, and CAT Pilot will draft the first tests for her to review rather than invent.
• And what she gets out of it: she becomes the person on the data team who can prove the data is right. That is a real skill, it is visible, and it belongs to her rather than to the tool.
• No specialist hire is required before a data team can start testing.

A team sharing one data solution #

Testing already happens. It just lives in four separate heads.

• Typical case: four people, four private habits — one checks by eye, one has a script that runs only on their laptop, one assumes somebody else is doing it.
• The constraint: nothing is shared, so the practice disappears when a person is on holiday or leaves.
• What CAT gives you: tests live in the project, in your repository, in a form every member of the data team can read, review and change.
• Test sets outlive the people who wrote them.

A corporation standardising QA #

Many data teams, one standard — usually attempted the expensive way.

• Typical case: a dozen data teams, several countries, and a genuine need to say the same thing about data quality in all of them.
• The constraint: a central standard normally demands a programme before anything can begin.
• What CAT gives you: the same toolkit and the same project format everywhere, so what one data team builds is directly reusable by the next, and results from all of them can be collected in one place.
• Data teams can start independently and still end up consistent with each other.

The question all four ask first #

Whatever the size, the first sentence is the same: we would not know where to start.

• It is the normal state, not a failure — and it is the single most common reason data testing never begins anywhere.
• The answer does not change with headcount. One check, on the thing that matters most, before the next release.
• CAT is opinionated on purpose, so the first day goes on deciding which number matters rather than on how any of this ought to work.

What all four have in common #

Different data teams, different constraints, but the same four facts apply to every one of them.

• CAT is installed and used, not rolled out. Nothing needs to be adopted organisation-wide before anything can happen.
• The same project format applies at every size, so growing from one person to a dozen data teams does not mean starting again.
• Tests are plain text in your repository, reviewed and versioned like the rest of your work.
• No CI/CD, no data maturity and no specialist role are required to begin.
• The practice is learnable, and learning it is the actual goal. CAT is the vehicle — the data team that ends up genuinely competent at quality assurance is the destination.
• Somebody has to own it. Not a job title, not a headcount — one person for whom this is genuinely their business. In all four situations above, that is the thing that makes the difference between a practice and an intention.

The result: a badge on your data #

A certificate is signed once. A badge is earned every time you check.

Whichever situation you are in, the outcome is the same — a badge: pass, warn or fail, earned and recorded, and reissued every time you check. Not a certificate somebody signed once in March.

What that badge proves, in each case:

• One person — the figures in the model reconcile with their source.
• Junior-owned testing — coverage measurably improved this quarter.
• A team — last Thursday’s release broke nothing downstream.
• A corporation — the same standard is being met in a dozen places at once.

Which brings it back to the same two questions, and the same two answers. Can we ship it? Did we break something? — answered with evidence, every time, at any size. That is what a data team sleeping at night is actually made of, and it is why the business ends up trusting the data and the data team alike.

Your data team does the work. The badge is simply how everyone else finds out.

Worth knowing before you assume nobody outside the data team cares: they usually do. Poor data quality is felt in the business long before it is discussed in IT, and a badge is the first thing that lets both sides talk about it in the same terms.