Інструменти для тестування даних, codeless-автоматизація та створення mock-сервісу — три дипломи моїх студентів

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Вітаю, колеги! Мене звати Олексій Остапов, я Head of Test Automation sub-practice в компанії Infopulse, один з ведучих подкасту «Питання Якості», автор блогу QA Mania. А ще я викладаю тестування в КПІ. Восени минулого року до мене звернулись декілька студентів КПІ із питанням, чи не міг би я стати їхнім дипломним керівником. І чом би й ні — в мене дійсно є купа ідей, які я вже просто фізично не встигаю опрацьовувати. Тож я роздав теми, і ми працюємо разом.

Тема 1. «Аналіз інструментів для валідації даних для програмного забезпечення у сфері телекомунікацій».
Тема 2. «Оцінка працездатності інструментів codeless-автоматизації тестування ПЗ у сфері телекомунікацій».
Тема 3. «Створення сервісу динамічних моків».

Коли я робив свій дипломний проєкт, то не ставився до нього достатньо серйозно, як і багато інших студентів — щось зробив, написав, захистив і забув. Але тепер я вирішив, що можу взяти участь в дипломних проєктах, які дійсно можуть принести користь.

Скоро в нас починається переддипломна практика, і я з нетерпінням чекаю можливості поділитись із вами результатами нашої роботи. А поки що ми разом зі студентами готуємо низку статей за темами дипломних робіт. Будемо дуже вдячні спільноті за поради та фідбек.

Тут і далі, коли використовується займенник ми, робота здебільшого виконана Богданою 😀

Яка основна мета роботи? Озвучити проблему. Адже дуже часто ми як інженери працюємо над задачею і вирішуємо її не оптимальним способом. Не знаємо, що можна зробити це по-іншому.

Уявіть, я колись не знав про існування Postman, хоча мої колеги вже деякий час ним користувались. А я тоді страждав і використовував застарілий SoapUI для тестування REST API, хоча він не дуже для цього підходить. І коли нарешті мені показали, що API-тестування REST-сервісів можна робити зручніше, це пришвидшило мою роботу в рази.

У чому проблема

Майже кожен тест-інженер, якого я знаю, так чи інакше натрапляв на

• міграцію даних з однієї системи в іншу;
• ETL;
• розгортання системи в новому середовищі;
• підготовку тестових даних для системного та інтеграційного тестування.

Тема якості даних настільки мене вразила, що минулого року я знайшов стандарт і написав про це цілу статтю. А ще є Big Data. Такі об’єми даних неможливо перевірити очима взагалі. Зі свого досвіду роботи в телекомі я пам’ятаю, що там є десятки систем, які мають свої унікальні набори даних, і вони мають узгоджуватись з даними в інших системах.

Як типово ми розв’язуємо такі проблеми? Руками. Рідше — генераторами, якщо дані не дуже складні. Іноді приділяємо увагу окремим полям в наборах даних, використовуючи black box-техніки тест-дизайну.

І саме тут варто замислитись — а чи можна зробити це краще? Стандартизувати, автоматизувати? Чи є інструменти, які можуть спростити нашу роботу?

На ринку представлено широкий спектр інструментів для валідації даних, які пропонують різноманітні функції та можливості. Вибір найбільш відповідного інструменту для конкретних потреб телекомунікаційної компанії може бути складним завданням, оскільки потрібно враховувати масштабованість, інтеграцію з дійсними системами, продуктивність, вартість та інші критичні аспекти.

Інструменти

Ми провели дослідження та обрали інструменти для оцінки якості валідації даних:

Astera — потужний інструмент для перевірки якості, очищення, трансформації та управління даними. Має модулі для усунення дублікатів, стандартизації форматів, перевірки правил та виявлення відхилень. Підтримує інтеграцію з численними базами даних, файлами та застосунками. Забезпечує відстеження походження даних та аудит змін. Пропонує гнучкі можливості для програмування та скриптів користувачів.

Talend Data Quality — модуль Talend, який забезпечує комплексне рішення для перевірки, очищення та збагачення даних з різних джерел. Інтегрується з ETL та іншими модулями Talend для комплексного рішення якості. Забезпечує автоматичне виявлення та виправлення помилок. Має вбудовані сховища правил та конвеєри для очищення даних.

Informacia Data Quality — потужний інструмент для управління якістю даних від компанії Informatica. Він пропонує функції парсингу, стандартизації, збагачення та перевірки даних, а також інтегрується з іншими продуктами Informatica. Підтримує хмарні та локальні розгортання.

Trifacta — інноваційне рішення для підготовки даних на основі візуального інтерфейсу та машинного навчання. Аналізує структуру та рекомендує необхідні перетворення. Підтримує численні типи та джерела, разом зі структурованими та неструктурованими. Забезпечує відстеження походження та аудит даних.

Datameer — платформа для аналізу та підготовки даних, яка поєднує профілювання, каталогізацію, інтеграцію та візуалізацію в одному рішенні. Виявляє відхилення та підозри на помилки. Дозволяє створювати власні потоки обробки для очищення та збагачення даних. Інтегрується з популярними аналітичними інструментами.

Data Ladder — інструмент для управління якістю даних з акцентом на автоматизацію процесів валідації та очищення даних за допомогою правил. Дозволяє створювати, налаштовувати та застосовувати набори правил для перевірки різних типів. Підтримує великі обсяги та широкий спектр форматів джерел. Інтегрується з провідними базами даних, сховищами даних та ETL-інструментами. Пропонує гнучкий вебінтерфейс для централізованого управління процесами якості даних.

Google Refine — безкоштовний інструмент з відкритим кодом для очищення та трансформації даних, що зосереджується на взаємодії з неструктурованими та напівструктурованими наборами даних. Забезпечує потужні можливості для експлорації, трансформації та видалення помилок. Підтримує імпорт/експорт різноманітних форматів. Надає вбудовані функції для очищення тексту, стандартизації, перетворення дат тощо.

DataWrangler — візуальний інструмент, який забезпечує інтерактивний підхід до очищення, трансформації та інтеграції даних з різних джерел. Дозволяє створювати та застосовувати потоки обробки до різних наборів. Підтримує зв’язані дані, JSON, XML та інші популярні формати. Інтегрується з хмарними сховищами, базами даних та аналітичними сервісами.

Навряд у нас буде час змінити список, але якщо у вас, шановні читачі, є гарні рекомендації чи досвід користування переліченими інструментами — пишіть у коментарях!

Бо на своїх сайтах вони всі потужні, інноваційні, класні та найкращі на ринку. Але єдиний спосіб впевнитись в їхній користі — об’єктивно порівняти.

Випробування інструментів

Ми вирішили розробити тестові сети даних і згодувати їх тулам, щоб перевірити, які з наших запрограмованих помилок інструменти зможуть:

• знайти;
• виправити;
• покращити.

Розроблені тестові сети містять найбільш популярні способи репрезентації, що використовуються в ПЗ:

• структуровані: база даних, CSV, JSON, XML;
• неструктуровані: текст.

Щоб сформулювати проблеми, ми спираємось на стандарт якості даних для ПЗ — ISO 25012. Частину типових помилок ми згенеруємо автоматично, використовуючи інструмент Mockaroo. Частину створимо самописними генераторами, написаними на Python.

Критерії оцінки

Поділимось із вами попереднім списком наших критеріїв оцінки — заповнена табличка буде після захисту диплома.

1. Особисте враження. Зручність користування, зрозумілість інтерфейсу, наявність документації та підтримки.
2. Доступність. Чи може інструмент працювати офлайн? Він платний чи безкоштовний? Чи може він працювати на типовому тестерському ПК?
3. Підтримка форматів даних: які бази, які формати файлів, структуровані та неструктуровані дані.
4. Час виконання. Оскільки наші тестові дані фіксовані та однакові, цікаво порівняти, скільки часу потрібно інструментам для проведення аналізу.
5. Принцип роботи. Інтеграція з ПЗ і постійний моніторинг, чи одноразові запуски та перевірки? Чи є можливість інтеграції в CI/CD?
6. Гнучкість і простота у налаштуванні. Якось я грався з SonarQube, і мені сподобалось, що його можна просто запустити і він видасть список проблем з моїм кодом. Цікаво, чи зможуть інструменти з тестування даних працювати без жодних попередніх налаштувань. І якщо ні, скільки зусиль потрібно на налаштування правил?
7. Якість роботи. Скільки запрограмованих проблем з даними зможе виявити інструмент?
8. Тестова звітність. Наскільки звіт інструмента доступний, зрозумілий для сприйняття? Чи є візуалізація даних і проблем з ними?
9. Інтеграція з ШІ. Все краще з ШІ, цікаво, що можуть запропонувати розробники в цій сфері :)
10. І вишенька на торті — якщо інструмент чудово аналізує дані, чи може він сам генерувати правдоподібні набори даних за заданими правилами?

Тут і далі по тексту, коли використовується займенник ми, робота здебільшого виконана Владиславом 😀

Два роки тому, до початку повномасштабного вторгнення і презентації світу ChatGPT, я вирішив дослідити, що можуть запропонувати нам, QA-інженерам, інструменти для автоматизації code-less та no-code. Провів пошук, обрав інструменти та критерії, ПЗ, яке треба покрити тестами, і почав дослідження. Результати заносив у таблицю, записував і публікував у блог відео роботи з інструментами. На жаль, повномасштабне вторгнення зупинило не тільки роботу, а і бажання працювати над цією темою.

Але, на щастя, завдяки моїм дипломникам, тема знову мене зацікавила. За цей час в ІТ з двох ніг увірвались штучні інтелекти, зокрема ChatGPT.

І якщо два роки тому майже кожен перший інструмент codeless-автоматизації пропонував шаблони і візуальні надбудови над Selenium, тягнучи всі відповідні обмеження і проблеми останнього, то зараз нам стало надзвичайно цікаво, наскільки ситуація змінилась, враховуючи, що розробники додають ШІ в усі можливі продукти.

Яка основна мета роботи? Дослідити, чи мають інструменти codeless-автоматизації інтеграцію з ШІ і як сильно це впливає на якість роботи і можливості автоматизації. Порівняти можливості найбільш популярних інструментів між собою та познайомити спільноту з результатами? Може, ШІ вже виконує роботу краще за нас, просто ми про це не знаємо.

У чому проблема

Коли я 15 років тому почав працювати в тестуванні, на ІТ-конференціях вже розповідали, що ручне тестування скоро «помре» — майбутнє винятково за автоматизацією. Останні років п’ять я періодично читаю публікації, що codeless/ШІ

• замінить розробників, і звичайні користувачі без технічної освіти зможуть створювати в конструкторах сайти та застосунки;
• замінить складну і часто не прозору роботу автотестерів, і бізнес, користувачі, зможуть з мінімальними зусиллями покривати більшість своїх сценаріїв;
• замінить користувачів — нащо людям взагалі щось робити, якщо роботи роблять все краще?

Можна ставитися до цієї ідеї скептично і казати, що такого ніколи не буде. А можна спробувати об’єктивно виміряти, наскільки ми далеко від технологічної сингулярності.

А якщо роботи не заберуть нашу роботу, то як нам максимально використати їхні можливості, щоб покращити свої ефективність і продуктивність?

Ці два зображення вже згенеровані ШІ. Залишу їх тут. Так коли термінатори знищуватимуть людство, у нас буде документальне підтвердження, що ми з ШІ дружили :)

Аналіз ринку

Одна зі складних задач, що ми собі поставили, — обрати інструменти для аналізу. Якщо ви швидко пробіжитесь пошуковиками, то різні сайти пропонують різні за довжиною списки інструментів, різного ступеня заангажованості. Тому, щоб запобігти упередженості, ми проаналізували інформацію з восьми різних джерел, і на їхній основі склали свій список. Визначити, який інструмент крутіший за об’єктивним списком критеріїв, — одна із цілей диплома.

Після аналізу ми обрали вісім інструментів (з кількістю джерел — просто збіг):

Testim — це платформа для автоматизації тестування веб- та мобільних застосунків з використанням штучного інтелекту. Вона дозволяє автоматизувати тестування без написання коду, прискорюючи процес створення тестів та знижуючи витрати на обслуговування.

Katalon Studio — це інструмент для тестування, який дозволяє створювати та виконувати автоматизовані тести для веб- та мобільних додатків. Він підтримує як кодування, так і роботу без написання коду.

ACCELQ — це інструмент для автоматизації тестування, який використовує штучний інтелект. Він дозволяє створювати та виконувати тести для веб- та мобільних застосунків, а також інтегрується з іншими інструментами.

Perfecto — це платформа для тестування веб- та мобільних застосунків. Вона дозволяє створювати та виконувати тести, а також аналізувати результати тестування.

Applitools — це платформа для візуального тестування та моніторингу. Вона використовує штучний інтелект для автоматизації тестування і забезпечує високу якість застосунків.

Functionize — це інструмент для автоматизації тестування, який використовує штучний інтелект. Він дозволяє створювати та виконувати тести для веб- та мобільних застосунків.

mabl — це інструмент для автоматизації тестування, який використовує штучний інтелект. Він дозволяє створювати та виконувати тести для веб- та мобільних застосунків.

Testsigma — це уніфікована хмарна платформа для автоматизації тестування, яка дозволяє автоматизувати тести у п’ять разів швидше, написати тести простою англійською мовою за допомогою NLP-скриптів, виконувати тести на вебсайтах, мобільних застосунках та API в одній платформі, інтегрувати з CI/CD-пайплайном для безперервного тестування та автоматично підтримувати тести за допомогою штучного інтелекту.

Найбільше нас непокоїть у списку вище ось що: якщо випадковим чином перемішати назви інструментів та їхній короткий опис, ніхто не помітить різницю.

Певно, список змінюватись не буде, але якщо у вас, шановні читачі, є гарні рекомендації чи досвід користування переліченими інструментами — пишіть в коментарях!

Критерії оцінки

Поділимось із вами попереднім списком наших критеріїв оцінки — заповнена табличка буде після захисту диплома. Ми вирішили частково перевикористати попередньо створені критерії, бо вони вже непогані:

1. Особисте враження. Зручність користування, зрозумілість інтерфейсу, наявність документації та підтримки. А ще обов’язкове демо. Нас дуже засмучує той факт, що не можна просто взяти і завантажити тріал — треба обов’язково прийти на один-два мітинги з розробниками інструменту і маркетологами.
2. Доступність. Чи може інструмент працювати офлайн, чи тільки в хмарі, чи на серверах розробника? Він платний чи безкоштовний? Чи може він працювати на типовому тестерському ПК? Якщо дають тріал, то на який термін? І з якими обмеженнями?
3. Можливості тестування. Ми обрали продукт і написали до нього набір позитивних та негативних тест-кейсів, які збираємось автоматизувати, і перевірити, як швидко і з якої спроби в нас вийде це зробити. Це один з найголовніших критеріїв успішності.
4. Оптимізація тестування. Чи підтримує інструмент паралельне виконання тестів, групування їх за мітками чи в test suits? Чи має інструмент можливість налаштовувати preconditions та postconditions? Чи можна їх сконфігурувати не для окремих тестів, а для груп? Ну і, звісно ж, DDT. І хоча всі вимоги звучать очевидно, вас може здивувати, що два роки тому далеко не всі інструменти могли похвалитись відповідними фічами. Тим цікавіше побачити прогрес!
5. Швидкість виконання. Нас цікавить умовний час створення тестів з нуля. І час виконання. Який би крутий інструмент не був, але якщо тести виконуються годинами, його сфера використання звужується.
6. Тестова звітність. Якість і кількість інформації про виконання тестів і, головне, — опис помилок, якщо вони трапляються. Наявність скриншотів чи відеозаписів. А може навіть root cause analisys від ШІ.
7. Інтеграція та сфера використання. З чим здатен працювати інструмент: Web, Desktop (Windows, Linux, Mac OS), Mobile? Чи може він перевірити API? Під’єднатися до бази даних? Зарепортити баг до Jira? Стати частиною CI/CD-пайплайну?

За кожним критерієм ми плануємо виставити оцінки і знайти переможця. А також написати коротку інструкцію, як користуватись інструментами, і поради, коли це дійсно варто робити.

Тут і далі по тексту, коли використовується займенник ми, практична робота здебільшого виконана Олегом 😀

Яка основна мета роботи? Звісно ж, зробити щось корисне для себе і для спільноти. А саме — дослідити рішення, що вже представлені на ринку, порівняти їх можливості та реалізувати власне, що вирішує конкретно мої проблеми. Тобто, як мінімум, спільнота дізнається більше про різні наявні mock-сервіси. І ми, інженери, зможемо проводити інтеграційне тестування ще ефективніше, а як максимум — отримаємо власний опенсорс-продукт, який зможемо розвивати та робити максимально зручним саме для нас.

У чому проблема

Велику частину своєї кар’єри я займався тестуванням в Enterprise-проєктах: телекоми, банки, безпека. Всі рішення такого масштабу складаються з багатьох продуктів та сервісів, тісно інтегрованих одне з одним. І, як це часто буває, різні системи розроблюються з різною швидкістю.

І тестування деяких продуктів часто блокується на невизначений термін через відсутність 3rd-party-вебсервісів, які розробляє інша команда, що фізично перебуває на іншому боці Землі і комунікує з вами, в кращому випадку, винятково через тікети в Jira.

Мій перший серйозний досвід використання моків був майже 10 років тому. Я і ще декілька команд працювали над сервісами, що разом мали стати великою телеком-системою. І ми мали інтегрувати наші продукти з 3rd-party-сервісом, що розробляв інший вендор. Цей сервіс мав бути готовий «на вчора», але розробка затягнулась. Ми провели тестування всіх доступних функцій, використовуючи SoapUI, і чекали початку інтеграційного тестування.

Я вивчав документацію SoapUI, щоб зробити свою роботу більш ефективною, і вичитав, що, згідно з API-тестами, можна створити власний мок-сервіс у вигляді jar-файлу, навіть з логікою, написаною на Groovy. Далі можна просто закинути його на Application server типу Tomcat, і користуватись. Я спробував, і воно запрацювало!

Потім не менш як рік всі наші команди користувались моїми моками для тестування, особливо для негативних сценаріїв, тому що реальний 3rd-party-сервіс не давав можливості просто і безболісно створити деякі рідкісні тестові випадки.

Уроки з цієї історії:

1. Автотестер — це не тільки тести для UI писати. Як AQA-інженер я використав свої знання та навички для розв’язання проблеми і прискорення розробки.
2. Робити SOAP-моки, використовуючи не найбільш зручний інструмент і мову, і винятково для Tomcat, — цікаво, але не достатньо універсально.

Мій другий серйозний досвід роботи з моками — великий банківський проєкт. На UAT команда DevOps розгорнула всі сервіси і забезпечила повну інтеграцію всього з усім. А на DEV — розгорнули необхідний мінімум і сказали, що в них недостатньо ресурсів.

Тож ми вирішили самотужки замінити відсутні сервіси, розгорнувши docker-контейнер з мок-сервісом. Він давав змогу створювати статичні відповіді на конкретні REST-запити. Всі налаштування — через API. Це дійсно гарний варіант, але не достатньо універсальний, особливо у випадках, коли система очікує різну поведінку, коли на той самий endpoint відсилається різний payload. І треба шукати компроміси.

Уроки з цієї історії:

1. Команда розробки теж зацікавлена в результаті та може допомогти з моками.
2. Треба йти на компроміси, щоб мати можливість протестувати хоч щось, бо рішення не універсальне.

Тож в якийсь момент я вирішив, що просто зобов’язаний створити мок своєї мрії!

Аналіз ринку

Будь-яка ґрунтовна робота має починатись з дослідження. Тож ми пошукали, що є в інтернеті:

Apidog — інструмент для створення моків API, має застосунок і вебверсію, має нейронку для створення динамічних моків з типу реальними респонсами (як саме — під питанням, можливо ChatGPT), має безкоштовну версію, або ж розраховане на великі проєкти або більші команди. Має якийсь просунутий рівень створення моків. Підтримує протоколи HTTP(S), gRPC, Socket (TCP), GraphQL, WebSocket тощо, імпорт/експорт даних в різних форматах: OpenAPI, Markdown, HTML.

Mimock — інструмент для мокування API, має вебінтерфейс, опенсорс, підтримує статичні моки та популярні протоколи.

Postman — популярний інструмент для розробки та тестування API. Він також має функцію мок-сервера, яка дозволяє генерувати моки API з колекцій запитів та відповідей.

Mocki — інструмент для мокування API, платний. Має можливість писати логіку респонсу і надавати динамічні відповіді. Підтримує протокол HTTP(S).

Mockoon — простий у використанні інструмент для мокування API. Опенсорс, має можливість додавати динамічні відповіді. Підтримує протокол HTTP(S).

WireMock — інструмент для мокування API, написаний на Java, має велике ком’юніті. Є опенсорс і хмарна платна версія. Є підтримка протоколів HTTP, graphQL, gRPC.

MockServer — інструмент для мокування API, має UI, доступний безкоштовно і є опенсорс-продуктом. Має можливість налаштувати динамічну відповідь. Підтримує HTTP, HTTPS / TLS, SOCKS, etc.

Mountebank — інструмент для мокування API. UI підтримується, але не «з коробки», а окремим плагіном. Має можливість створювати моки через API, можливість налаштувати динамічну відповідь. Є опенсорс-продуктом і підтримує протоколи TCP, HTTP, HTTPS, SMTP.

Навряд ми будемо значно змінювати список, але якщо у вас, шановні читачі, є гарні рекомендації чи досвід користування переліченими інструментами — пишіть в коментарях!

Фічі, над якими ми працюємо — вони ж критерії оцінки конкурентів

1. Підхід. Плануємо писати на Python FastAPI, тому що ми знаємо Python. Як базу, принаймні на початку, ми б хотіли використати щось максимально просте — типу SQLite. Але з можливістю перемкнутися на серйознішу базу за потреби. Для простоти використання — створити встановлюваний пакет в PyPI та опублікувати Docker image.
2. Доступність. Ми націлені на опенсорс: код буде викладено на GitHub і, відповідно, ми не плануємо брати плати за використання сервісу.
3. Підтримка протоколів. Почнемо з HTTP, як найбільш вживаного. Далі плануємо додати TCP sockets, а далі — залежно від ситуації.
4. Інтерфейси. Легкий Web UI і API-інтерфейс, які дадуть можливість керування моками у найбільш зручний на поточний момент спосіб.
5. Статичні моки. Необхідний мінімум, який є у всіх моків — дати можливість повертати статичну відповідь на будь-який запит, URL якого відповідає regexp.
6. Динамічні моки. Те, чого мені завжди бракує — можливість самостійно написати кілька рядків коду, які зможуть розпарсити запит і повернути респонс. Поточна мета — wysiwyg-редактор на UI та підтримка Python-скриптів на бекенді.
7. Імпорт/експорт налаштувань. Дрібничка, але має сильно спростити життя для бекапу чи розгортання моку в іншому середовищі.
8. Налаштування затримки. Ще одна дрібничка, яка мені потрібна напрочуд часто — налаштувати затримку в N секунд перед відповіддю. Щоб потестувати поведінку застосунків, поки вони очікують на відповідь.
9. Глобальні налаштування. Можливість вказати поведінку мок-сервіса за замовчуванням — що повертати, якщо сервіс не замоканий? 404 чи 200? Чи додати якийсь пейлоад?
10. Запам’ятовування запитів. Типова ситуація: запустив мок, інші сервіси роблять до нього запити. Шукаєш їх в лозі і по одному налаштовуєш через інтерфейс: реквести і респонси. А хотілося б зайти на UI і побачити список запитів, на які ще не налаштовані відповіді та просто вказати потрібні. Вважайте, половина роботи вже зроблена автоматично!
11. Логування. Ми хочемо бачити на UI статистику, які сервіси і як часто запитуються, подивитись деталі запиту за потреби.

Власне, це поки весь список. Небагато, але все необхідне і головне — своє. Питання до спільноти — що ви думаєте? Якими моками користуєтесь? Якої фічі в моках не вистачає вам найбільше?

Стежте за анонсами! Плануємо показати робочий прототип через деякий час після захисту диплома.

Розкажіть про типові проблеми з даними, які у вас були під час тестування. Чи ви тестуєте ETL? Які у вас є лайфхаки?

І поки ви очікуєте на результати нашого дослідження, можете робити припущення, які інструменти ввійдуть до трійки наших лідерів і, можливо (сподіваюсь), стануть широко вживаними у нашій спільноті!

Дякуємо, що дочитали.

Друзі, просто зараз я збираю гроші на РЕБ для 18 ОБМП. Минулого року ми з вами вже зібрали і поставили 8 штук, але цього замало, а ще наш ворог починає використовувати дрони на інших частотах, тож наші РЕБ мають ставати складнішими, і, на жаль, дорожчими.

🎯 Ціль: 120 000 ₴
🔗Посилання на банку
send.monobank.ua/jar/2Lhz7iG49r