How I Work

I’m Artem — QA and Agile Delivery consultant working with engineering teams across the world. Testing is one step in a much longer pipeline — from idea to code to release to customer. Most teams fix the testing step. The real problem is upstream — in the decisions made before anyone writes a line of code, in how quality is understood at the leadership level, in what “done” actually means across the org. I change that understanding. Everything downstream — the builds, the releases, the customer experience — changes with it.

The method

I start with the system and the team behind it. You tell me what you think is broken. The team tells their story. The process shows a third one. I collect all three, find where they diverge, and write down what’s actually broken and why — in plain language, so it can be argued with, referenced and acted on after I’ve left. Then we change the things the assessment says to change.

Findings come with evidence attached — the file, the pipeline stage, the ticket. A claim you can’t check is an opinion, and you can get those for free.

I’ve done this inside a games studio coordinating releases across offices in Europe, the USA and Australia, a B2B publishing platform through a monolith-to-services rebuild, and a consultancy running quality across several client engagements at once. The domain changes. The structural failures repeat.

On AI in the pipeline

Every team is currently being told to put AI in their QA. Most of what’s being sold is a demo. What holds up in practice is narrower and duller: workflows that read your actual tickets, acceptance criteria, pull requests and test cases, and hand a person a finding grounded in the source — file and line, not vibes.

I build those with the decision point left where it belongs. The workflow assesses and reports; a person decides what merges, what gets blocked and what ships. The one I co-developed with a QA colleague and the engineering teams around us runs against real tickets in a live delivery pipeline rather than a sandbox — which is mostly how you learn which parts don’t work.

Who I work with

Engineering managers, heads of engineering and CTOs at companies where QA has stopped working — usually after a growth phase, a reorg or an acquisition. Teams of 2 to 200 engineers are the sweet spot: small enough to move, large enough to have the structural problems worth solving.

I work remotely with clients across time zones — most engagements run without a single on-site visit.

If that sounds like your team, get in touch.