QA Engineer · manual & automation

Artem Cherbaev

The first QA engineer at a US broker-dealer. I built the function, not just the tests.

Five years owning quality end to end for web, iOS, Android and microservice backends: the test strategy, the defect workflow, and 1,450+ automated UI, API and end-to-end tests gating releases in CI. I use Claude Code and MCP heavily for the maintenance work, and keep the suites themselves deterministic — a pipeline that needs a model at runtime is one nobody can reproduce.

Watch my suite run See my work
  • Curitiba, Brazil · UTC−3
  • Remote, international teams
  • English C1 · Russian native
Artem Cherbaev, smiling, in front of a green hedge
1,450+
automated UI, API and end-to-end tests, built and maintained
−60%
production defects, once the automation gated releases
2d→1d
full regression cycle, after the move to Playwright
48+
releases taken through regression, UAT and sign-off

01 Work in public

My own work, running in the open

Work done for an employer belongs to them. These are mine: public repositories, pipelines you can watch, and results nobody typed in by hand.

Test automation · featured

Agentic Playwright Suite

End-to-end, visual regression and REST API tests against a public demo storefront, in Playwright and TypeScript. Claude Code agents write and repair the tests over Playwright MCP; the pipeline itself runs no model, so every result can be reproduced.

  • Four lanes on every push: Chromium, WebKit, visual regression and the REST API
  • Every job runs in one container image, versioned from the lockfile
  • Allure reports with trend history, a suite health page and replayable traces
  • Nine defects raised against the target, each with its evidence
  • Playwright
  • TypeScript
  • Docker
  • GitHub Actions
  • Allure
  • Claude Code
  • Playwright MCP
Watch the last run Repository
Last CI run

Every push to main runs four lanes and publishes the results. They load here from the suite's own feed.

Dashboard Suite health Traces

QA workflow

Quality Lab

A small store built to be tested: Playwright UI and API tests, accessibility checks with axe-core, evidence-based failure triage and reviewed repair proposals. Switchable, deliberate defects show what the suite actually catches — and a written-up cart race shows how a real one was found.

  • Playwright
  • TypeScript
  • axe-core
  • API testing
Repository The case study

Portfolio

This site

Hand-written HTML, CSS and JavaScript: no framework, no build step, no trackers. Its own Playwright suite — pages, links, accessibility with axe, and the runner against recorded feeds — has to pass before anything is deployed.

  • HTML & CSS
  • JavaScript
  • Playwright
  • axe-core
Repository Read the CV

02 Experience

Five years, one team, built from zero

One role, start to finish: from the first test plan to a tiered pipeline of 1,450+ automated checks.

QA Engineer

Lime Trading

An award-winning broker-dealer operating in the USA

Mar 2021 – Jul 2026

The first and only QA engineer on the team, for web, iOS and Android apps and the microservices behind them. Money moves through these products, so a missed defect is never cosmetic.

−60% production defects
2d → 1d full regression cycle
4h → 1.5h authoring and triage per cycle, AI-assisted
5w → 2w junior QA onboarding
  1. Foundation

    Built the QA function from scratch

    Test strategy, test plan, entry and exit criteria, the defect workflow and the test documentation in Jira, TestRail, Qase and Confluence. Requirements and acceptance criteria reviewed before development started, with a traceability matrix from requirement to test to defect.

  2. Automation

    The first suites, in Selenium and Python

    UI and end-to-end suites from the ground up, then an API layer with Pytest and Requests against REST and gRPC services, backed by SQL checks in PostgreSQL and MySQL and Kafka and RabbitMQ message validation between services.

  3. Mobile

    iOS and Android with Appium

    Critical flows on real devices and BrowserStack across a device and OS version matrix, with the XCUITest driver — including WebDriverAgent signing, provisioning profiles and native selector stability.

  4. Migration

    Led the move to Playwright and TypeScript

    Re-architected around page objects, API-driven test data, role-based session fixtures and parallel execution, and replaced every sleep with explicit state polling — so the suite was reliable enough to gate a release.

  5. Pipeline

    Tiered quality gates in CI/CD

    Smoke on every pull request as a merge gate, full regression nightly and before each release, per-service suites on deploy to staging — in Docker against Kubernetes test environments, on TeamCity, Jenkins and GitHub Actions, reported in Allure.

  6. AI-assisted QA

    Brought Claude Code, MCP and agents into the daily work

    Test case generation, log analysis and defect triage with Claude Code, MCP, Cursor and AI agents — the maintenance work, where agentic tooling actually pays.

More from the role

Release ownership

48+ releases through regression, smoke and UAT, defects prioritised by severity and impact, and 600+ defects documented in Jira with a reopen rate under 5%.

Test design

The manual regression suite and release checklists built with equivalence partitioning, boundary values, decision tables, state transitions and pairwise testing, prioritised by risk and complemented by session-based exploratory testing.

Production quality

Kibana, Grafana, Sentry and Chrome DevTools to triage errors and crash reports, reproduce what customers reported, and trace a defect to the service responsible rather than the symptom.

Performance and security

Load and stress testing with JMeter against the trading and reporting endpoints, and OWASP ZAP scans plus manual authentication and authorisation checks before major releases.

Mentoring

Onboarded junior QA engineers and wrote the process documentation, framework guides and playbooks the team still runs on.

Traces over guesswork

Playwright traces, video and screenshots on every failure cut triage time sharply, and fed a flake history kept in Allure.

Moscow State University Bachelor of Computer Science 2016 – 2020

03 Approach

How I approach QA

Four working principles, and what each one looked like in practice.

01

A suite nobody trusts is worse than no suite

A flaky test is a defect in the test code, not background noise to be retried away. Rebuilding the suite in Playwright, I replaced every sleep with explicit state polling and moved test data setup onto the API, because the suite had to be reliable enough to gate a release before anyone would let it.

02

Testing belongs inside the pipeline, not after it

A quality gate that blocks a failing build is worth more than a report nobody opens. Smoke ran on every pull request as a merge gate, full regression nightly and pre-release, and per-service suites on deploy to staging.

03

Automate the maintenance, not only the tests

Most automation effort goes on keeping a framework alive rather than writing new coverage. Bringing Claude Code, MCP and Cursor into test generation, log analysis and defect triage took each regression cycle from about four hours of that work to an hour and a half.

04

Own the strategy, not just the tickets

Deciding what to test, in which layer, and what to stop testing is the part that needs judgement rather than throughput. I review requirements and acceptance criteria before development starts, because ambiguity is far cheaper to resolve at design than in QA.

04 Skills

Tools I reach for

Grouped the way the work is. The dark row is what I use most; everything below it I have shipped with.

Most used
  • Playwright
  • TypeScript
  • Python
  • Pytest
  • REST & gRPC
  • SQL
  • GitHub Actions
  • Docker
  • Allure
  • Claude Code
  • MCP

Web automation

  • Playwright (TS & Python)
  • Selenium WebDriver
  • Cypress
  • Page Object Model
  • Fixtures & traces
  • Parallel execution
  • Flaky-test triage
  • Framework design

API & backend

  • Pytest & Requests
  • Postman
  • Swagger / OpenAPI
  • gRPC
  • Kafka
  • RabbitMQ
  • PostgreSQL
  • MySQL
  • MongoDB
  • Test data via API

Mobile

  • Appium
  • XCUITest
  • BrowserStack
  • Real devices & simulators
  • Device / OS matrix
  • Android Studio
  • Xcode
  • Charles Proxy

CI/CD & infrastructure

  • GitHub Actions
  • TeamCity
  • Jenkins
  • Docker
  • Kubernetes
  • Linux & Bash
  • Git
  • Pipeline design

AI-assisted QA

  • Claude Code
  • MCP
  • Playwright MCP
  • Cursor
  • AI agents & skills
  • Test generation
  • Log analysis & triage
  • Testing AI features

Observability & debugging

  • Kibana (ELK)
  • Grafana
  • Sentry
  • Chrome DevTools
  • Log analysis
  • Crash & stack-trace triage

Performance & security

  • JMeter
  • Load & stress testing
  • Response-time analysis
  • OWASP ZAP
  • Auth & authorisation testing

Test design

  • Risk-based testing
  • Equivalence partitioning
  • Boundary values
  • Decision tables
  • State transitions
  • Pairwise
  • Exploratory sessions

Process & management

  • Jira
  • TestRail
  • Qase
  • Zephyr
  • Allure TestOps
  • Confluence
  • Scrum & Kanban
  • Release management

05 About

Why I test the way I do

I joined Lime Trading as its first QA engineer, on a team that had never had one. There was no process to inherit and no suite to maintain, so the first question was not what to test but what would actually go wrong, who would pay for it, and how late anyone would find out.

That is still how I decide. A bug report is cheap; the failure behind it usually is not, and the two are rarely the same size. In a trading product the expensive failures are the quiet ones — a price that renders correctly and settles wrong, a mobile build that breaks on one OS version, a message that never reaches the service downstream. Coverage follows from that rather than from the requirement list, which also means being willing to decide what not to test.

The other half of the job is maintenance. Most automation effort goes on keeping a framework alive, which is where agentic tooling actually pays, and where I use Claude Code, MCP and agents I write myself on real work rather than as an experiment. The suite above was built that way, and it is public, so none of this has to be taken on trust.

Looking for
QA Automation Engineer and SDET roles
Based in
Curitiba, Brazil · UTC−3
Works
Remote, with international product teams
Languages
English C1, Russian native
Education
BSc Computer Science, Moscow State University

06 Contact

Open to QA Automation Engineer and SDET roles

Remote, in international product teams — ideally where agentic testing tooling is part of the engineering culture rather than a pilot. Email is fastest; I usually reply within a day.

Write to me

Drafts the email in your own mail app — nothing is sent or stored by this page.

Open in your email app