Yurii Simashkevych

Available for new work · Wrocław and remote

Your releases shouldn’t wait for testing.

I help engineering leaders at software companies clear regression bottlenecks and get automated checks they can trust, without rebuilding their QA function. I’m Yurii, an SDET and QA lead with twelve years in banking and software companies.

Start with a focused two-week assessment of one product. You get evidence of your biggest risks and a practical plan. Hands-on help afterwards is optional.

Discuss your release bottleneck See the assessment
Green that means something.

Things I hear in my first week on a team

  • “Just re-run it, that test is flaky.”
  • “We can’t release on Friday, QA isn’t done.”
  • “How did that bug get to production?”

If one of these sounds like your team, an assessment will show you why it happens and what to fix first.

Start with a two-week assessment

It stands on its own. You keep the findings and the plan, and any further work is optional.

Two weeks · one product

Quality assessment

I look at how one product is tested and released: strategy, suites, CI history, flaky tests, environments, and how release decisions are made.

You get
Your three biggest quality risks with evidence, and a 90-day plan in priority order.
I need
Read access to the code, CI and bug tracker, and time with the people who build and test the product.
Not included
Changes to your code or tests. Those are follow-on work, if you want them.
You decide
What to fix first, and whether to do it yourselves, hire, or bring me in.

If you want help after that

Hands-on work that follows from the plan. If you already know exactly what’s wrong, we can start here instead.

  1. 01

    Test automation build

    A Playwright and TypeScript framework shaped around your product: semantic locators, fixtures, test data through APIs, traces, sharded CI.

    You get your critical journeys as a merge gate, and engineers who can maintain it without me.

  2. 02

    Manual to automation

    I’ve done this twice: leading it once and co-leading it once. It’s a people change more than a tooling one: pairing, risk-ordered coverage, and keeping what your testers know.

    You get a faster regression cycle, and a team that owns its tests.

  3. 03

    API and data testing

    REST, GraphQL and SOAP suites, contract tests, and data integrity checks, including migrations between databases.

    You get fast checks below the UI that catch backend regressions early.

  4. 04

    CI gates and flaky tests

    Gates that are fast and trusted. Retries that report instead of hide. A quarantine with owners and expiry dates.

    You get a green build people believe, and a flaky rate that goes down.

  5. 05

    Fractional QA lead

    Part-time quality leadership while you grow: test strategy, release readiness, metrics, hiring loops, mentoring.

    You get senior QA leadership a few days a month, and a plan to hand it over.

What changed on teams I worked with

Stories from my employment, not consulting work. The details are under NDA, so I describe what changed instead of quoting figures.

Software company · 2022–2025

From a manual process to a QA team of seven

Before
Legacy manual process, regression done by hand, slow feedback on every fix.
What I did
Moved the team to TypeScript with CodeceptJS and Playwright, became technical lead for the new stack within two months, and made the suites a quality gate in Bitbucket Pipelines.
After
Fixes got feedback much sooner, because re-testing ran in the pipeline instead of by hand. I then grew and led a QA team of seven, with shared coding standards and code review.

Investment bank · 2018–2021

Regression automation for securities data

Before
A large manual regression suite on a regulated financial data platform.
What I did
Co-led the quality strategy, built a Java suite with Selenide and TestNG, a C# SOAP API suite, and later a tool to verify data integrity during a SQL to MongoDB migration.
After
Far less manual regression work, and shorter testing cycles during the migration.

How an engagement runs

No 80-page reports. The first two weeks stand alone. Everything after that is your choice.

  1. Weeks 1–2

    Assess

    Talk to the people who build and test the product. Read incidents and CI history.

  2. End of week 2

    Decide

    We go through the three risks and the 90-day plan, with measures such as release speed and escaped defects. You can stop here.

  3. If you continue

    Build it with your team

    Hands-on in your codebase, pairing with your engineers, so the knowledge stays.

  4. Handover

    Leave it running

    Standards, routines and metrics your team runs without me.

What I believe about quality

  • The whole team owns the tests. SDETs lead the end-to-end layer and coach. Everyone writes and fixes tests.
  • A flaky gate is worse than no gate. Reliability before coverage numbers, every time.
  • Test at the lowest useful layer. Business rules belong in unit and API tests, not in slow browser journeys.
  • Measure the system, not the people. Time to feedback and escaped defects. Never bugs per tester.
Yurii Simashkevych

About me

I started in QA in Lviv in 2013, moved to Wrocław, and spent years testing securities trading and data platforms for an international investment bank. Then I moved to software companies, where I built UI and API automation from scratch and led a QA engineering team.

I like the unglamorous parts: a flaky test tracked down to its root cause, a manual checklist retired because the suite finally covers it, a manual tester writing their first Playwright test.

M.S. in Information Security, ISTQB Foundation. I work in English and Polish.

TypeScriptPlaywrightJavaGoC#GraphQLRESTSQLMongoDBKafkaGitHub ActionsDocker

LinkedIn GitHub

Read my code before you hire me

Open-source examples of how I build test automation.

Tell me what’s slowing your team down.

Email me and we’ll set up a free 30-minute call to work out whether an assessment makes sense for you. No pitch deck.

yurii@yuriisimashkevych.com

Or message me on LinkedIn. I reply within one working day.