Олександр

ОЛЕКСАНДР РЕВКОВ
QA Engineer · Web, Mobile, API · B2B SaaS / B2C
[відкрити контакти](див. вище в блоці «контактна інформація») · [відкрити контакти](див. вище в блоці «контактна інформація») · Дніпро (офіс) або віддалено
[відкрити контакти](див. вище в блоці «контактна інформація») · Telegram: @Reevkolld

ПРОФІЛЬ
QA Engineer з комерційним досвідом у Web, Mobile та REST API тестуванні B2B SaaS і B2C продуктів. Сильні
сторони: API, SQL, exploratory та risk-based testing, тестування складної бізнес-логіки та role-based access. 2 роки
комерційного досвіду, включно із самостійним QA продукту як єдиного QA у команді. Досвід роботи з вимогами
та комплексного аналізу дефектів на рівні UI, API, бази даних і зовнішніх сервісів.

НАВИЧКИ
Тестування: функціональне, регресійне, smoke, exploratory, risk-based
Web: Chrome, Safari, Firefox, Chrome DevTools, адаптивне тестування
Mobile: iOS, Android, реальні пристрої, офлайн-флоу, push-сповіщення, deep links, дозволи (permissions),
геолокація
API: REST API, Postman, Swagger/OpenAPI, статус-коди, негативні та граничні сценарії, авторизація
Бази даних: SQL, MySQL, PostgreSQL, SELECT, JOIN, фільтрація, групування
Тест-дизайн: класи еквівалентності, аналіз граничних значень, діаграма станів і переходів, попарне тестування
(pairwise)
Інструменти: Jira, Confluence, Charles Proxy, AWS CloudWatch
Автоматизація: TypeScript, Playwright — на етапі навчання

ДОСВІД РОБОТИ
QA Engineer · Cleveroad (аутсорс-компанія) · вересень 2024 – серпень 2026
ERP-система (B2B SaaS) для охоронної компанії
Веб-панель і мобільний застосунок (iOS/Android на реальних пристроях) · єдиний QA у команді
Продукт: управління робочими змінами (shift management) і персоналом — понад 300 охоронців, звітність та
аналітика. Модель доступу: 8 ролей із налаштовуваною CRUD-матрицею; права додатково обмежені тим, до
якого об'єкта охорони належить користувач (субпідрядник не створює зміни, а лише призначає власний
персонал).
• Протестував REST API (~60 ендпоінтів: дашборд, аналітика, зміни, клієнти, користувачі,
компанії-субпідрядники, звіти, матриця доступу) у Postman за специфікацією Swagger/OpenAPI; матрицю прав
на 8 ролей покривав попарним тестуванням ролей і дій. Після рефакторингу бекенду виявив дефект
авторизації: UI приховував кнопку створення зміни, але POST /shifts приймав запит від субпідрядника та
створював зміну — перевірка прав залишилася лише на фронтенді. Завів критичний дефект, його виправили
до релізу.
• Побудував діаграму станів і переходів для життєвого циклу зміни та перевірив валідні й заборонені
переходи. Знайшов тупиковий стан: зміну можна було завершити, поки охоронець перебував на перерві, —
після цього він не міг ані закрити перерву, ані заступити на наступні зміни.
• SQL-запитами локалізував помилку фільтрації нічних змін: вибірка будувалася за датою початку, а не за
перетином інтервалу зміни з поточною добою, — тому зміни, що почалися напередодні, зникали з дашборда
диспетчера. Після баг-репорту логіку вибірки виправили.
• Уточнював вимоги з обома бізнес-аналітиками ще до старту розробки. Поле post orders планували зробити
звичайним текстовим — я поставив питання про очікуваний зміст поля та експорт даних, і в підсумку його
реалізували через шаблони. По змінах поставив питання про часові пояси: за контрактом з клієнтом зміна
триває з 06:00 до 15:00 — диспетчер вводить свій час чи час об'єкта? У підсумку зміни відображаються у двох
таймзонах (адміністратора та об'єкта охорони), а вибір точки на карті при створенні об'єкта визначає його
таймзону.
• Мобільний застосунок охоронця: перевірив повний офлайн-флоу — цикл зміни, звіти, SOS — та відновлення
після повернення мережі; push- та in-app-сповіщення про створення, зміну й видалення змін разом із deep
link-редіректами. Виявив, що після відкликання дозволу на геолокацію в налаштуваннях ОС зміна все одно
стартувала, хоча за вимогою замовника трекінг має бути активним завжди — без нього зміна не може бути

1

розпочата.
• Після міграції геолокації на зовнішній сервіс виявив втрату geofence-подій. За логами AWS CloudWatch та
записами в БД встановив, що координати надсилалися коректно, але зовнішній сервіс не повертав відповідь.
Дефект був на боці провайдера; після його заміни geofence-події почали надходити коректно.
Корпоративний сайт Cleveroad · CMS, локалізація
• Проводив smoke-тестування та risk-based регресію перед кожним релізом (~30 релізів): три браузери, реальні
iPhone і Android, адаптивна верстка в Chrome DevTools (device mode, 1920 / 1280 / 768). Локалізував причини
верстальних дефектів — margin collapse, overflow: hidden — і помилку гідратації React #418, через яку банер
миготів під час завантаження сторінки.
• Протестував німецьку, іспанську та норвезьку локалізації сайту, зафіксував 19 дефектів: неперекладені рядки,
зламаний через довжину перекладу layout, помилки в навігації та перемикачі мов, некоректні формати дат і
чисел. Передав усі дефекти у роботу та перевірив їх виправлення до релізу; на основі знайдених проблем
склав чек-ліст для наступних мовних версій.
Застосунок health & fitness · iOS + Android
• Тестував today plan: вправи на день, добову норму калорій та нагадування про check-in; перевіряв
перерахунок показників після зміни даних користувача та одиниць вимірювання.
• Тестував стрічку активності користувачів: перевіряв пагінацію та сортування контенту за категоріями
(бодибілдинг, фітнес тощо).
• Під час перевірки валідації трекера води виявив, що застосунок приймав значення 10 л води на добу без
помилки чи попередження. Дефект створював ризик введення потенційно небезпечного для користувача
значення. Оформив баг-репорт; після цього додали верхню межу та попередження.
B2C соціально-стримінгова платформа · iOS
Зона відповідальності: стрічка контенту та модерація
• Через Charles Proxy локалізував дефект на боці клієнта: застосунок надсилав поле tag замість tags зі
специфікації — пости публікувалися без тегів, при цьому API повертав 200, тож дефект не було видно ні в UI,
ні в логах. Оформив баг-репорт із payload для відтворення й передав мобільній команді.
• Під час регресії виявив прогалину в процесі модерації: у формі скарги поле «Причина» було вільним текстом
без списку варіантів, а вкладення — необов'язковим, тож модератор отримував лише текст скарги без самого
спірного контенту. Оформив баг-репорт і запропонував PM автоматизувати пост-модерацію зовнішнім
сервісом — пропозицію взяли в роботу, інтеграцію я протестував.

ОСВІТА ТА МОВИ
Дніпровський національний університет імені Олеся Гончара — «Інженерія програмного забезпечення» (121),
бакалаврат.
Мови: українська — рідна; англійська — B1/B2 in-progress

2