If Greek mythology had been written in the age of Jira, there would probably be a minor god in charge of “unexpected role changes.” One morning, you’re a seasoned QA Engineer, happily wrestling with test cases and edge conditions and the next thing you know, the gods of Delivery roll their divine dice, and you respawn in a new role: Process Automation Engineer.
That’s more or less what happened to me.
For more than eleven years, my natural habitat was clear: I was a QA Engineer. I lived among requirements, acceptance criteria, test plans, bugs that only appeared five minutes before a release, and that strange mixture of pride and terror that comes with saying “Go to release.”
Then came the twist: I moved into process automation, designing workflows in n8n that connect systems, move data, trigger notifications, and basically do things while humans are busy sleeping, eating, or creating new Jira tickets.
To be clear: I’m not talking about automated tests or classic “QA Automation”. I’m talking about business process automation end to end flows that live in a canvas full of colourful nodes and arrows.
My role changed. But my soul didn’t.
The identity crisis that wasn’t small at all
Changing your title is easy. Changing your wiring… not so much.
I’ll be honest: I looked in the mirror and didn’t recognise the QA I had been doing for over a decade. I saw a shadow, a blur, a silhouette without definition. One moment, I was dealing with requirements, acceptance criteria, test cases and regressions. Then next, I was supposed to build the entire system that executes specific actions.
The existential questions came uninvited:
-
Am I still a QA if I’m designing workflows instead of testing them?
-
Did I cross over to “the other side” and become one of those people who cause the bugs instead of reporting them?
-
Is my LinkedIn title lying to everyone, or just to myself?
It took time and more than a few late night debugging sessions to notice a simple truth: I hadn’t dropped my QA identity at the door of process automation. I had simply given it new toys.
From testing features to caring for invisible monsters
In my former life, my universe was made of fairly well defined pieces: this feature, this user story, this endpoint or screen. You could draw a box around “what we’re testing” and, with effort, keep the chaos contained. Process automation cheerfully ignores those boxes.
Now, my mental picture looks more like this: a trigger fires in System A, a workflow wakes up, fetches data from System B, transforms it into something System C won’t reject in disgust, sends a message to Slack, and schedules something else for later just to keep life interesting. And it all needs to behave as if it were one cohesive, predictable thing.
At some point, I noticed my inner dialogue had shifted from “Does this feature behave according to spec?” to something closer to “Does this whole chain of events behave like a sane, adult member of the ecosystem?”
The monsters you chase in process automation aren’t UI glitches. They’re half completed processes, duplicated events, and silent failures nobody notices until a user angrily forwards a screenshot three weeks later.
Welcome to the underworld of invisible failures. Bring your QA flashlight.
A story from the trenches
Let me tell you about a workflow I built recently.
The requirement sounded deceptively simple: automate notifications for a recurring business process. Contractors needed to receive reminders via Slack, with escalating urgency depending on how much time had passed. The system had to track who had responded, differentiate message tones (friendly at first, urgent later), log everything to Google Sheets, and integrate with Google Drive for document handling. On paper, a nice little automation.
My QA soul looked at it and immediately saw:
-
What if the same person receives duplicate notifications?
-
What happens if someone responds between the scheduled reminders?
-
How do we avoid pestering people who already completed their task?
-
What if a third party API decides to take a nap at 3 AM on a Sunday?
Before I wrote a single node, I had already catalogued a dozen ways the flow could misbehave. That catalogue wasn’t pessimism, it was eleven years of QA reflexes, refusing to believe that anything “should be fine.”
The result? A workflow with multiple checkpoints, state tracking, conditional branching based on response status, and differentiated message templates. Not because I’m paranoid, but because I’ve seen too many “simple” systems fail in spectacular, silent ways.
The technologies were familiar territory for QA testing: Slack, Google Drive, Google Sheets, JavaScript logic inside n8n nodes. The difference was that now I wasn’t verifying someone else’s work; I was building it and questioning it simultaneously.
I felt like playing both sides of a chess match. Exhausting, but strangely satisfying.
How a QA soul sneaks into process automation
Once the initial drama of the role change had settled, I started recognising familiar patterns. My QA mindset was very much alive; it had just put on a different costume.
From “What are the requirements?” to “What actually needs to happen?”
Old QA reflex: read the requirements doc, underline vague phrases, ask questions that make everyone slightly uncomfortable.
New version of the same reflex: ignore the shiny nodes for a minute. Ask: What is the real outcome this flow is supposed to achieve? Ask again, because the first answer is usually “it sends a notification”, which is a side effect, not an outcome.
From test cases to “stories the flow must survive”
As QA, I wrote test cases: happy path, unhappy path, “the cosmos misaligned, and everything exploded” path.
With process automation, I don’t write them in the same format, but my brain still works that way. I think in stories the flow must survive:
-
The story where everything is perfect, and the demo goes smoothly.
-
The story where a third party service is down and decides to rejoin at its convenience.
-
The story where we receive the same event twice because someone hit “retry.”
-
The story where the payload changes shape without telling anyone.
From bug reports to designing how things are allowed to fail
There’s a special place in QA memory for bugs that are impossible to reproduce and leave zero traces. We all have battle stories ending with “… and of course, there were no logs.”
My QA soul looked at process automation and said, very calmly: “We are not doing that again.”
So now, when I design a workflow, I think intentionally about how it’s allowed to fail:
-
Who should find out?
-
What should we log in a language a human can understand?
-
How easy will it be, two weeks from now, to figure out what happened without needing divine revelation?
Why this matters for QAs
You can treat my story as a quirky personal journey, complete with internal drama and mythology references. Or you can read it as a sign of where our discipline is heading.
We’re seeing more and more:
-
Internal processes automated
-
Client workflows orchestrated through tools like n8n
-
Critical actions happening far away from any “Submit” button a user can see
Someone has to care about the quality of those invisible flows.
Not just “does this UI behave nicely?” but:
-
Does this automation behave consistently over time?
-
Does it fail loudly when it should, and quietly only when it’s safe?
-
Does it play well with the rest of the ecosystem, or is it secretly sabotaging other systems at odd hours?
That “someone” looks suspiciously like us. QA folks. People whose brains are wired to think in scenarios, edge cases, and real world mess, not just ideal diagrams.
An invitation to other QA souls
I didn’t wake up one day and decide, heroically, “I shall now become a Process Automation Engineer.” It was gradual, human, and chaotic. I started asking questions about the automations around the products I was testing. I reviewed existing workflows with the same curiosity I had for user stories. I helped document processes so more people could understand what was happening behind the scenes.
And eventually, I found myself not only testing flows, but designing them.
If you’re a QA at Qubika and you see process automation expanding around you, consider this less a threat and more an invitation.
You can step into that world of nodes and arrows without losing your QA soul. In fact, that soul is exactly what you should bring:
-
Your obsession with “what if…?”
-
Your respect for real users and their very real pain.
-
Your healthy distrust of anything that only works in demos.
You can change your role. You can add new buzzwords to your title. You can even spend part of your day assembling workflows instead of writing test cases.
But if you keep your QA mindset alive, that slightly stubborn, slightly dramatic inner voice that refuses to accept “it should be fine” as an argument, then the essence of what you do stays the same: helping teams build systems that behave reliably in the wild.
Perhaps the myth was never about the gods changing our roles. Perhaps it was about discovering that the soul we carried all along was exactly what the new world needed.
New role, same soul.
And honestly? That’s not a bad deal.
