Technical Skills Matrix

Area Core Technologies & Methodologies
Strategic QA Leadership & Engineering Governance Automation & Test Infrastructure Architecture, Release Gate Qualification, Test Determinism & Flake Elimination, Shift-Left Strategy, Cross-Functional Technical Reviews, Team Mentorship, Quality Strategy, System Qualification, Release Planning, Requirement Traceability Matrix (RTM), TestIt, PlanIt, Jira
Automation & Programming Python (advanced automation & scripting), Custom Python Frameworks, Playwright, Pytest, Selenium WebDriver, REST API Validation, Fault Injection & Service Virtualization, Custom Service Emulators (Flask, http.server), Process-Level Test Isolation, Static Analysis Gating (Pylint), Go (Golang), JavaScript (ES6+), HTML5, CSS3, Shell/Bash Scripting
Backend Verification & Databases PostgreSQL, MSSQL, Oracle SQL, MySQL, Apache Cassandra, ElasticSearch, Data Integrity Testing, Backend Automation
Networking & Security Infrastructure TCP/IP, UDP, IPsec, DNS, TLS/SSL, SSH, SIP, HTTP/S, Wireshark (deep-packet analysis), cURL utilities
Infrastructure & DevOps Docker, Jenkins Agents, GitHub Actions, Cross-Platform CI Matrices (Linux/Windows, multi-version Python), Git, AWS (EC2), VMware, VirtualBox, VM Deployments
Operating Systems & Environments Linux (RHEL, Ubuntu, CentOS, Oracle Linux), Windows, macOS
Intelligent Tooling & Data Science scikit-learn (test prioritization & flaky-test detection), Pandas, NumPy, custom log-parsing utilities, LLM-assisted debugging, agentic workflows, prompt engineering, Grafana telemetry

Selected Engineering Outcomes

Every outcome below is verifiable in source rather than self-reported - the Evidence column opens the project it belongs to.

Measured Impact
Zero flaky failures across the pipeline's entire 27-run history. All eight failures resolved to a named cause: five to one real mobile-layout defect the suite caught on its first run at a 390px viewport, three to the same cross-repository ordering race, where a site and its test framework were deployed out of step. None was retried away, and the eight runs since are green.
Diagnosis moved off the developer's machine. Each failure ships a screenshot, the rendered DOM, a replayable trace, and an LLM root-cause verdict, so a red build is read rather than reproduced - all three infrastructure failures above were diagnosed from the CI log alone, which named the colliding elements outright.

Full write-up: Case Study - Making a CI Signal Trustworthy.

Outcome Evidence
Eliminated a class of false CI failures. Gated the suite on deployment settlement - no in-flight Pages run, then a repeated ETag - instead of trusting an HTTP 200. A half-propagated CDN had been timing out locators that were never broken. Web Automation
Cut runner spend without cutting coverage. Cancel-on-supersede concurrency collapses a commit burst into roughly one suite execution. The policy is deliberately inverted where an external API quota, not compute, is the scarce resource - there runs are serialized instead. Web AutomationAI Assisted Rest API
Built self-extending suites. A crawler discovers the route surface at collection time; one entity dataset fans out across every suite that requests it. Publishing a page or adding an entity grows coverage with no test edit. Web AutomationAI Assisted Rest API
Reduced time-to-resolution on red builds. Each failure ships a screenshot, the rendered DOM, a replayable Playwright trace, and an LLM root-cause verdict - diagnosis happens from the CI artifact instead of a local reproduction. Web Automation
Made quality gates blocking, not advisory. Static analysis runs at a hard 10.00/10 threshold before any browser starts, so a regression fails the pipeline rather than accumulating in a log nobody reads. Web Automation
Wired event-driven cross-repository regression. A front-end deploy dispatches an event into a separate automation repository, which waits for propagation and re-validates the live site unattended. Portfolio WebsiteWeb Automation
Found and fixed a real defect with the suite. A mobile overflow assertion caught a 398px document inside a 390px viewport on its first run, traced to two independent CSS causes - both since corrected and now regression-covered. Portfolio Website
Published reusable fault-injection infrastructure. A containerized HTTP error-code simulator plus a dependency-free emulator with server-lifecycle controls, letting suites reproduce specific 4xx/5xx conditions and hung-backend timeouts on demand. HTTP Emulators
Made self-terminating software deterministically testable. The fault-injection emulators had no tests, and the obvious reason is that they are hostile to testing: their control codes stall the process for two minutes, drop the listener, or exit non-zero mid-request. A shared server would have made every result depend on which destructive test ran first. Each test now owns a subprocess on an ephemeral port, readiness comes from polling the socket rather than sleeping, and the two-minute stall is asserted through a short client-side timeout instead of being waited out. 93 tests, green on the first run across Ubuntu and Windows against Python 3.12 and 3.14. HTTP Emulators
Proved the isolation rather than assuming it. Collection order is randomised on every run and CI does a second pass under a fixed seed, so a suite that only passes in one order fails instead of passing by luck. Static analysis, gated at 10.00/10 ahead of the tests, also surfaced a latent defect in the emulator itself: a control path referenced a listener that could be unbound, raising a NameError instead of performing its documented restart. HTTP Emulators
Cut the published container 8.6x and proved the reduction holds. The image shipped on a full Debian base with the pip cache retained and an unrelated log file baked in, and its .dockerignore sat outside the build context, so Docker never read it - a rebuild from a working directory would have copied a 528 MB local virtual environment into a public image. A slim base plus ignore rules scoped to the context root took the published download from 397 MB to 46 MB. Confirmed by rebuilding from a deliberately dirtied context and asserting the artifact still held only the application and its seven-package dependency closure. HTTP Emulators
Closed the gap between what the page claims and what is actually true. Proving the image was minimal on the day it was built proves nothing about the day after, and a figure typed into prose stops being true the first time the thing it counts changes. Neither failure is visible from a browser - the tab still renders, the link still resolves, the number still looks like a number - so the page would go on advertising claims nothing had checked since the day they were written. The suite now reads the published image straight from the registry, resolving a pull token, the platform manifest and the layer metadata to confirm the installed dependency closure still matches; and it reads the suite-size figures back off the page to compare them against the suite that is running. Registry access is kept off the deployment path: a third party has no business gating a deploy signal. Web AutomationHTTP Emulators
Audited the audit, and found it was checking 2 links out of 16. A green link-integrity test proved nothing: role-based locators skip elements hidden from the accessibility tree, and in a tabbed layout every inactive panel is hidden, so only the header and footer were ever inspected. Caught by measuring coverage instead of trusting the passing result. The check now resolves all 16 targets, prefers HEAD with a GET fallback, paces requests per host after rate limiting was traced to the check itself, and runs on a schedule so no deploy waits on a third party. Web Automation
AI Assisted Rest API
Repo apolskiy/CountryWeather
Tagline Resilient, data-driven REST API test framework with response-time SLA gates and AI-assisted engineering conventions
Overview A Python REST API automation framework validating two independent public services - REST Countries v5 and Open-Meteo v1 - from one shared architecture. Entity data lives in a single source of truth (test_data/master_entities.json) that a pytest_generate_tests hook expands across both suites, while a centralized client layer absorbs the network reality of testing live third-party APIs: burst limits, transient gateway errors, and latency regressions.
Key Features & Highlights
  • Single Source of Truth & Dynamic Parametrization: Any test in any module that declares an entity parameter is automatically parametrized across every record in master_entities.json, with the entity name as the test id. Five entities currently expand nine test functions into 33 executed cases; adding a country grows both suites with no test edit.
  • Network Resilience: A centralized ApiClient retries connection and timeout failures plus HTTP 429/502/503/504 with exponential backoff (retry_backoff * 2**attempt), deferring to the server's Retry-After header when present.
  • Proactive Rate-Limit Pacing: Beyond reactive retries, the client enforces a minimum interval between the start of consecutive requests across the whole session, so the suite never bursts past the v5 API's short-window limit in the first place.
  • Performance SLA Gates: Every call is asserted against a per-environment max_response_time (5.0s countries, 3.0s weather). Only the successful attempt is timed - backoff and failed-attempt time are deliberately excluded, so a retry storm cannot be misread as server latency.
  • Typed Schema Validation: Responses are parsed into dataclass validators through explicit from_dict factories that check field presence and type before construction, normalizing the v5 object model so tests keep a stable shape. Presence-only assertions are rejected by convention.
  • Quota-Aware CI (Deliberately Inverted Concurrency): Runs are serialized account-wide under a branch-agnostic concurrency group with cancel-in-progress: false - the exact opposite of the cancel-on-supersede policy used where runner minutes are the scarce resource. Here the constraint is an external shared quota, not compute: a per-branch group would let two branches race the same rate limit, and cancelling an in-flight run would spend quota on a result nobody reads. The scarce resource dictates the policy.
  • One Entry Point: A Makefile owns the pytest invocation and artifact layout, so make test executes the identical command locally and in CI, emitting JUnit XML, a self-contained HTML report, and Allure results in one run.
  • AI-Assisted Engineering: Framework conventions - externalized datasets, mandatory schema validation, typed signatures, Google-style docstrings - are codified as machine-readable rules in .claude/rules/, with .claude/skills/CLAUDE_LOG.md recording the architectural decisions and their rationale.
Tech Stack
  • Core: Python 3.14, Pytest 9.0.2, Requests 2.32.5, REST Countries v5 & Open-Meteo v1
  • Architecture: pytest_generate_tests data-driven parametrization, YAML-configured environments (PyYAML 6.0.3) injected via fixtures, dataclass schema validators, bearer auth read from the environment
  • Reporting: Allure Pytest 2.16.0, Pytest HTML 4.2.0, JUnit XML
  • CI/CD: GitHub Actions on Ubuntu runners, Make-driven execution, selectable suite via --env=countries|weather, Allure CLI report generation
CI / Build Status CountryWeather CI Pipeline status
Documentation Full project README
Portfolio Website
Repo https://github.com/apolskiy/apolskiy.github.io
Tagline Responsive software QA portfolio & live target application for automated E2E testing
Overview A hand-written personal portfolio site showcasing frontend fundamentals and quality engineering work. Every page is authored in semantic HTML5, CSS3, and vanilla ES6+ JavaScript with no framework and no build step - the sources are served exactly as committed. Hosted on GitHub Pages, the site is both an interactive professional showcase and the live target application for the PlaywrightAPWebsiteAutomation end-to-end regression suite.
Key Features & Highlights
  • Zero-Dependency Frontend: No framework, bundler output, or third-party runtime - one stylesheet and one script drive the entire page.
  • Single-Page Tab Routing: Vanilla ES6+ DOM manipulation swaps data-tab panels in place across six tabs, with no page reloads and no router library. A standalone case-study page sits alongside it as a real second document, reached by an ordinary relative link.
  • Cross-Tab Citations: Each engineering outcome cites the project it can be verified against, and the citation opens that project's tab rather than leaving the site. These controls carry a button role instead of being anchors, because every anchor here must resolve to an absolute target or another page of the site, and a bare fragment is neither. Keyboard activation is part of the contract, not an afterthought.
  • Anti-Spam Obfuscation: Every outbound URL and the contact address ship as Base64 payloads (data-h / data-e) and are decoded into real anchors on DOMContentLoaded, so scrapers never read them from the markup; a <noscript> fallback keeps the site reachable without JavaScript.
  • Responsive Layout: A CSS Flexbox tab strip plus a max-width: 600px breakpoint that wraps the navigation and restructures the skills matrix for mobile viewports.
  • Continuously Verified: Each push runs the GitHub Pages build-and-deployment job, and the deployed page is then re-validated end to end by the Playwright suite in the Web Automation tab.
Tech Stack
  • Frontend: Semantic HTML5, CSS3 (Flexbox, media-query breakpoint), JavaScript (ES6+, DOM manipulation, Base64 decoding)
  • Hosting & Deployment: GitHub Pages (pages-build-deployment), Git
  • Quality: Validated in CI by the Playwright / Pytest E2E suite
CI / Build Status Portfolio Website GitHub Pages build and deployment status
Documentation Project README
Web Automation
Repo https://github.com/apolskiy/PlaywrightAPWebsiteAutomation
Tagline Production-grade Playwright & Pytest E2E suite with dynamic site crawling, AI failure triage, and Allure reporting
Overview An E2E web automation and dynamic route-discovery framework built in Python with Playwright and Pytest. It runs functional, layout, and cross-viewport regressions against https://apolskiy.github.io/, generating its own route list at collection time so the suite grows with the site instead of being hand-maintained.
Key Features & Highlights
  • Page Object Model (POM): Strict encapsulation - test modules contain no selectors and never touch a Playwright Page directly, so a markup change is absorbed by the Page Object alone.
  • Dynamic Site Exploration: An async Playwright crawler renders each page in a real browser (the target publishes its links as Base64, so an HTTP-only crawler would discover nothing), walks the site breadth-first under depth and page-count limits, and writes reports/sitemap.json - the artifact that parameterizes a health check per discovered route.
  • AI-Powered Failure Triage: On an assertion failure the rendered DOM snapshot is sent to Claude for a structured root-cause verdict attached to the Allure report. The inspector is strictly advisory: a transport or credential problem degrades to "no report" rather than failing the run.
  • Cross-Viewport Coverage: Every layout rule is asserted on both sides of the site's 600px breakpoint - desktop 1920x1080 and mobile 390x844 - including sideways-overflow checks at each size.
  • Deployment Resilience: Before any browser context launches, CI polls the site repository's Actions API until no Pages deployment is in flight, then waits for the served ETag to repeat across consecutive polls - an HTTP 200 alone is no proof of freshness, and testing a moving CDN target is how a passing locator times out mid-run.
  • Concurrency Control & Runner-Cost Efficiency: Concurrency groups scoped by workflow, event, and ref with cancel-in-progress: true. During a rapid commit cycle each new push cancels the superseded run instead of queueing behind it, so a burst of N commits consumes roughly one full-suite execution rather than N - billed runner minutes track the number of states worth testing, not the number of pushes. The same rule removes the race where two runs assert against the same deployment slot.
  • Blocking Quality Gate: pylint --fail-under=10 across every package and conftest.py runs before the suite - a style regression fails the pipeline instead of printing a warning.
  • No Third Parties on the Deploy Path: The one check that resolves off-site links is marked external and deselected from the deployment run, then executed on a weekly schedule instead. Link rot is a monthly problem; checking it per push would put GitHub and Docker Hub in the critical path of a deploy signal and generate enough request pressure to trip rate limiting on its own. It fails only on 404/410, because 401, 403 and 429 mean "not reachable by an anonymous caller" rather than "gone".
  • Evidence-Integrity Checks: The suite holds the site to its own claims: every published outcome must cite a project, each citation must open the tab it names, and every project panel must carry a documentation link and a build badge sourced from that project's own repository. A stale reference cannot quietly point a reader somewhere wrong.
  • Published Artefact Verification: The claim that the emulator's public image carries Flask and nothing beyond its own dependency closure is checked against the image itself - anonymous pull token, platform manifest, then the layer blobs, reading installed distribution metadata to confirm the closure still matches what this site advertises. No container runtime is involved, and no HTTP client was added for it. A careless rebuild is invisible from the browser: the tab still renders, the link still resolves, and only the artefact changes - which is precisely why it is read rather than trusted.
  • Diagnosable Failures (Developer Experience): A red build ships everything needed to explain itself. Each failure attaches a full-page screenshot, the fully rendered DOM including script-injected nodes, a Playwright trace openable in Trace Viewer for step-by-step time travel through the run, and the Claude verdict - so the first question a developer asks is answered from the CI artifact rather than by reproducing the failure locally. Reproduction is the expensive step in time-to-resolution; these artifacts are designed to remove it.
  • Dual Reporting Engine: Native Java 21 Allure HTML reporting paired with a self-contained Pytest HTML summary, both uploaded as build artifacts. Every test carries epic / feature / story / severity metadata and each phase is an Allure step, so the report reads as a user journey instead of a click log.
Tech Stack
  • Core Automation: Playwright 1.61.0, Python 3.10+ (developed and CI-pinned on 3.14), Pytest 9.1.1, pytest-playwright 0.8.0
  • AI Diagnostics: Anthropic SDK 0.120.2 (Claude-based failure triage)
  • Reporting & Imaging: Allure Pytest 2.16.0, Pytest HTML 4.2.0, Playwright traces, Pillow 12.3.0
  • Quality & Config: Pylint 4.0.6 held at 10.00/10, python-dotenv 1.2.2
  • CI/CD: GitHub Actions on Ubuntu (Temurin JDK 21, Allure CLI 2.29.0), two workflows - a deployment-gated E2E pipeline and a weekly outbound link check - plus Bash / cURL polling against the GitHub REST API
Test Coverage 61 tests against the live site, of which 10 are generated at collection time by crawling the site's own route graph, so publishing a page grows the suite with no test edit. Nine modules cover SPA routing, cross-viewport layout, base64 link decoding, shared hover styling, per-project panel completeness, engineering-outcome evidence integrity, published-container verification, the suite-size figures this site quotes, and per-route health. 59 run on the deployment path; the two third-party checks - outbound link rot and the published container image - run weekly instead. CI runs Chromium; the suite runs on Firefox and WebKit on request, so a WebKit-specific regression would not be caught by the pipeline.
CI / Build Status PlaywrightAPWebsiteAutomation CI Pipeline status
Documentation Framework README
HTTP Emulators
Repo https://github.com/apolskiy/PublicAP
Tagline Dual Python & Flask HTTP service emulators for REST API fault injection, custom header reflection, and server lifecycle testing
Overview A suite of lightweight HTTP service emulators engineered in Python to enable deterministic quality assurance, REST API fault-tolerance testing, and boundary validation. Comprising an advanced standalone Python HTTP server script and a containerized Flask microservice, the project allows QA automation pipelines to mock external REST endpoints, reflect dynamic headers, and inject edge-case error conditions on demand.
Key Features & Highlights
  1. Core Python HTTP Server Emulator (custom_header_response_to_http_request.py):
    • Full REST API Verb Support: Handles GET, POST, PUT, PATCH, and DELETE methods for complete REST state testing.
    • Payload-Driven Status Selection: The response status is the last three digits of the caller-number field in the JSON body, so 18884400503 returns a 503. This models telephony-style routing, where the dialled number decides the outcome under test. With no body, an X-Caller-Number header supplies the code directly.
    • Server Lifecycle Control Codes: 590 accepts the connection and sleeps 120s without answering, reproducing a hung upstream that a mock cannot imitate; 591 drops and re-opens the listener after 60s; 592 shuts down. Single-threaded by design, which is what makes 590 a genuine stall.
    • Out-of-Band Error Sentinel: Status 999 is deliberately outside the HTTP range, so a client can never confuse "the emulator rejected my request" with a failure it was asked to produce. Returned on a missing or non-numeric caller-number, malformed JSON, or any unexpected exception, after which the process exits non-zero.
    • Session Emulation: 201 returns a fresh session_id (UUID4) per call.
  2. Flask Error Code Emulator (flask_app):
    • Comprehensive Error State Simulation: 21 status codes served on request via /error/<code>: seventeen 4xx (400, 401, 403, 404, 405, 406, 408-417, 419), three 5xx (500, 501, 503), and the non-standard 600, which proves a client tolerates a status outside the registered range. An unlisted code returns 404, so the supported set is discoverable by probing.
    • Containerized Execution: Published as a public image (apolskiy/flask_app) on Docker Hub for containerized Linux/CI execution. Built on python:3.14.4-slim and pinned to a Flask-only dependency set: the image carries Flask and its six transitive dependencies and nothing else, confirmed by reading the published layers rather than trusting the requirements file. A .dockerignore at the build-context root keeps local virtual environments, caches and stray logs out of the artifact, taking the published download from 397 MB to 46 MB.
Tech Stack
  • Languages & Frameworks: Python 3.x, Flask, Python Standard Library (http.server)
  • API & Protocols: REST API (full HTTP verbs, 4xx/5xx/6xx fault injection, payload-driven status selection, connection-stall emulation)
  • DevOps & Containerization: Docker, Docker Hub (apolskiy/flask_app), Linux (Ubuntu container environments)
  • Quality & Tooling: Pytest, pytest-randomly, Pylint (blocking 10.00/10 gate), GitHub Actions, Git
Test Coverage 93 E2E tests across both emulators, run on a four-way matrix of Ubuntu and Windows against Python 3.12 and 3.14. The Flask simulator is driven through its WSGI client for the full 21-code matrix plus real-socket assertions; the caller-number emulator gets a dedicated subprocess on an ephemeral port per test, because its control codes stall or terminate the process and a shared server would make results depend on execution order. Collection order is randomised every run, and a second pass under a fixed seed proves the isolation holds.
CI / Build Status PublicAP emulator test suite status
Documentation Emulator README