Що таке TestComplete і для яких задач він підходить
TestComplete — це інструмент функціонального UI‑тестування від SmartBear для автоматизації перевірок у реальних застосунках і браузерах. Його часто обирають у корпоративних командах, де потрібні стабільні регресійні прогони, зрозуміла підтримка різних технологій UI та можливість працювати як “без коду”, так і зі скриптами.
На практиці TestComplete зручний, коли треба:
- покрити регресію UI для веб‑частини продукту (кабінет, адмін‑панель, SaaS‑інтерфейс);
- тестувати desktop‑додатки на Windows (внутрішні корпоративні клієнти, POS‑софти, інсталятори);
- автоматизувати типові сценарії користувача: логін, ролі, форми, оплати, налаштування, повідомлення, експорт/імпорт;
- запускати тести на окремих машинах/VM через легкий раннер (TestExecute) для паралельних прогонів.
Де TestComplete особливо зручний: desktop і web
У веб‑тестуванні TestComplete працює з реальними браузерами на Windows і дає доступ до об’єктної моделі сторінки (елементи, властивості, дії). Це корисно для стабільніших тестів, ніж “клік по координатах”, особливо якщо в UI багато динаміки.
У desktop‑частині сильна сторона — робота з Windows‑інтерфейсом, діалогами, системними вікнами, контролами різних фреймворків та сценаріями інсталяції/оновлення. Для підприємств це часто критично: частина продукту може бути web, а частина — desktop‑утиліти або “тонкі” клієнти.
Типові сценарії enterprise UI automation
Найчастіше автоматизують не “все підряд”, а те, що дає максимальний ефект у регресії:
- Аутентифікація і сесії: логін, MFA, відновлення пароля, тайм‑аути, “запам’ятати мене”.
- Ролі та доступи: різні права для користувачів/адмінів, приховані розділи, 403/404 при прямому заході.
- Критичні бізнес‑флоу: створення/редагування сутностей, підтвердження дій, статуси, історія.
- Форми і валідації: маски, локалі (десяткові роздільники), обов’язкові поля, помилки.
- Платежі й підписки: checkout, webhook‑статуси, сторінки успіху/помилки.
- UI‑стійкість: перевірка, що сторінки не “ламаються” після релізу (критичні блоки, навігація).
Навіщо тут мобільні проксі: гео‑QA і антибот на “мобільних” ASN
Якщо продукт має веб‑інтерфейс і працює в різних країнах, одних лише “локальних” тестів недостатньо. Поширені ситуації:
- частина функцій прихована або змінена для певних регіонів (комплаєнс, ліцензії, партнери);
- різні валюти, податки, тексти, банери згоди, правила доставки/оплати;
- антибот‑шар (WAF/бот‑захист) по‑різному реагує на ASN і тип мережі: датацентр/VPN vs мобільна мережа;
- потрібно відтворити “поведінку користувача зі смартфона” не лише по User‑Agent, а й по мережевих атрибутах.
Mobile proxy у цьому контексті — це вихід у інтернет з IP‑адреси, що належить мобільному оператору (мобільний ASN). Такі адреси часто мають інший “репутаційний профіль” у антибот‑системах і краще відображають реальні умови доступу кінцевих користувачів.
Коли саме mobile proxy дають найбільшу користь
- Гео‑обмеження і фіче‑флаги: перевірити, що у країні A модуль увімкнений, а в країні B прихований/заблокований.
- Ціни й локалізація: валюта, ПДВ, округлення, мова, адресні формати.
- Антибот і ризик‑скори: CAPTCHA, 403, додаткові перевірки при логіні, обмеження частоти.
- Підозрілий трафік: коли частина корпоративної інфраструктури “схожа” на датацентр і тригерить захист.
- Перевірка інцидентів: “в Туреччині не пускає в кабінет”, “в Канаді зник розділ Billing”.
Як поєднати TestComplete і проксі: практичні підходи
TestComplete керує браузером/додатком на Windows‑машині, тому проксі зазвичай підключають на рівні середовища виконання:
- Системний проксі Windows (WinINET): зручно для сценаріїв, де тест використовує браузери/компоненти, що читають системні налаштування.
- Проксі на рівні браузера: запуск браузера з параметрами проксі або з окремим профілем, де проксі задано.
- Окрема VM/контейнер під країну: найнадійніше для масштабування: кожна VM має свій вихідний IP (mobile proxy), а тести запускаються паралельно через TestExecute.
- PAC‑файл/маршрутизація: якщо треба проксувати лише частину доменів (наприклад, тільки web‑частину, а API лишити напряму).
Ключова ідея: не “вшивати” проксі в тести, а робити його параметром середовища/джоби в CI. Тоді один і той самий набір тестів можна запускати для різних країн без дублювання.
Що важливо для стабільності: sticky‑сесії та керування IP
Для UI‑тестів стабільність важливіша за “часту ротацію”. Якщо IP змінюється посеред логіну або оплати, можна отримати зайві підозри у антибот‑системі або навіть розлогін.
- Sticky‑сесія (фіксація IP на N хвилин) підходить для повного e2e‑флоу: логін → дія → перевірка.
- Ротація між тестами корисна, коли треба зменшити накопичення “ризик‑скору” або перевірити поведінку на різних IP у межах країни.
- Пули за країнами — окремі списки endpoint’ів для кожного регіону, щоб не змішувати гео в одному прогоні.
Кейс: SaaS‑панель з регіонально прихованими функціями
Уявімо SaaS‑кабінет, де частина функцій доступна лише в певних країнах (наприклад, різні платіжні провайдери, юридичні обмеження або партнерські інтеграції). Команда хоче автоматизувати перевірку, що:
- в країні UA видно модуль “Payments” і доступний провайдер X;
- в країні DE модуль “Payments” є, але провайдер X прихований, натомість доступний Y;
- в країні US частина налаштувань недоступна, і UI коректно показує пояснення (baner/tooltip/FAQ);
- антибот‑шар не видає зайвих CAPTCHA/403 при нормальній швидкості кліків.
Рішення: для кожної країни виділяється окремий mobile proxy endpoint (або пул), запускається одна й та сама тест‑збірка, але з різними змінними середовища: COUNTRY=UA, PROXY=..., LOCALE=uk-UA, TIMEZONE=Europe/Kyiv. У звіті тестів фіксуються: IP, країна, ASN, час, версія збірки. Так легше відрізнити “реальний баг” від проблеми мережі або нестабільного проксі.
Як організувати гео‑матрицю прогонів
Щоб це працювало “по‑дорослому”, зазвичай роблять матрицю:
- Країна/регіон (UA, PL, DE, US…)
- Тип мережі (mobile ASN як “реалістичний” профіль, інколи — окремо датацентр для порівняння)
- Браузер (Edge/Chrome/Firefox — залежно від ваших користувачів)
- Роль (user/admin/partner)
Далі в CI (або планувальнику) запускаються джоби паралельно. Для TestComplete зручно, що раннер може виконувати тести на окремих машинах без повної IDE (TestExecute), що спрощує розгортання “ферми” під гео‑перевірки.
Поради, щоб тести не перетворилися на “флейк‑фест”
- Валідуйте гео явно: на старті тесту зробіть коротку перевірку, що IP дійсно у потрібній країні (через ваш сервіс‑ендпойнт або надійний geolocation API), і логайте результат.
- Контролюйте швидкість: антибот часто реагує на “людськи неможливу” частоту дій. Додавайте реалістичні паузи там, де користувач читає/чекає.
- Окремі акаунти під гео: щоб не ловити блокування через підозрілі входи з різних країн одним логіном.
- Чистий стан: перед кожним тестом — очищення cookies/localStorage або окремі профілі, щоб не змішувати локалі.
- Діагностика: на фейлі зберігайте скрін, DOM/логи, і параметри мережі (IP/ASN/країна), інакше баг буде “невідтворюваним”.
Підсумок
TestComplete добре підходить для enterprise UI automation, особливо коли треба стабільно ганяти регресію для web/desktop і масштабувати виконання на кількох машинах. Додавши індивідуальні мобільні проксі, ви отримуєте реалістичну гео‑перевірку: як виглядає продукт у різних країнах і як поводиться антибот‑шар на мобільних ASN. Найкращий результат дає підхід “проксі як параметр середовища”, sticky‑сесії на e2e‑флоу і чітке логування мережевих атрибутів у звітах.
Коротко про підходи створення тестів: keyword‑тести та скрипти
У TestComplete є два популярні стилі роботи:
- Keyword‑driven тести — сценарій збирається з “операцій” у візуальному редакторі. Це зручно для команди зі змішаними навичками, коли частина QA не пише код, але може підтримувати регресію.
- Скриптові тести — логіка описується кодом (часто обирають JavaScript або Python). Скрипти дають більше гнучкості: параметризація, власні утиліти, складні перевірки, робота з API/файлами, генерація даних.
Практичний компроміс: критичні e2e‑флоу тримати у keyword‑формі (легше читати), а допоміжні речі (логін‑хелпер, робота з тест‑даними, перевірка гео/IP, репорти) винести у скриптові бібліотеки.
Web‑частина: кросбраузерність, профілі та мобільна емулція
Для гео‑QA важливо тестувати не “в абстракції”, а в реальних браузерах, які використовують ваші клієнти. У TestComplete це зазвичай означає прогони в Edge/Chrome/Firefox з однаковим набором сценаріїв і порівнянням результатів.
Якщо вам потрібно перевірити саме “мобільний веб”, корисний підхід — запуск тестів у мобільній емулції браузера. Це дозволяє перевірити адаптивність, меню, модальні вікна, поведінку інпутів і ключові сторінки без фізичних пристроїв. Важливо розуміти: емулція покриває UI‑розмітку і поведінку фронтенду, але не замінює мережеву реальність. Тому для антибот‑перевірок саме mobile proxy дають основний ефект.
Mobile testing: коли потрібні реальні Android/iOS тести
Окремо від мобільного вебу можуть бути нативні додатки. У таких кейсах команди будують два рівні:
- Web‑регресія (кабінет/панель/лендінги) — через браузерні тести.
- Нативний мобільний регрес — через мобільні тести (Android/iOS) на реальних пристроях або емуляторах.
Навіть якщо ваш основний фокус — SaaS‑панель, інколи корисно мати хоча б базовий набір мобільних smoke‑тестів: логін, головний екран, критичний сценарій. Якщо мобільний клієнт “падає”, це часто швидше видно у smoke‑матриці, ніж у підтримці.
Дані і повторюваність: data‑driven підхід для гео‑перевірок
Гео‑QA дуже добре лягає на data‑driven формат. Замість трьох однакових тестів “UA/DE/US” робіть один тест, який читає параметри з таблиці (JSON/CSV): країна, проксі‑endpoint, очікувані фічі, валюта, мова, список прихованих розділів. Тоді додавання нового регіону — це один рядок у даних, а не нові копії сценаріїв.
Корисна практика — зберігати “очікування” у вигляді простих правил, наприклад:
- ModulesVisible: [Dashboard, Users, Payments]
- ModulesHidden: [CryptoPayouts]
- Currency: EUR
- PaymentProviders: [Adyen, SEPA]
Ці правила можна перевіряти як у UI (наявність блоків), так і опосередковано (текст/підказки), а також використовувати для генерації зрозумілих повідомлень у звіті, якщо щось “не зійшлося”.
Чекліст впровадження mobile proxy у geo‑QA
- 1) Визначте матрицю: які країни і які браузери реально важливі (за аналітикою продукту).
- 2) Окремі середовища: для кожної країни — свій проксі‑endpoint/пул і бажано своя VM або хоча б окремий профіль браузера.
- 3) Перевірка гео на старті: логайте IP/країну/ASN; якщо гео не відповідає — тест має падати “швидко і зрозуміло”.
- 4) Sticky для e2e: одна IP‑сесія на повний флоу, ротація — лише між тестами.
- 5) Обмеження швидкості: ставте паузи і не запускайте десятки логінів на секунду з одного IP.
- 6) Артефакти прогону: скріни, логи, відео (якщо є), та мережеві параметри в одному місці.
- 7) Порівняння з “контролем”: інколи корисно мати контрольний прогін без проксі, щоб швидше локалізувати проблему.
На що звернути увагу з антибот‑точки зору
Антибот‑системи дивляться не лише на IP. Якщо ваші тести “провалюються” навіть з mobile proxy, причина може бути у поєднанні факторів: частота дій, повторювані патерни, чистота профілю, підозрілі заголовки, відсутність “людських” пауз. Для QA важливо не “обходити” захист, а підтвердити, що звичайний користувач не страждає. Тому під час налаштування тестів орієнтуйтесь на реалістичну поведінку, а не на максимальну швидкість прогону.
Якщо у продукті є “soft blocks” (наприклад, додаткова перевірка при ризику), додайте окремі тести на ці гілки: очікувані повідомлення, зрозумілі інструкції для користувача, коректне повернення у флоу після підтвердження.