Rethinking Test Management in Modern Engineering
For a long time, test management has lived somewhere outside the code, spreadsheets, dashboards, or separate tools.
But as teams move faster now, things start to break down. Code changes quickly, features evolve, bugs get fixed, but test documentation doesn’t always keep up.
And that’s where the frustration begins. Outdated test cases, unclear coverage, and a constant feeling that things are slightly out of sync.
Because of this, many teams are starting to rethink how they manage testing altogether.
What Is Repository-Centric QA?
At a simple level, it just means this:
keep your test cases in the same place as your code.
Instead of managing tests in a separate tool, you store them in the repository, often as Markdown files, and update them through the same workflow as code changes.
So when code changes, tests change with it. No separate syncing needed.
It’s a small shift, but it changes how teams work.
Why Teams Are Moving Toward the Repository
The biggest benefit is alignment.
When tests live in the repo:
They evolve with the code
Changes are visible to everyone
History is automatically tracked
You don’t have to wonder if your test cases are outdated; they’re right there, versioned along with everything else.
It reduces that constant mismatch between “what the system does” and “what the test docs say.”
Markdown as the Foundation
Most teams doing this use Markdown to write test cases.
Why? Because it’s simple.
A test case in Markdown might look like:
Test Case ID
Description
Preconditions
Steps
Expected Results
Nothing fancy. Just clean, readable text.
And since it’s plain text, it works perfectly with version control. You can review it, edit it, and track changes without needing any special tools.
Collaboration Feels More Natural
One of the nicest side effects is how collaboration improves.
Instead of QA working separately, test cases become part of the same flow as development.
Changes go through pull requests
Feedback happens in the same place as code reviews
Everyone can see what’s being tested
It stops feeling like “QA work” vs “dev work” and becomes more of a shared responsibility.
From Documentation to Operational Truth
This is where things get really interesting.
Traditionally, test status is tracked manually when someone updates a dashboard or marks something as passed/failed. But that can easily be outdated.
With a repo-based approach, you can start linking:
what you expect (test cases)
what actually happened (test results)
That gap between expected vs actual is what really tells you the truth about your system.
This idea, sometimes called Operational Truth, is what makes testing more reliable. You’re not guessing or manually updating status anymore. You’re looking at real execution results.
Challenges to Keep in Mind
Of course, it’s not perfect.
As things grow, a few challenges show up:
Harder to find what’s covered (discoverability)
Reporting isn’t as straightforward
Needs some structure to scale well
Teams usually solve this with:
Clear folder structures
Naming conventions
Lightweight reporting layers
So it’s less about replacing everything and more about adding just enough structure to keep things manageable.
The Future of Test Management
Test management is slowly moving away from being tool-heavy and toward being workflow-driven.
Instead of relying only on external platforms, teams are bringing testing into the same space where development already happens.
Repository-centric QA is a big part of that shift. It fits naturally with version control, CI/CD, and how modern teams already work.
It also connects well with the idea of Test Management as Code (TMaC), where test cases are treated just like code versioned, reviewed, and continuously improved.
Some teams exploring repository-centric QA also refer to resources like https://qualityfolio.dev/ to see how test cases written in Markdown can be organized within the repository and aligned more closely with development workflows.
Final Thoughts
This isn’t about saying traditional tools are bad. They still have their place.
But more teams are realizing that keeping tests closer to the code just makes life easier.
Less syncing. Less confusion. More transparency.
And most importantly, testing starts to reflect what’s happening in the system, not what we think is happening.
Top comments (0)