“Most of my work is making release day boring. The good kind of boring.”
— me, every other FridayQA Engineer·Luxembourg·EU
Tykhon
Kozachenko.
QA at Salonkee. I write the test plans, build the automation, and hold the release gate that catches what shouldn't ship.
The full quality stack — from a manual pass on Monday to a green nightly suite on Thursday.
The shop floor
The system, in pieces.
100%
held the gate · every cut
// one helper · every checkout spec calls it · no copy-paste
Cypress.Commands.add('seedAndSignIn', (role: UserRole = 'returning_customer') => {
cy.task('db:reset');
cy.task('db:seed', { role, fixtures: 'checkout' });
cy.intercept('POST', '/api/auth/session').as('getSession');
cy.session(role, () => {
cy.apiLogin(role);
cy.visit('/');
cy.wait('@getSession');
});
});
15%
<6%
Assertions split into classes, data-test selectors
centralized, state seeded via DB tasks — not the UI.
test design & management
Jira
TestRail
Xray
Postman
Swagger
BDD / Gherkin
automation
Cypress
Playwright
TypeScript
Patrol
ai · ci · data
Claude Code
Anthropic API
GitHub Actions
Docker
Cypress Cloud
Mochawesome
Sentry
Adyen
MySQL · MongoDB
Tests are docs
that run.
Coverage map
Where the tests live.
Two suites I've been growing — a customer-facing app and an internal operator tool. Rows are ordered by depth of coverage: where I've put the most hours.
700+ tests written end-to-end regression gate on every release payments my home turf.
Three projects
What I'm most proud
of building.
/01
From 80 to 700+ tests · two products · one architecture.
Inherited a thin Cypress suite on one product. Rebuilt the
infrastructure end-to-end — POMs, dedicated assertion classes,
centralized data-test selectors, DB-task state
seeding across MySQL and MongoDB.
Result: 700+ tests across both suites, full nightly sweep under two hours, flake down ~60% from the refactor baseline. The next 700 tests cost less than the first 200 — and most of them are written by the engineers themselves now.
- Cypress · TypeScript
- Page Object Model
- Nx workspace
- GitHub Actions · self-hosted
- Cypress Cloud
/02
QA tooling, built on Claude.
Internal workflows on the Anthropic API and Claude Code: test-case drafting from Jira tickets, PR-review assistants, coverage-gap detection over the Cypress tree. Small CLIs, thin wrappers, no platform team needed.
Picked up across QA and engineering. The point isn't magic — it's removing the parts of the day that don't earn their keep.
- Anthropic API
- Claude Code
- Node CLI
- Prompt engineering
/03
Sole QA on a payments product, from day one.
Pulled in as the only QA on a new payments product. Owned the strategy, manual plans, E2E scope, release-readiness criteria — all of it, on a blank canvas.
Adyen integration, POS terminals, Tap to Pay (iOS + Android), expense management, internal transfers. Every release passes through a gate I built.
- Adyen
- POS · Tap to Pay
- PCI-aware testing
- Financial flows
Beyond the suite
More than automation.
Automation is the visible artifact. The real work is upstream: the plans, the manual passes, the release rhythm, the conventions, and the conversations that keep the team out of the bug-fix loop in the first place.
Strategy & manual depth
Full test plans for new flows. Risk-based prioritization across releases. Exploratory passes where automation can't go yet — the questions that haven't been asked. The plan ships before the code does.
- Test strategy
- Exploratory
- Risk-based
- UAT · BDD
Release management
Bi-weekly production cycles — regression sign-off, release readiness, post-release monitoring. The gate is mine to hold; multiple critical bugs caught per release before users see them. Boring releases are not an accident.
- Release sign-off
- Regression cycles
- Post-release monitoring
- Sentry · Slack
Automation that holds
POMs, dedicated assertion classes, centralized
data-test selectors, DB-task state seeding.
Conventions written down so the next 700 tests cost less than the
first 200 — and the team can write them without me in the room.
- Cypress · Playwright
- POM · TypeScript
- CI · self-hosted
- Flake-resistant
Cross-team enablement
Onboarding docs, contribution guides, PR reviews, training sessions, pair work. Engineers write their own tests because the conventions are written down and someone's around to pair when they're stuck. The goal is never to be the only QA who can do this.
- Docs & guides
- Training
- PR reviews
- Pair sessions
How I work, underneath
Three habits, not rules.
-
/01
Tests are documentation that runs.
If a teammate can read the spec and tell me how the feature works, half the battle is already won. The other half lives in a green CI badge — the kind that no one has to investigate at 5pm on Friday.
-
/02
The best gate is one engineers built with me.
I don't catch bugs by standing at the end of the sprint. I catch them by making it cheap and obvious for everyone to write the test as they ship the code. A regression gate the team owns together holds longer than one I enforce alone.
-
/03
Boring releases are honest releases.
When Friday's deploy is a non-event, it means the conversations happened earlier in the week — in design review, in PR comments, in a quick call before anyone wrote a Jira ticket. The drama I prevent never makes the changelog.
Working with me
How I show up.
Async by default
I write things down before I talk about them. Writing forces clarity, lets teammates engage on their own clock, and means the work survives me being out for a day.
Listen, then recommend
The best gates I've built started as conversations, not Jira tickets. Three questions before any opinion — about the constraint, the user, and the thing that already broke last quarter.
Calm under deploys
When releases get tense, I try to lower the temperature — usually by being the person who already drafted the rollback plan. Steady beats loud in a war room.
Curious sideways
Payments, fintech, mobile, AI inside QA — I pick up adjacent domains because they make the next gate cheaper to build. Tools, not titles.
Inbox open
If something here
landed for you.
Mail's the fastest. The CV expands the story; the rest is just where the conversation continues.
Email tykhonkozachenko@gmail.comT.