Як проксі полегшує життя QA. Розглядаємо на прикладі реальних кейсів
Хелоу, ворлд! Мене звуть Дмитро, я Middle General QA у мультипродуктовій IT-компанії Futurra Group. Ми створюємо круті mobile та web-застосунки в нішах lifestyle, edtech та utilities для мільйонів юзерів зі всього світу.
У розробці ми керуємося даними, які отримуємо від користувачів, і ретельно їх аналізуємо — саме data-driven підхід дозволяє нам ухвалювати обґрунтовані рішення щодо розвитку продуктів. Однак щоб ці дані справді приносили користь, ми повинні бути впевнені в наступному:
- Наші тригери коректні: трекінг в застосунку спрацьовує від саме тієї дії користувача, яка нас цікавить.
- Ми бачимо цілісну картину: жодні дані не губляться «по дорозі» до БД.
- Наші дані повні: в івентах із застосунку приходять усі потрібні нам метрики.
Контролювати ці аспекти щодня нам допомагає проксі. Однак рішення впровадити його прийшло не одразу, і загалом воно рідко буває очевидним для продуктових команд. Основна причина — брак інформації про те, як проксі може спростити та покращити тестування. Серед інших причин можна виділити також такі:
- Недостатня обізнаність в інструментах. Багато QA-інженерів та розробників не знайомі з усіма можливостями проксі-тулів на кшталт Fiddler, Charles чи Burp Suite. Є помилкова думка, що вони призначені винятково для безпеки або аналізу мережі.
- Складність налаштування. Для початківців використання проксі може виглядати складним — потрібно розуміти, як налаштувати пристрій для роботи через проксі, як створювати та надавати сертифікати, як правильно редагувати чи перехоплювати запити й відповіді тощо.
- Вузька спеціалізація інструментів. Команди, що вже налагодили свої флоу тестування з використанням вузькоспрямованих, але більш популярних та звичних інструментів-альтернатив проксі (далі у статті розповім про них детальніше), перестають шукати нові шляхи для покращення тестування, чим дуже себе обмежують.
- Неочевидна вигода. На перший погляд, проксі здається інструментом лише для «перехоплення трафіку». Це може створити бар’єр для впровадження проксі, якщо команда раніше з ним не працювала. Але це набагато універсальніший тул. Важливо, щоб у команді був хтось, хто лобіюватиме його використання та зможе на практиці продемонструвати всі переваги.
У цій статті я хочу розвінчати деякі міфи й непорозуміння щодо проксі-інструментів та показати, як їх використання може покращити тестування й забезпечити більш точні та релевантні метрики для аналізу користувацької поведінки. Свої думки підкріплю реальними кейсами застосування проксі у наших проєктах. Колись мені самому бракувало такого матеріалу в інтернеті, тож сподіваюся, цей досвід стане в пригоді QA-фахівцям Junior- та Middle-рівнів.
Простими словами про проксі
Для початку розберемося, що таке проксі й навіщо він потрібен. Якщо просто, це своєрідний посередник між вашим пристроєм і сервером, до якого надсилаються запити та отримуються відповіді.
У стандартній ситуації пристрій робить запити прямо до ресурсу. Однак у випадку проксі всі ці дані спочатку проходять через нього, що відкриває додаткові можливості для отримання інсайтів.
Проксі не просто маршрутизує трафік — він дозволяє перехоплювати, аналізувати та змінювати запити й відповіді в реальному часі. Це дає змогу глибше розуміти поведінку юзерів у застосунках, тестувати різні сценарії, виявляти вразливості й оптимізувати обробку даних.
Коли без проксі (не) обійтись
Чи можна обійтися без проксі? Теоретично так, але навіщо ускладнювати собі життя? Альтернативи, звісно ж, є, але вони мають свої обмеження:
- API-тестування через Postman дає змогу перевіряти запити до серверів, але не дає можливості відстежувати та одразу редагувати мережеві запити в реальному часі з мобільних застосунків чи вебінтерфейсів.
- Браузерні DevTools чудово підходять для аналізу запитів у вебзастосунках і симуляції поганого з’єднання/швидкості мережі, але їхні можливості обмежені для роботи з мобільними застосунками або тестування поза браузером.
- Сніфери трафіку (на кшталт Wireshark) дозволяють бачити весь мережевий трафік, але складні в налаштуванні та аналізі через великий обсяг даних.
На мою думку, проксі — це універсальний інструмент, що об’єднує можливості перехоплення, аналізу та маніпуляції трафіку для різних платформ одночасно. Він забезпечує ефективну роботу в одному місці, що робить тестування швидшим і зручнішим.
Окрім того, він зменшує залежність від розробників — не потрібно сидіти та чекати на окремий білд, щоб почати тестування. Ви можете безпосередньо маніпулювати трафіком і отримувати потрібні дані без затримок.
Далі я поділюся реальними кейсами наших продуктів, які наочно демонструють, як проксі допомагає підвищувати якість тестування, знаходити приховані проблеми та отримувати точні метрики для ухвалення подальших обґрунтованих рішень.
✍️ Кейс 1. Тестування тригерів івентів — від «наосліп» до прозорості
До впровадження налагоджених процесів тестування у нашому VPN-продукті (на той момент у VPN-команді не було тестувальника) перевіркою івентів займалися аналітики та маркетингова команда.
Це робилося майже «наосліп»: обирали потрібні елементи в застосунку, де за технічним завданням мала бути реалізована певна логіка відправки івентів. Потім відкривали базу даних і перевіряли, чи з’явилися там потрібні метрики.
Проблема була очевидна — без проксі неможливо точно визначити, що саме спричинило відправку івенту. Можна було натиснути одне, а спрацьовувало зовсім інше. Проксі ж, як вже зазначалося, дозволяє чітко відстежувати, які дані надсилаються та в який саме момент.
Проксі суттєво спростив нам тестування метрик: тепер ми бачимо все в реальному часі, без потреби заглядати в базу даних. Процес тестування з хаотичного перетворився на прозорий і передбачуваний. Завдяки проксі ми отримали впевненість у двох провідних аспектах:
- Тригери івентів спрацьовують саме тоді, коли це потрібно.
- Відправляються всі необхідні дані у повному обсязі.
✍️ Кейс 2. Застосування проксі у методі Blue-Green
Під час релізів нових функціональностей ми зазвичай використовуємо підхід Blue-Green (інші назви — ab-деплоймент та staging/production) для деплойменту в продакшн. Для тих, хто не знайомий з терміном, простими словами: ми маємо дві версії продакшн-середовища — blue та green. На одну деплояться всі нові зміни (green), а інша залишається незмінною (blue) — і саме її продовжують бачити наші юзери.
У цьому процесі проксі відіграє важливу роль, оскільки дозволяє направляти всі запити з пристроїв на ту версію продакшн-середовища, яку потрібно протестувати, без жодних змін для кінцевих користувачів. Тобто можна маніпулювати запитами в реальному часі, що дає можливість чітко контролювати, які саме дані передаються в різних середовищах, без впливу на досвід юзерів.
Таким чином ми можемо тестувати нові функції без ризику для користувачів. Оскільки якщо на новій версії з’являться баги, вони не вплинуть на реальних юзерів.
✍️ Кейс 3. Імітація проблем з мережею
Для певних тест-кейсів нам потрібно перевіряти такі сценарії, імітація яких потребує «танців з бубном» — багато зусиль та часу. Наприклад, як застосунок реагує на повільне інтернет-з’єднання? Що бачить юзер, коли з’єднання раптово втрачається? Як система опрацьовує різні коди помилок від сервера, наприклад, 500?
Імітувати такі ситуації можна за допомогою проксі — з використанням вбудованих інструментів Throttle та Breakpoints. Throttle допомагає зручно налаштовувати обмеження швидкості мережі, а Breakpoints — відловлювати запити й відповіді, щоб редагувати перед тим, як їх отримує застосунок.
Це значно спрощує процес тестування та дає змогу швидко перевірити поведінку застосунку в реальних умовах.
✍️ Кейс 4. Підміна домену запиту
Коли треба зарелізити значні оновлення, що охоплюють як фронтенд, так і бекенд, часто виникає потреба в тестуванні змін обох аспектів одночасно. Наприклад, фронтенд вже розгорнутий на проді, але тестування бекенду неможливе до того, як буде завершено його реліз на проді. У таких випадках інструмент Map Remote дає змогу ефективно розв’язати проблему, підміняючи URL запитів до бекенд-сервісів на тестовий. Таким чином не потрібно буде чекати, поки бекенд релізнуть на прод, що прискорить процес тестування та знизить залежність від синхронізації двох частин системи.
✍️ Кейс 5. Перевірка на витік чутливих даних
У сучасних застосунках більшість мережевих запитів здійснюється через HTTPS для забезпечення конфіденційності та безпеки. Проксі дає можливість задекодити цей зашифрований трафік (за допомогою довіреного сертифіката), що відкриває доступ до аналізу вмісту запитів та відповідей. Завдяки цьому ми можемо ретельно перевірити, чи не передаються чутливі дані, як-от логіни, паролі чи токени сесій у відкритому вигляді.
✍️ Кейс 6. Аналіз сторонніх інтеграцій у продукті
Застосунки часто інтегруються зі сторонніми сервісами — аналітичними платформами, рекламними мережами, сервісами push-нотифікацій чи платіжними системами. За допомогою проксі можна перехоплювати та редагувати запити й відповіді зовнішніх API. Це особливо корисно у таких випадках:
- Відсутність доступу до sandbox-середовища потрібного сервісу. Якщо немає можливості використовувати тестове середовище стороннього сервісу, проксі дозволяє імітувати взаємодію напряму.
- Перевірка негативних сценаріїв і відмовостійкості застосунку. Наприклад, що відбувається, якщо зовнішній сервіс повертає помилку на кшталт 500 Internal Server Error, 403 Forbidden або таймаут.
- Підміна відповідей для перевірки реакції системи на певні умови чи дані.
- Валідація обробки отриманих даних. Проксі дає змогу детально відстежувати, як наша система інтерпретує відповіді сторонніх сервісів, і виявляти потенційні проблеми у взаємодії з інтеграціями.
Цей підхід допомагає зменшити ризики під час роботи з зовнішніми API та гарантує стабільність і коректну обробку даних навіть у складних сценаріях.
✍️ Кейс 7. Редагування відповідей з БД
Є випадки, коли потрібно протестувати контент, який підтягується з бази даних. В таких тест-кейсах часто є потреба в отриманні якихось конкретних відповідей з БД. Проксі дозволяє модифікувати ці відповіді на рівні мережевих запитів, забезпечуючи гнучкість і швидкість тестування. Це стає особливо корисним у таких кейсах:
- Некоректні або відсутні дані. Перевірка того, як застосунок відображає контент, якщо дані з бази приходять із помилками або взагалі відсутні (порожній контент), та чи показується повідомлення про відсутність даних.
- Тестування пагінації. Для перевірки коректної роботи пагінації можна редагувати відповіді, налаштовуючи різну кількість елементів на сторінку (1, 10, 100). Це дозволяє легко перевірити роботу навігації між сторінками та її стабільність.
Проксі дає змогу моделювати потрібні дані без змін у базі та без залежності від розробників, що прискорює тестування. Також він спрощує перевірку edge-кейсів і рідкісних сценаріїв, які складно відтворити в реальних умовах.
✍️ Кейс 8. Редагування заголовків запитів
Проксі дає можливість змінювати заголовки HTTP-запитів. Це значно спрощує тестування кешування, локалізації та роботи сесій. Ось кілька прикладів:
- підміна Cache-Control і ETag дає можливість перевірити, чи коректно система обробляє повторні запити та кешує ресурси;
- редагування Accept-Language: імітація різних мовних налаштувань допомагає перевірити, чи правильно система відображає локалізований контент або fallback-тексти (якщо потрібної мови немає);
- заміна User-Agent дозволяє тестувати адаптивність UI на різних пристроях і в різних браузерах.
- редагування Cookies, щоб перевірити поведінку системи під певною сесією або налаштуваннями.
Замість висновків
Проксі — це стратегічний інструмент, що розширює можливості тестування та аналізу даних. Він дозволяє перехоплювати, редагувати та моделювати мережеві запити в реальному часі, ефективно тестуючи складні сценарії та edge-кейси. Використання проксі підвищує якість продукту, знижує залежність від розробників і забезпечує переваги, недоступні через інші інструменти, такі як API-тестувальники або браузерні DevTools.
Для мене та моєї команди проксі — це точно must тестування. А ви використовуєте проксі у своїх проєктах? Як оцінюєте його ефективність порівняно з іншими інструментами?
Поділіться своїми думками та кейсами в коментарях👇🏻
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів