Kraków, Poland

Mykola Khytra.

Senior QA Engineer who makes releases boring.

Manual, API, and automated testing. Product risks, exploratory testing, and confident release decisions.

AI-assisted QA Claude Code & Codex for test design, debugging, and documentation. See the workflow

5+years in QA
11k+scenarios in a shared test ecosystem
Up to 4×faster execution for CI jobs
QAmanual + automation

About

Quality is a
shared signal.

Mykola Khytra outdoors, wearing a hat and glasses

Five years across manual, general, and automation QA, with experience testing web applications, desktop software, APIs, and WebSockets.

The work spans the testing lifecycle: understanding product risks, designing tests, exploring behavior, reporting defects, validating releases, and building maintainable automation. AI-assisted workflows support analysis, test design, and implementation.

Expertise & tools

The right approach
for the risk.

Manual exploration, API checks, and maintainable automation across the QA lifecycle.

Manual & product QA

Exploratory, functional, smoke, and regression testing. Test design, clear defect reports, and release validation.

Test strategyTestRailTestomat

API & integration QA

API and WebSocket testing, business rules, error handling, and defect investigation. Jest, Vitest, and Axios for automated API checks.

PostmanSwaggerREST APIsAxiosJestVitest

Automation & delivery

UI automation with Playwright and TypeScript. Reusable test code, faster CI feedback, and failure diagnostics.

PlaywrightTypeScriptJavaScriptCircleCIGitHub ActionsGitDatadog

AI-assisted QA

Practical AI.
Verified results.

Daily use of Claude Code and Codex for repository analysis, test design, automation code, debugging, and documentation.

Understand the context

Explore repositories, develop test ideas, and investigate failures with AI assistance. Product risks and existing behavior guide the questions.

Build and improve

Draft and maintain test code, refactor shared utilities, and prepare documentation. Use agents to support repeatable QA work and problem analysis.

Check the result

Review proposed changes, run relevant checks, and verify behavior manually where needed. Technical judgment stays with the engineer.

Selected work

Less waiting.
Better signals.

Selected automation and process improvements from Shelf, alongside the wider manual and general QA experience described below.

01CI performance

60 minutes → 15

Parallel execution and multiple workers sped up many regression CI jobs by up to four times.

TypeScriptCircleCI
Read the CI case
02API regression

From manual to repeatable

Built nearly all automated API checks for one project, with reusable clients, fixtures, and test data.

REST APIsAxios
Read the API case
03Shared engineering

Automation at team scale

Maintained and evolved a shared ecosystem of 1,200+ specs and 11,000+ API and UI scenarios.

Code reviewObservability
Read the team case
01 / Faster regression feedback

Make the wait shorter, not the checks weaker.

Context. Long-running regression CI jobs slowed down the feedback cycle, while overnight regression workflows needed ongoing maintenance.

My contribution. Applied parallel execution across many CI jobs, using multiple concurrent workers and other optimizations. Separately, maintained overnight regression workflows for roughly 30 of around 70 CI jobs and investigated failures through logs and test artifacts.

Result. Up to four times faster execution across optimized CI jobs, including a runtime reduction from approximately 60 minutes to 15. These improvements covered many CI jobs, not all jobs or the entire delivery pipeline.

02 / Repeatable API regression

Shared foundations before more test code.

Context. One company project relied on manual API regression work that could be made repeatable.

My contribution. Built nearly all of its automated API checks, using reusable Axios clients, fixtures, helpers, and explicit test-data setup and cleanup.

Result. Reduced repeated manual regression work and left a maintainable basis for future checks.

03 / A test ecosystem people can maintain

Useful failures need shared ownership.

Context. A TypeScript ecosystem with 1,200+ specs and 11,000+ API and UI scenarios, shared by roughly 10–15 QA engineers, automation engineers, and developers across teams.

My contribution. Maintained and refactored shared code, reviewed changes nearly every day, helped QA engineers and developers use the framework, and created a Datadog dashboard for execution monitoring.

Process ownership. Independently migrated test case management from TestRail to Testomat and created documentation, guidelines, and automation standards.

Result. Better execution visibility and a more consistent way to maintain automation and test case management. The suite size describes the shared ecosystem, not tests authored by me alone.

Experience

Across the QA
lifecycle.

Full experience in my CV PDF
  1. Jan 2024 – Jul 2026 · Shelf · Remote

    Senior Automation QA Engineer

    Shared automation, CI optimization, API coverage, code reviews, and an independent TestRail-to-Testomat migration.

  2. Oct 2022 – Jan 2024 · Shelf · Lviv

    Hybrid QA Engineer

    Combined manual product testing and API checks with TypeScript automation, Playwright, Jest, and CircleCI.

  3. Nov 2021 – Oct 2022 · Shelf · Lviv

    Junior QA Engineer

    Manual, API, and WebSocket testing, test documentation, defect reporting, and investigation.

  4. Apr 2021 – Oct 2021 · StarApps · Lviv

    Trainee QA Engineer

    Manual web and desktop testing for EV charging and energy-related products.

How I work

Evidence over opinion.

Risk first

Start with what can hurt users or the business, not only what is easiest to automate.

Make failures useful

A failed check needs enough context to reproduce, investigate, and decide what to do next.

Leave it maintainable

Clear fixtures, documentation, and a debuggable pipeline matter after the original author moves on.

Engineering notes

Three things
worth asking.

Practical ideas behind everyday quality decisions.

Quality engineering

Is this test worth keeping?

A useful check protects an important behavior and produces a failure someone can act on. If it is flaky or costly to maintain, fix its foundations or reconsider what it is testing. A bigger suite is not automatically a better one.

Exploratory testing

What does a script miss?

Exploratory sessions follow questions: where do users get stuck, which assumptions fail, and how does the product handle unusual states? Findings become reproducible defects, new test ideas, or candidates for automation.

CI/CD

What does green actually mean?

Only that the checks which ran passed. Trust also depends on what they cover, what was skipped, how failures are investigated, and whether the result arrived soon enough to influence a decision.

Contact

Let’s talk
about quality.

Need help with product quality? Let’s discuss manual testing, API coverage, release validation, and AI-assisted automation.

Manual, general, and automation QA.

Based in Kraków · Open to remote roles