Олександр

OLEKSANDR REVKOV
QA Engineer · Web, Mobile, API · B2B SaaS / B2C
[відкрити контакти](див. вище в блоці «контактна інформація») · [відкрити контакти](див. вище в блоці «контактна інформація») · Dnipro (office) or remote
[відкрити контакти](див. вище в блоці «контактна інформація») · Telegram: @Reevkolld

PROFILE
QA Engineer with 2 years of commercial experience testing Web, Mobile, and REST API products in B2B SaaS
and B2C domains. Specializing in functional, regression, exploratory, and risk-based testing. Hands-on experience
with Postman, SQL, Charles Proxy, Swagger/OpenAPI, and AWS CloudWatch. Independently owned QA on a
product with a complex role model and permission matrix, covering business logic, API, and mobile scenario
testing.
Strong in requirements analysis, test coverage design, risk identification before development starts, and
comprehensive defect investigation at the UI, API, database, and external-service levels. Developing test
automation skills with TypeScript and Playwright. Focused on a structured approach to testing and on finding risks
that affect product quality and stability.

SKILLS
Tools: Jira · Confluence · Postman · Swagger/OpenAPI · Chrome DevTools · Charles Proxy · AWS CloudWatch ·
Google Sheets (test documentation)
Data work: SQL (MySQL, PostgreSQL) — SELECT with JOIN, filtering, and grouping. Reconciles database data
against the UI and uses SQL to localize the root cause of data discrepancies.
Testing: functional, regression, smoke, exploratory, risk-based; web (Chrome, Safari, Firefox), mobile (iOS and
Android on real devices); REST API (status codes, response structure, negative and boundary scenarios, access
rights verification).
Test design & docs: equivalence classes, boundary value analysis, state-transition diagrams, pairwise testing;
test cases, checklists, bug reports, test reports; Agile/Scrum.
Automation: TypeScript, Playwright (in progress).

WORK EXPERIENCE
QA Engineer · Cleveroad (outsourcing company) · September 2024 – August 2026
ERP system (B2B SaaS) for a security company
Web dashboard and mobile app (iOS/Android on real devices) · sole QA on the team
Product: shift and workforce management — 300+ security guards, reporting and analytics. Access model: 8 roles
with a configurable CRUD matrix; permissions further restricted by which security site the user belongs to (a
subcontractor does not create shifts, only assigns their own staff).

• Tested the REST API (~60 endpoints: dashboard, analytics, shifts, clients, users, subcontractor companies,
reports, access matrix) in Postman against the Swagger/OpenAPI spec; covered the 8-role permission matrix with
pairwise testing of roles and actions. After a backend refactor, found an authorization defect: the UI hid the "create
shift" button, but POST /shifts still accepted the request from a subcontractor and created the shift — the
permission check remained front-end only. Filed a critical defect, fixed before release.

• Built a state-transition diagram for the shift lifecycle and verified valid and forbidden transitions. Found a dead-end
state: a shift could be completed while the guard was on break — after that they could neither close the break nor
start subsequent shifts.

• Used SQL queries to localize a night-shift filtering bug: the query was built on the shift's start date rather than the
overlap of the shift interval with the current day, so shifts that started the previous day disappeared from the
dispatcher's dashboard. The selection logic was fixed after the bug report.

• Clarified requirements with both business analysts before development began. The "post orders" field was
planned as plain text — I raised questions about the expected content and data export, and it was ultimately
implemented via templates. For shifts, I raised a time-zone question: per the client contract a shift runs
06:00–15:00 — does the dispatcher enter their own time or the site's time? As a result, shifts are displayed in two

time zones (administrator's and security site's), and selecting a point on the map when creating a site determines
its time zone.

• Guard mobile app: tested the full offline flow — shift cycle, reports, SOS — and recovery after network
reconnection; push and in-app notifications for shift creation, changes, and deletion, plus deep-link redirects.
Found that after revoking the location permission in OS settings, the shift still started, even though per the client's
requirement tracking must always be active — a shift should not be able to start without it.

• After geolocation was migrated to an external service, found lost geofence events. Using AWS CloudWatch logs
and database records, established that coordinates were sent correctly but the external service was not returning
a response. The defect was on the provider's side; geofence events started arriving correctly after it was replaced.

Cleveroad corporate website · CMS, localization
• Performed smoke testing and risk-based regression before each release (~30 releases): three browsers, real
iPhone and Android devices, responsive layout checks in Chrome DevTools (device mode, 1920/1280/768).
Localized the causes of layout defects — margin collapse, overflow: hidden — and a React hydration error #418
that made the banner flicker during page load.

• Tested the German, Spanish, and Norwegian localizations of the site, logging 19 defects: untranslated strings,
layout broken by translation length, navigation and language-switcher errors, incorrect date and number formats.
Passed all defects to development and verified fixes before release; compiled a checklist for future language
versions based on the issues found.

Health & fitness app · iOS + Android
• Tested the "today plan": daily exercises, daily calorie target, and check-in reminders; verified metric recalculation
after changes to user data and units of measurement.

• Tested the user activity feed: verified pagination and content sorting by category (bodybuilding, fitness, etc.).
• While checking water-tracker validation, found the app accepted a value of 10 L of water per day with no error or
warning — a defect that risked the user entering a potentially unsafe value. Filed a bug report; an upper limit and
warning were added afterward.

B2C social streaming platform · iOS
Area of responsibility: content feed and moderation
• Using Charles Proxy, localized a client-side defect: the app sent a "tag" field instead of "tags" per spec — posts
were published without tags, while the API returned 200, so the defect was invisible in both the UI and the logs.
Filed a bug report with the reproduction payload and handed it to the mobile team.

• During regression, found a gap in the moderation process: the "Reason" field in the report form was free text with
no list of options, and the attachment was optional, so the moderator received only the complaint text without the
disputed content itself. Filed a bug report and proposed to the PM automating post-moderation via an external
service — the proposal was adopted, and I tested the integration.

EDUCATION
Oles Honchar Dnipro National University — Software Engineering (121), Bachelor's degree.

LANGUAGES
Ukrainian — native; English — B1/B2, in progress.