Олександр

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

ПРОФІЛЬ
QA Engineer з роком комерційного досвіду в тестуванні web, mobile та REST API у B2B SaaS і B2C-продуктах. Закриваю
повний цикл: аналіз вимог, тест-дизайн, баг-репорти, звітність за релізом.
Був єдиним QA на ERP-продукті з 8 ролями доступу та налаштовуваною матрицею прав. За 9 місяців покрив тестами
близько 20 епіків — понад 1400 тест-кейсів, якими команда користується для регресії.
Локалізую дефекти на рівні UI, REST API та бази даних: за логами й трафіком визначаю, на чиєму боці причина —
клієнта, бекенду чи зовнішнього сервісу.

НАВИЧКИ
Інструменти: Jira · Confluence · Postman · Swagger/OpenAPI · Chrome DevTools · Charles Proxy · AWS CloudWatch · Google
Sheets (тест-документація)
Робота з даними: SQL (MySQL, PostgreSQL) — SELECT з JOIN, фільтрацією та групуванням. Звіряю дані в БД з UI та
використовую SQL для локалізації причин розбіжностей у даних.
Тестування: функціональне, регресійне, smoke, exploratory, risk-based; web (Chrome, Safari, Firefox), mobile (iOS та
Android на реальних пристроях); REST API (статус-коди, структура відповідей, негативні та граничні сценарії, перевірка
прав доступу).
Тест-дизайн і документація: класи еквівалентності, аналіз граничних значень, діаграма станів і переходів, попарне
тестування (pairwise); тест-кейси, чек-лісти, баг-репорти, тест-звіти; Agile/Scrum.

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

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