Andriy Moiseyenko QA Automation Engineer

Quality engineering · Ottawa, Canada

QA Automation Engineer with a developer's perspective.

I build quality systems for products that need to be understood beyond the interface — across devices, APIs, backend behaviour, data flows, and ML-driven decisions.

View selected work Start a conversation Download resume ↓
  1. 01 Automation architecture

    Frameworks shaped around the system, not inherited by habit.

  2. 02 APIs and backend behaviour

    Contracts, state, access, persistence, and negative paths.

  3. 03 AI/ML system validation

    Forecast quality examined as both data and product behaviour.

  4. 04 Performance and reliability

    Scenarios, thresholds, diagnostics, and reproducible evidence.

  5. 05 Product development

    First-hand understanding of the systems behind the interface.

The system beneath the surface

Quality begins before the first test runs.

I start by building a working model of the product: what it promises, how its layers communicate, where uncertainty enters, and which failures would matter most.

  1. 01

    Understand the system

    Trace the user journey, services, data, environments, and delivery path until the visible behaviour has an explainable structure.

  2. 02

    Locate meaningful risk

    Turn requirements, boundaries, state transitions, and unknowns into a deliberate testing strategy rather than an indiscriminate inventory.

  3. 03

    Apply pressure with purpose

    Exercise negative paths, integrations, permissions, devices, performance profiles, and model behaviour where the system is most likely to reveal its truth.

  4. 04

    Create clear evidence

    Build automation, diagnostics, and CI feedback that help a team understand what failed, why it matters, and whether the product is ready.

Selected work

Systems understood in depth.

Case 01

Professional system

BluWave AI

Quality architecture for AI-powered energy products

At BluWave AI, I own the testing approach across web and mobile interfaces, APIs, backend services, data workflows, and forecasting behaviour.

Context

A growing product surface needed more than isolated automated checks. It needed coherent quality foundations built from first principles: useful coverage, reliable environments, readable evidence, and methods suited to both deterministic software and model-driven behaviour.

Response

  • Architected dedicated automation foundations for UI and mobile testing with WebdriverIO, Appium, and Mocha; API regression with Bruno and Postman/Newman; SOAP/XML services; and performance, load, and soak work with k6 and Locust.
  • Integrated suites into Dockerized Jenkins pipelines with environment resolution, secure configuration, normalized reporting, and Jira/Xray result publishing.
  • Designed risk-based API coverage across authentication, access control, CRUD workflows, filtering, persistence, schemas, status behaviour, negative paths, and deterministic cleanup.
  • Validated forecasting quality through scenario-based testing and measures including MAE, RMSE, MAPE, correlation, bias, peak miss, and lag, connecting statistical behaviour to product expectations.
  • Traced failures across logs, API responses, dashboards, devices, data, and CI evidence to give developers and product owners a clear engineering signal.

Demonstrates

  • QA strategy ownership
  • Automation architecture
  • AI/ML validation
  • Performance engineering
  • Cross-layer diagnosis

Case 02

Professional system

Canada Revenue Agency

Turning negative paths into a reusable testing capability

At the Canada Revenue Agency, I developed Java automation with Selenium and TestNG for federal web applications and helped shape test design for a key initiative.

Context

Regression coverage needed to remain repeatable while requirements, edge cases, and delivery decisions continued to evolve across an Agile team.

Response

  • Translated user stories and acceptance criteria into focused approaches and reusable automated scenarios.
  • Created a negative-testing framework that made edge-case exploration systematic instead of case-by-case.
  • Integrated automation into Jenkins, reviewed run evidence, triaged failures, and worked directly with developers on resolution.
  • Coordinated test design and automation structure with stakeholders while reviewing work and mentoring junior testers.

Demonstrates

  • Java automation
  • Negative testing
  • CI/CD feedback
  • Technical leadership
  • Collaborative delivery

Case 03

Product ownership

Independent product

The product behind the tester

Young Mystic is a multilingual, mobile-first essential-oil library used by more than 200 people — designed, built, and evolved as a complete product rather than a portfolio exercise.

Context

The product combines a calm consumer experience with authentication, structured editorial content, multilingual delivery, content management, and carefully bounded offline behaviour.

Response

  • Built the application with SvelteKit, MongoDB, and Sanity, including authentication, account flows, server-side data boundaries, and a nontechnical publishing workflow.
  • Designed the PWA and mobile experience around fast navigation, resilient public metadata, safe offline fallback, and clear separation from authenticated premium content.
  • Maintained the product across architecture, UX, content modelling, security decisions, localization, browser QA, and deployment rather than treating development as a one-time handoff.

Demonstrates

  • End-to-end product thinking
  • Application architecture
  • Authentication and data boundaries
  • PWA reliability
  • Long-term ownership
View source ↗

Developer’s perspective

I know where systems break because I know how they are built.

Building complete products changed the way I test them. An interface is never only an interface: it is a contract with state, services, data, permissions, content, devices, and deployment decisions behind it.

That perspective lets me move naturally between a user-visible symptom and the layer that produced it — and lets me build automation that reflects the actual architecture instead of merely replaying steps.

Selected builds

Products are part of the evidence.

01

Guided by Scent

A calm mobile-first digital home built with SvelteKit and Sanity, replacing a long service page with a clear route-based product experience.

Content modelling, responsive art direction, resilient CMS fallbacks, route transitions, and browser verification across WebKit and Chromium.

View source ↗
02

Alex Healing

A social-first personal platform with a universal content architecture and a deliberately simple Russian-language editing experience.

SvelteKit, Sanity, backward-compatible content modelling, mobile atmosphere, and touch behaviour refined without destabilizing layout geometry.

Visit live site ↗ View source ↗

Working range

Tools in service of judgement.

Automation systems

I choose and shape frameworks around the product surface, the team, and the evidence a release decision actually needs.

  • Java · Selenium · TestNG
  • WebdriverIO · Appium · Mocha
  • Cypress · Playwright

Interfaces and services

I test beyond happy-path responses: identity, authorization, state, persistence, cleanup, contracts, and failure behaviour.

  • REST · Bruno · Postman/Newman
  • SOAP · XML
  • Backend and data workflows

Performance and models

I treat performance and forecasting as observable behaviours that require designed scenarios, thresholds, and diagnostics.

  • k6 · Locust
  • Load · soak · performance
  • MAE · RMSE · MAPE · bias · lag

Delivery and diagnosis

Automation becomes valuable when it survives environments, runs consistently, and leaves a team with a clear signal.

  • Jenkins · Docker · Git
  • Jira/Xray
  • Logs · devices · CI evidence

Product development

I build production-minded web systems, which gives my quality work architectural context and respect for the user experience.

  • SvelteKit · TypeScript · JavaScript
  • MongoDB · Sanity
  • PWA · Vercel · responsive UX
Andriy Moiseyenko outdoors
Outside the test plan

Curious about how things work. Serious about how they affect people.

About

Precision is a form of responsibility.

I am most engaged when a system is unfamiliar, consequential, and worth understanding properly. I like finding the structure inside ambiguity, turning it into a practical testing method, and leaving the team with something clearer than I found.

My path includes software development, infrastructure support, and a Master of Pharmacy. Different disciplines, same instinct: details matter because people eventually live with the result.

I care about technical correctness and about how a product feels in a person’s hands. For me, quality includes both.