As our Zymez platform accelerated, so did our release cadence. With new customer requests, feature enhancements, and rapid innovation shaping every sprint, our development timelines became shorter — and our deployments more frequent.
But while the product was moving faster, one part of the process struggled to keep pace: regression testing.
Our testing team kept running into the same challenge — every release introduced multiple code changes, user stories, and fixes. But testers rarely had clear visibility into what exactly had changed, and more importantly, what could break because of it.
Developers would provide brief summaries or walkthroughs of what they worked on, but those explanations often captured what was intended, not what might be impacted. And in a complex application, intent rarely tells the whole story.
So the testing team did what every responsible QA team does when unsure:
they chose the larger, safer test suite — running broad regression cycles just to be confident nothing was missed.
It worked — but it came at a cost.
Regression cycles were:
Longer than ideal
Repetitive
Poorly prioritized
Mentally exhausting
We had built a platform capable of shipping features rapidly — but our regression process wasn’t aligned with that speed.
That’s when one question changed everything:
“If every code change already exists in commit history, why can’t the testing context come from there?”
And that became the starting point for our experiment with n8n automation and Claude-driven commit interpretation — transforming commit logs into actionable testing intelligence.

The Idea — Let Commit Logs Tell the Testing Story

The more we thought about it, the more obvious it seemed: every change that mattered to testing was already documented — not in a meeting note, not in a Jira ticket, but in the commit history.
Commit logs contain everything testers struggle to uncover manually:
What functions or modules changed
Which UI or backend components were modified
Whether the change touches shared logic affecting multiple workflows
If we could extract and interpret that information automatically, the testing team wouldn’t have to guess — they’d start every regression cycle with clarity.
So the goal became simple:
Notify testers about likely impact areas based on commit analysis — before they begin regression testing.
To make that happen, we chose n8n as the automation backbone. Its flexibility, built-in triggers, integrations, and visual workflow approach made it perfect for a distributed engineering process like ours.
Our DevOps engineer spun up the first workflow quickly:
We added a Bitbucket trigger so the workflow executes whenever a new commit hits the repo.
Then we added an HTTP Request node to fetch commit logs via Bitbucket’s API.
Almost instantly, we had a fully automated workflow that:
Listens for new commits → Fetches changes → Understands what was modified
For the first time, the system — not a person — knew exactly what changed between releases.
Now we just needed intelligence — something to read those commit logs and translate them into meaningful testing guidance, not raw diffs.
That’s where Claude entered the workflow.

Making Commit Logs Meaningful — Claude as the Reasoning Layer

Once we had the commit logs flowing into the workflow, the next challenge was clear:
Raw diffs alone don’t help testers. They need context.
So we wanted Claude to interpret the commit changes the way an experienced QA lead would — identifying:
  • What functionality the modified code belongs to
  • Which modules or features could be affected
  • Whether the change touches shared or reusable logic
  • What regression test cases should be prioritized
But to do that, Claude first needed awareness of our system — not just isolated code snippets.

Teaching Claude the Product

We started by giving Claude an understanding of our application structure.
Using Claude Code, we generated:
A one-line description of every file in the repository
  • Summaries of frontend components
  • Backend service responsibilities
  • Key workflows and feature boundaries
This gave the model a mental map of the system — a context that normally only developers know.
Next, we provided something crucial:
The full regression test case document.
So Claude now knew:
  • How our product is structured
  • What the features do
  • How those features are tested
With both resources available, we crafted a structured system prompt inside n8n — instructing the model to act as a QA impact analyst.

The User Prompt

In the user prompt, we passed the actual commit log and asked Claude to:
  • Summarize what changed
  • Identify affected functionality
  • Suggest regression areas
  • List specific test cases relevant to the change
n8n made this easy thanks to its built-in LLM nodes, letting us send data from earlier workflow steps straight into Claude — no custom scripting required.
For the first time, testers weren’t just seeing what changed — they were receiving intelligent, actionable testing guidance, automatically generated moments after a commit landed in the repo.
The model wasn’t just reading commit logs —
it was reasoning from them.

Delivering the Insight — Turning Analysis Into Action

Once Claude was able to interpret commit logs and generate meaningful regression guidance, the next question was:
How do we get this into the hands of testers without adding another manual step?
Since our testing workflow already lived inside OpenProject, where we track features, bugs, and sprint tasks, the most natural solution was to place the regression summary right where testers already work.
So instead of emailing summaries or sending Slack messages, we went one step further:
we allowed Claude to create the test task itself.
Using an MCP Tool connected to our OpenProject server, Claude could now:
  • Create a new Testing Task automatically
  • Add a structured summary of commit changes
  • Attach the suggested regression focus areas
  • Link the relevant existing test cases
  • Assign the task to the testing team or release owner
This meant that as soon as a commit reached the repository, the system not only understood the change — it also created a regression reminder with full context, without anyone needing to intervene.
Here’s what testers began to see inside OpenProject:
🔧 Release Build: Commit Impact Summary
————————————–🧠 Summary of Change:
– Updates made to Appointment Scheduling Service
– Validation logic modified for recurring appointments

🧩 Potential Impact Areas:
– Appointment creation flow
– Validation and form submission
– Calendar synchronization
– Notifications workflow

🧪 Recommended Regression Tests:
– [TC-004] Create appointment
– [TC-019] Cancel appointment
– [TC-022] Email/SMS notification validation
– [TC-045] Conflict handling logic

⚠️ Risk Level: Medium

Suddenly, regression wasn’t a guessing exercise — it was guided, focused, and time-efficient.
Instead of thinking,
“Where do I start?”
testers now asked,
“Okay, how quickly can I validate these areas?”
The result?
A workflow that once depended heavily on developer memory and tester detective work now flowed automatically from commit → analysis → task → execution.
The system had gone from being reactive to being intelligent and proactive.

Improving the Workflow — and What Comes Next

As soon as we saw the first version working, we knew we were on to something valuable — but we also saw room for improvement.
Right now, the workflow triggers on every commit. That works functionally, but in reality, testers don’t care about individual commits — they care about the combined change set that makes up a release.
So, the next iteration focuses on:
  • Grouping commits into release batches (instead of generating one task per commit)
  • Pulling full modified file contents – so Claude has deeper context when analyzing logic changes
  • Supporting annotated “release commits,” tagged branches, or CI events rather than generic push triggers
Our DevOps engineer is already refining these pieces — making the automation smarter, quieter, and more meaningful.
But even in its earliest form, this system has already made a noticeable difference.
Instead of testers needing long back-and-forth conversations with developers to understand what changed…
Instead of running broad, repetitive regression suites “just to be safe”…
Instead of starting blind with every release…
They now begin each cycle with clarity:
what changed, what might break, and what to prioritize.
It’s a huge mindset shift — from reactive testing to informed testing.
And this is just the starting point.
We can now imagine:
Automatically generating relevant test cases using LLM reasoning
Linking execution results back into the workflow
Creating a feedback loop where testing patterns continuously improve
Eventually letting AI predict regression scope based on historical defect patterns

AI + Automation Doesn’t Replace Testers. It Empowers Them.

What we built isn’t a replacement for human judgment — it’s an amplifier.
It takes context that was previously hidden in code and turns it into guidance testers can act on instantly.
For a fast-moving platform like Zymez, where speed must coexist with quality, this approach changed how we ship software:
  • Less time wasted deciding what to test
  • More time spent testing the right things
  • Faster releases with higher confidence
Regression testing stopped being a bottleneck — and started becoming a strategic, automated, intelligent part of our engineering workflow.