Порівнюємо No-Code/ Low-Code інструменти автоматизації: Leapwork, Tosca, Testim і Testigma
Привіт, мене звати Дмитро, і я вже понад 5 років працюю у сфері тестування. Приблизно три роки на одному з проєктів в ІТ-компанії Customertimes я почав вивчати Tricenris Tosca — інструмент автоматизації без використання коду, а також маю бекграунд як Java QA Automation.
Тож у цій статті я хотів би поділитися своїм досвідом роботи з автоматичним тестуванням та розглянути No-Code/Low-Code automation tools на прикладі Testim, Testigma, Leapwork та Tosca.
Ця стаття буде корисна командам, які шукають рішення для покриття продукту автоматизованими тестовими сценаріями без використання коду та можливістю залучати до таких активностей Manual QA спеціалістів.
Framework та No-code automation tools
Насправді No-code automation інструменти можна розглядати як еволюцію Cucumber фреймворку, вперше випущеного у 2008 році та написаного мовою Ruby. Cucumber створили для того, щоб допомогти бізнес-аналітикам та програмістам працювати над спільним визначенням вимог до ПЗ і автоматизувати роботу у вигляді специфікацій.
Такі інструменти, як Tosca, Testim, Testigma, Leapwork та інші, — це досить розвинута версія підходу Cucumber фреймворку, де замість складного коду використовують інтуїтивно зрозумілий інтерфейс, який дозволяє створювати тести за допомогою візуального редактора, без потреби писати код.
Що ж таке фреймворк? Фреймворк — це структура або платформа, яка допомагає розробникам швидко і легко створювати програми з використанням заздалегідь побудованих блоків. Для автоматизаторів тестування фреймворки є дуже важливим інструментом, який дозволяє створювати стабільні, масштабовані та ефективні тестові сценарії.
Здебільшого універсальним рішенням для налаштування процесу автотестування є заздалегідь написаний фреймворк, що має певні архітектурні паттерни, залежності, налаштування та інші технології для створення моделей даних, взаємодію з UI-елементами, базою даних, API тощо. Ба більше, у цьому можуть допомогти внутрішні процеси в команді: єдині правила написання коду, менторство, код ревью, управління та інше.
Наприклад, у Customertimes ми створили власний досить потужний фреймворк для написання тестів під Salesforce продукти на Java. Для таких проєктів немає необхідності кожен раз «вигадувати велосипед» — простіше працювати зі стандартизованою структурою класів та методів, паттернів із залученням готових фреймворків. Крім того, у ньому є багато утиліті-класів для роботи з лейаутами, пермішнами, апекс-класами та багато іншого, пов’язаного саме із Salesforce.
Тож по суті no code/code less інструменти є такими самими фреймворками, з такими ж технологіями для взаємодії з уже відомими компонентами. Однак ми не можемо внести зміни у них та оптимізувати під наші потреби, що іноді буває досить критичним. Також у деяких випадках ми не можемо використовувати надважливі інструменти роботи з кодом, маніпуляцій з даними, конфігурацій та низькорівневих взаємодій тощо.
Усі інструменти, які ми розглянемо — Testim, Testigma, Leapwork та Tosca, — трохи схожі між собою. Усі вони мають функцію запису користувацьких кроків: юзер включає цей режим і починає мануально натискати на кнопки, вводити дані, а тула самостійно переводить це в формат її внутрішнього синтаксису.
До речі, на рекординг модулі розробники часто прикручують AI-технології, тому в майбутньому цей процес буде зручним. Наразі частково ця функція може бути корисною, але з погляду стабільності тестів такий підхід є не кращою практикою, адже при зміні будь-яких умов на вебсторінці тести будуть падати.
Ще одною спільною характеристикою є робота з Rest API. На мою думку, в усіх інструментах це схоже на роботу в Postman, але з додатковою можливістю використовувати параметри та робити відносно прості маніпуляції з JSON-файлами.
Іншими словами, ми зможемо працювати тільки з очікуваною для нас схемою API. Якщо, наприклад, нам доведеться працювати з великими масивами даних, з динамічною структурою JSON-файлу, то, скоріше за все, без використання мов програмування ми не зможемо цю проблему розвʼязати.
Насамкінець, усі тули спрощеної автоматизації мають готові рішення для збору статистики, інтеграцію з CI продуктами, можливість формувати та налаштовувати звіти (зручніше, ніж читати Алюр репорт), інтеграцію з тест-менеджмент системами.
Перейдімо ж до огляду кожного інструмента.
Leapwork
Leapwork — це платна no-code automation platform для тестування веб- та десктоп-застосунків, мобільних вебзастосунків, віджетів та інших технологій. Leapwork має вбудований графічний інтерфейс для «візуального програмування» з перетягуванням блоків функціональності та з’єднання їх між собою.
Leapwork підтримує запуск тестів на багатьох платформах, включаючи Windows та Linux. Однак наразі не підтримується на Mac-платформі.
Інструмент складається з трьох основних компонентів: Studio, Controller (сервер) та Agent.
Для розгортання проєкту нам потрібна інфраструктура й сервер з базою даних. Або ж можна використовувати cloud-рішення, такі як Amazon Web Services (AWS) або Microsoft Azure.
Таким чином, користувач може використовувати Leapwork в хмарному середовищі без необхідності налаштування та управління власною фізичною інфраструктурою. Однак сам процес потребує додаткових зусиль на старті та підтримку, можливо навіть залучення DevOps-спеціаліста.
Функціональність
Leapwork дає багато можливостей для маніпуляцій з браузером та вебелементами.
Наприклад, запуск веббраузера, навігацію по вебсторінках, пошук та клік по вебелементах, введення тексту, завантаження файлів, очищення та отримання кукі-файлів, взаємодію з випадними списками, перевірку стану чек-боксів та радіокнопок, отримання значень атрибутів елементів, виконання JavaScript-коду та багато іншого.
Його можливості задовольняють більшість наявних потреб взаємодії з вебкомпонентами.
Плюси
Leapwork має досить цікавий підхід для роботи з HTML-документом, виявлення унікальних атрибутів вебелементів з можливістю їх корегування.
Для цих цілей Leapwork зробив досить зручний та інтуїтивно зрозумілий редактор вебоб’єктів. Ми можемо записувати сценарії, ходити по структурі дерева документа вебсторінки.
Рівень абстракції дозволяє групувати пов’язані елементи та повторно використовувати їх у різних тестових сценаріях.
Якщо локатор елемента зміниться, ми можемо внести зміни тільки в одному місці — у нашому об’єкті вебелемента, і всі тестові сценарії, які використовують цей об’єкт, автоматично використовуватимуть оновлені локатори.
З погляду логічних операцій тут також все на високому рівні. Є можливість виконувати обчислення, працювати з регулярними виразами, порівнювати значення, використовувати вейтери, лупери, світчі, генерувати дані і багато іншого.
Особливо приємна фіча — це можливість виконання C# коду. Це непоганий обхідний шлях для нетипових ситуацій, коли стандартний синтаксис та методи не задовольняють поточні цілі.
З додаткових позитивних характеристик продукту є те що, ми можемо писати SQL query для взаємодії з Oracle, SQL Server, DB2, MySQL, MongoDB та іншими базами даних. Також ми можемо використовувати Excel-файли як місце розташування тестових даних, конфігурацій, а також записувати результати в такий файл, якщо в цьому є потреба.
Leapwork має багато додаткових можливостей, таких як надсилання e-mail-нотифікацій в рамках рану тестів, репортинги, інтеграції інших продуктів, календарні запуски тестів, використання тригерів та інші досить розповсюдженні фічі для подібних інструментів.
Мінуси
Документація Leapwork декларує можливість тестування мобільних вебзастосунків, але я не знайшов розділу тестування саме мобільних застосунків в розділі Solutions, а це досить критичний недолік.
Як на мене, робота з автоматизованими сценаріями у вигляді блок-схеми не є дуже зручним рішенням та не вирішує глобальних питань візуального сприйняття алгоритму.
Оскільки клієнт робочого середовища є десктоп-застосунком, гіпотетично ми можемо мати проблеми з версійністю, оновленням продукту, DevOps підтримкою та іншими проблемами. З цього погляду Web-рішення, такі як Testim та Testigma, є гнучкішими.
Більше детальної інформації ви можете знайти в цьому розділі.
Вартість
Вартість ліцензії для мене лишилась невідома, оскільки портал розкриває ці дані тільки після офіційних контактів.
Однак кожен може скористуватися trial-ліцензією безкоштовно та оцінити можливості продукту самостійно.
Tricentis Tosca
Компанія Tricentis має низку продуктів для повного процесу роботи в команді, я б назвав це екосистемою продуктів. Там є багато корисних застосунків, інтеграцій, налаштувань: від ризик-менеджменту до зручних інструментів розгортання власних баз даних для імплементації процесу автотестування.
Розгляньмо інструмент Tosca.
Функціональність
Tosca позиціонує себе як Module Based фреймворк, і це говорить про те, що є окремий кластер, в який ми зберігаємо моделі, а тестовий крок — це лише операція над моделлю.
Це виглядає так: я як інженер проаналізував вебсторінку та додав елементи — кнопки, форми, випадні списки — і зберіг це все в модель «Login | Salesforce». Після цього заходжу в тестовий блок, викликаю модель «Login | Salesforce» та виконую над елементами певні дії у певній послідовності. Сам тестовий сценарій є сукупністю таких кроків.
Моделлю в цьому випадку також можна вважати структуру JSON (Request, Response) з усіма параметрами, або модель, що відповідає за операцію над String/JSON/PDF/Excel файлами.
До речі, така реалізація (для UI-компонентів) нагадує типовий Page Object Pattern, якби це реалізовувалось, наприклад, на Java.
Як я згадував раніше, блок TestCases використовує моделі та проводить певні дії над ними. Можна перевикористовувати готові кроки або групу кроків за допомогою абстрактних сутностей, додавати кроки в теки, генерувати дані, робити сценарії на кшталт «Try-Catch» операцій, щоб відловлювати помилки, трекати їх в логи або ж робити певні посткроки після завершення тесту.
Також в блоці TestCases можуть бути реалізовані логічні операції, умови, цикли тощо. Тестові сценарії можна конфігурувати окремо або групами для простоти налаштувань під різні інженерні потреби.
Тест кейси після їх виконання групуються у відповідні тест сьюти. Також в системі є модуль з вимогами, вони можуть мати лінки на JIRA тікети, або ці тікети можуть бути занесені в систему самостійно. Принцип роботи достатньо простий, логіка застосунку інтуїтивно зрозуміла. Думаю, саме тому Tosca став найрозповсюдженим продуктом серед розглянутих.
Також хочу додати, що Tosca має суперфічу для роботи з великою кількістю комбінацій через Test Design модуль. Там юзер може налаштувати патерн тесту з умовами та згенерувати сотні тестових комбінацій.
Також юзер може використовувати Excel-файл для таких цілей і при певних домовленостях на проєкті такі сьюти можуть бути згенеровані командою бізнес-аналітиків.
Test Design модуль ми з командою перевіряли: закривали сотні тестів таким чином, оскільки специфіка проєкту потребувала великої кількості перевірок на основі комбінацій. До речі, це частково і є своєрідною частиною імплементації принципів Cucumber фреймворку, про який ми говорили на початку статті.
З власного досвіду роботи з інструментом можу визначити такі плюси та мінуси:
Плюси
Tosca працює з Web-технологіями, API, DataBase, Mobile testing, а також з десктоп-застосунками, файлами, форматами та багато з чим іншим. Також є достатньо велика кількість налаштувань, операцій над об’єктами, «синтаксичного цукру».
Якщо налаштувати проєкт, використовуючи найкращі практики, то його досить легко підтримувати, і це не потребує великої команди дорогих спеціалістів. Платформа може бути інтегрована в
Щодо навчання, продукт має ідеальну документацію та навіть власну академію із записаними лекціями, тренінгами, завданнями для самоперевірки, практикою. Вони навіть створили систему сертифікацій, які є певними досягненнями серед Tosca користувачів.
Продукт гарно взаємодіє з SAP, Salesforce, Angular та іншими технологіями.
Мінуси
Одним із недоліків, на мій погляд, є інфраструктура і налаштування проєкту. Вона не виглядає достатньо надійною на перший погляд. Так само, як в Leapwork, треба встановити застосунок, пройти етап ліцензії, створити локальну віддалену або хмарну інфраструктуру на основі бази даних, надати доступ користувачам.
Але незручною є відсутність Git технологій. Tosca працює за принципом Check in — Check out. Тобто якщо я зайняв теку, то маю право редагувати те, що там розміщено, а інші інженери мають тільки права читання до моменту мого Check out процесу. Це говорить про те, що велика кількість активних тест девелоперів просто буде заважати одне одному.
Також серед мінусів те, що Tosca доступна тільки на Windows-платформах.
Ще одним недоліком є те, що вона досить довго працює. Порівняно зі стандартним Java + Selenium це дуже помітно. У разі екстреного закриття апки можуть бути втрачені дані, з чим ми також іноді стикалися.
Tosca працює з мобайлом, але практичного досвіду я з цим не мав. Та якщо ж ми не можемо встановити цей продукт на Mac, виникає питання: чи гарною ідеєю буде використовувати її для тестування iOS?
Вартість
Ціна ліцензії також не є публічною інформацією, її можна уточнити у підтримки, але є trial-ліцензії та Tricentis охоче діляться навчальними ліцензіями.
Testim
Testim Automate — це повнофункціональна платформа, яка дозволяє швидко створювати стабільні тести. У Testim є два способи створення тестів: записати їх за допомогою розширення Testim або написати код у вашому IDE.
Є також третій рекомендований підхід для тих, хто хоче писати код — записати тест, експортувати його як код і змінити його у вашому IDE.
Функціональність
Редактор Testim має багато функцій, які дозволяють писати тести без необхідності використання коду.
Групи — можна групувати кроки та використовувати їх повторно, можна вкладати групи в групи. Групування допомагає створювати архітектуру тестів так, щоб юзер не повторював одні й ті самі кроки. Також можна створювати ефективну архітектуру тестів, повторно використовуючи наявні кроки.
Перевірки — для забезпечення відповідності вихідних даних тесту очікуваним результатам. Ви можете налаштовувати перевірки для даних, PDF-файлів, електронних листів, документів Word та багато інших форматів.
Умови — є можливість налаштувати крок або групу кроків для виконання (або пропуску), якщо виконуються певні умови (або ж якщо вони відсутні). Розумні локатори — ці функції роблять ваші тести стабільними. Однак ви можете налаштувати параметри так, щоб вони були більш або менш строгими або навіть надавати пріоритет різним атрибутам.
Цикли — можна виконувати одні й ті самі кроки кілька разів, виконуючи повноцінний ітераційний алгоритм однотипних операцій.
Тестування з використанням даних — Testim дає можливість гнучко використовувати тестові дані для будь-яких цілей. Користувач може використовувати посилання CSV-, Excel- або JSON-файл, що вирішує проблеми конфігурацій, створення попередніх умов для проходження тесту, використання констант та заздалегідь заготовлених моделей даних.
Найшвидший спосіб написання тесту — записати його. Це досить просто зробити, використовуючи розширення Testim. Ви просто починаєте запис у візуальному редакторі Testim, записуєте кроки у вашому застосунку, натискаючи, вибираючи пункти меню, вводячи текст тощо. Результатом буде тест крок за кроком, який можна редагувати візуально.
Плюси
Візуалізація робочого місця та зручність роботи з Testim — це наче витвір мистецтва.
Мобільне тестування в Testim надає широкі можливості для запису та виконання тестів на фізичних та віртуальних пристроях з операційними системами iOS та Android.
Запис тестів можна виконувати на комп’ютерах з операційними системами Windows, Mac або Linux за допомогою веббраузера. Під час запису Testim перетворює кожну дію в крок тесту, який відображається на екрані візуального редактора Testim.
Для створення та виконання мобільних тестів в Testim потрібно встановити Tricentis Mobile Agent (TMA). Цей агент керує фізичними пристроями, підключеними до вашого робочого місця (наприклад, телефон або планшет), а також симуляторами/ емуляторами, що працюють на вашому робочому місці.
До речі, цікаво, що Tricentis є партнерами проєкту Testim. Можливо, цей продукт буде розвиватися і перетвориться в дійсно щось геніальне. Маючи досвід роботи з Tricentis Tosca, я буду не здивований таким результатам.
Щодо інфраструктури, усе також дуже просто: достатньо встановити розширення на браузер, і можна починати працювати. Гарною новиною є те, що завжди є можливість спробувати попрацювати на безкоштовній (лімітованій) версії, або використовуючи пробну ліцензію.
Одною із перевагою інструмента є можливість використання коду. Це нівелює майже будь-які ризики та дозволить обійти деякі блокери, інтегрувати низку сервісів, таких як GitHub, Jenkins, TeamCity тощо.
Документація, навчальні ресурси, демопроєкти також зроблені на високому рівні. Ви можете запустити тест будь-якої складності, та й, власне, будете готові повторити щось подібне.
API-тестування не має якихось бенефітів відносно інших розглянутих продуктів, але воно дуже наближене до Postman та навіть використовує JavaScript синтаксис, що тільки розширює можливості. Мені здається, що не треба робити UI-компоненти для API-запитів, це виглядає трохи абсурдно, наприклад у тому ж Tosca.
Також Testim реалізував зручну конфігурацію та роботу з тестовими даними через заздалегідь заготовлений JSON-файл. Це також гарне рішення, ідеальне спрощення того, де інтерфейс просто не потрібен. Цей файл можна спокійно шерити, робити версійність, і це, як на мене, зручніше, ніж вести конфіги, наприклад, в Tosca.
Мінуси
Testim реалізує досить нестандартну концепцію для роботи з Web UI компонентами, а саме роботу з матрицею селекторів замість одного статичного локатору елемента. Якщо в стандартній практиці ми намагаємось уникати взаємозв’язку локаторів зі структурою DOM-дерево, щоб зменшити вірогідність падіння тесту після змін в HTML-файлі, то Testim працює навпаки: він запам’ятовує всі залежності і шляхом автоматичного аналізу вагових коефіцієнтів намагається знайти цей елемент у різних конфігураціях сторінки.
Таке рішення одразу викликає сумніви щодо можливості Testim розвʼязувати ці задачі на практиці для складних селекторів. І це не безпідставно. Я, наприклад, спробував цей підхід для заздалегідь заготовленого складного прикладу пошуку UI-елемента, що має дублікати та розташований на сторінці з великою кількістю динамічного HTML контенту.
Технологія Smart Locators із вбудованим AI так і не змогла вдало записати цей елемент. Ба більше, для вирішення проблеми довелося витратити досить багато часу.
Тобто теоретично і, особливо, у перспективі це може бути дуже зручно — відмовитись від статичних селекторів. Це дасть змогу використовувати тільки запис кроків користувача, без додаткових дій, проте наразі мені було б комфортніше вводити статичний XPath, і Testim, на жаль, не надає такої можливості.
Не виключаю, що за правильного підходу та подальшого вдосконалення продукта такий недолік може стати флагман-фічею та переконфігурувати ринок AQA-технологій, однак наразі я бачу в цій концепції деякий негативний вплив на точність створення автоматизованих скриптів. Деталі є тут.
Вартість
По-перше, усе досить прозоро: не потрібно нікому писати, щоб дізнатись прайс. По-друге, ліцензія достатньо вартісна. Тож щоразу, коли маркетологи казатимуть, що подібні тули зменшують ціну на автоматизацію, тримайте в голові цей цінник.
Місячна ціна видається непоганою, але купувати ліцензію можна щонайменше на рік. І економічна ефективність лишається відкритим питання, особливо для українського IТ-ринку, де такі продукти незвичні.
Подробиці про ціни тут.
Testsigma
Testsigma є повнофункціональною платформою для автоматизованого тестування, яка надає інструменти для створення, управління та виконання тестових сценаріїв для веб- та мобільних застосунків.
Робота з Testsigma стала для мене досить приємним відкриттям.
Функціональність
Цей продукт, як і інші, також має потужний інтерфейс для запису тестових степів, але мені подобається, що вони імплементували так званий Page Object. Це своєрідна можливість працювати з тестами у два етапи.
Спочатку ми проходимо сценарій, у нас формуються компоненти та назви скрінів, на яких вони розміщені. Потім ми уточнюємо валідність наших локаторів, робимо їх стабільнішими, ідентично тому, як у Java. І тепер ми матимемо стабільний UI функціональний тест.
У наступному сценарії, якщо мені потрібно буде перевикористати уже наявний UI-компонент, я просто звернуся до нього в рамках формування тесту. Таким чином ми маємо потрібний нам рівень абстракції, що спростить:
- підтримку тестів;
- роботу в команді;
- окремий концептуальний процес роботи з локаторами, як на мене, дуже важливий для стабільності тестів.
Як розпочати роботу в Testsigma? Необхідно запустити Testsigma Agent, що буде контролювати локальні ресурси комп’ютера, та встановити браузерне розширення. Після цього ми зможемо працювати з браузером, мобільними девайсами (віртуальними, реальними) та контролювати операції дебагу.
Testsigma надає рішення для перехресного тестування мобільних застосунків з використанням технології end-to-end. З її допомогою можна автоматизувати тестові сценарії і виконувати їх як на платформі Android, так і на iOS, використовуючи англійську мову.
Платформа дозволяє створювати плани тестування, керувати наборами тестів та запускати їх на різних пристроях, включаючи реальні пристрої та емулятори. Крім того, Testsigma підтримує інтеграцію з популярними тестовими платформами, такими як BrowserStack та Sauce Labs, що дозволяє паралельно виконувати тестування на кількох пристроях.
Усе достатньо просто: завантажуєте APK-файл, обираєте доступні способи взаємодії з мобільним пристроєм, для платних версій можливостей набагато більше.
Робота з mobile UI елементами схожа на роботу з Apium-інспектором. Принцип той самий, що і робота з UI-компонентами: робота з локаторами та діями над ними.
Плюси
Testigma несе в собі достатньо велику палітру функціональних можливостей. Щобільше, так-чи інак, поєднує в собі позитивні сторони усіх розглянутих нами сьогодні тулів:
- працює з коробки, та не вимагає складного налаштування, має можливості створення функцій під операції, яких немає під капотом;
- має зрозумілу та логічну архітектуру, яка несе в собі кращі практики, а спосіб створення та підтримка об’єктів дозволяє мати рівні абстракції та перевикористання сутностей;
- швидкий розвиток автоматизованих тестів для вебзастосунків, REST-сервісів та навіть мобільних застосунків для проведення Agile-тестування. На жаль, не перевірено на реальному проєкті, але ввідні умови та задекларовані можливості достатньо потужні;
- підтримка організації та запуску тестів на різних середовищах, різних віртуальних та локальних машинах, на різних віртуальних та локальних давайсах, різних браузерах та інших кастомних конфігураціях;
- проста інтеграція сервісів Slack/Email Notification/Jenkins/Browser Stack/Sauce Lab/Jira;
- існують деякі можливості з використання штучного інтелекту та допоміжних алгоритмів. Наприклад: автоматичний аналіз не працюючих тестових кроків, та пропуск, тестів де вони використовуються, для запобігання втрати часу на тестовий ран. Також є деякі «фішки», що полегшують роботу із селекторами;
- написання алгоритмів на Java дозволяють обійти більшість існуючих блокерів, пов’язаних з недосконалістю фреймворку в специфічних умовах для конкретного проєкту.
Мінуси
Testigma не є досить популярною платформою, опираючись на вакансії, що мають конкретну цю технологію як критерій. Це є досить важливий фактор для вибору інструменту.
Інструмент достатньо функціональний, але для новачків може стати справжнім викликом робота зі структурами даних, об’єктами, тестовими сценаріями будування архітектури тестів, використовуючи кращі практики. Освоєння Testigma може зайняти деякий час.
Як і всі інструменти такого типу, можуть бути проблеми з автоматичним визначенням локаторів з використанням штучного інтелекту та аналізу сторінки.
Вартість
Серед інших продуктів цінова політика також вирізняється. По-перше, безкоштовна версія має достатньо великий спектр можливостей. По суті, платні версії надають додаткові ресурси та можливості, а не ріжуть функціонал.
Для старту процесу буде достатньо й безкоштовної версії. Також є можливість оплачувати платформу помісячно, а це зменшує фінансові ризики та навантаження.
Спробувати цей продукт на практиці можна за посиланням.
Коли обирати No-Code Automation Tools
Пропоную виконати вправу для порівняння імплементації та оцінки використання автоматизації тесту за допомогою коду (я обрав Java) порівняно з No-Code automation Tools (я обрав Tosca).
Щоб вправа була об’єктивна, нам потрібно знайти завдання середньої складності та бажано не на рівні UI. Адже відразу можна констатувати, що при складній низькорівневій реалізації тестів бажано використовувати мову програмування, а при простій UI-реалізації No-Code automation інструменти матимуть перевагу завдяки простоті та швидкості написання.
Умови задачі: є об’єкт Users, нам потрібно навчити наш алгоритм забирати, записувати, генерувати та редагувати дані щодо цього об’єкту, використовуючи API-ендпойнти.
Java
Тут ми розглянемо реалізацію API тест-степу на прикладі використання Rest Assured, Lombok та інших архітектурних патернів. Зауважу, це приклад типового рішення, простого порівняння технологій. Щоб зробити все за типовою практикою, нам потрібно поділити процес заведення API запиту в проєкт на кілька етапів:
1. Аналіз.
2. Створюємо модель даних:
— дата-модель для ініціалізації полів («філдів») та їх типів;
— Enum для імен полів, які будуть використовуватися в запитах та відповідях API;
3. Додаємо наші API-запити до класів для виконання запитів. Скоріше за все, для генерації API запитів ми будемо використовувати наявні утиліти класи та методи, на фінальному етапі у нас повинні з’явитися GET, POST, PUT, DELETE та інші типи запитів щодо об’єкту.
4. Використовуючи мову програмування, я не хочу щоразу вводити руками всі необхідні поля, тому мені знадобляться додаткові класи для генерації значень полів цього об’єкту.
4.1. Також важливо закласти можливість аналізувати наявні дані користувачів у нашому оточенні, наприклад, знаходити юзерів за ID, або значенням Gender, або зберегти всіх користувачів яким, наприклад, більше 20 років. Тому нам потрібно писати власний DataProvider.
5. І тільки тепер я зможу використовувати ці класи в своїх тестових кроках:
Отже, ми бачимо, що така, на перший погляд, проста операція потребує достатнього рівня знань роботи з кодом, ООП, дотримання фреймворку. А в результаті ми маємо готову структуру, яку легко підтримувати й доповнювати.
Вона точно працюватиме надійно та будь-які зміни будуть адаптуватись за невеликий проміжок часу. Тобто основна інвестиція часу йде на початку роботи, а потім ми просто використовуватимемо уже написаний код швидко і без зайвої уваги на його реалізацію.
Також зверніть увагу, що в наших запитах ми маємо можливість забрати усіх користувачів, а потім за допомогою стрімів відфільтрувати потрібного нам юзера (юзерів) та працювати одразу з усіма полями об’єктів, використовуючи лише єдиний запит на Back End.
Tosca
У роботі з Tosca та здебільшого усіма аналогічними продуктами все буде схоже на роботу з Postman.
1. Моделюємо структуру Request та Response з відповідними методами, хедерами та параметрами.
2. Передаємо потрібні нам дані для створення дати у тестовому блоці.
3. Валідуємо отриманий результат та записуємо необхідні поля з Response-файлу.
4. Якщо ми будемо використовувати цей запит неодноразово, то можемо обернути його в реюзабельний компонент. Так цей запит буде простіше підтримувати.
5. Робимо таку операцію для кожного необхідного для нас випадку GET, POST, PUT, DELETE запити, а також Генерація даних, Створення даних для окремого кластеру тестів тощо.
На перший погляд виглядає простіше, та можу запевнити, що в перспективі сотень тестів, які треба хендлити та підтримувати, це зовсім не так. На відміну від Java, тут ми не маємо достатньо зручних інструментів для парсингу, фільтру JSON-файлів.
Нам досить складно запам’ятати та повторно використовувати масиви об’єктів. І в деяких випадках ситуація може стати катастрофічною, якщо під рукою немає достойних інструментів для роботи з даними.
Наприклад, Back End може повертати складну структуру: або вам потрібно працювати з високим ступенем вкладеності об’єктів JSON, або просто в період розробки структура JSON файлу буде часто змінюватись.
Якщо ви не оціните ці ризики на старті, то можуть виникнути неприємні ситуації під час написання тестів. А якщо вже трапляються подібні умови, то вивчити і адаптуватися до написання коду буде значно простіше, ніж вирішувати подібні челеджі.
Також, очевидно, у нас збільшується кількість API колів відносно Java-реалізації, для деяких систем це теж може бути критичним лімітом.
Підсумок
Кожен інструмент і технологія має місце на існування і може бути ефективна, якщо враховувати умови розробки продукту та технічні ризики. Бувають проєкти, де треба, наприклад, тестувати
Такий проєкт буде уже автоматизований на Tosca, поки Java-спеціалісти розгорнуть свій фреймворк. Але, по-перше, за такі тули треба платити, по-друге, їм ще достатньо далеко до того, щоб нівелювати можливі ризики, які ми розглянули на прикладі цього кейса.
Висновки
Я не мав змоги досконало протестувати всі інструменти, але з мого аналізу можна зробити деякі висновки. Свої враження я зібрав на малюнку нижче:
Окремо я хотів би зупинитися на комерційній таємниці щодо вартості та спеціальних умов для великих компаній. Це не дуже прозоро, не викликає довіру, особливо якщо у компанії цей процес новий і вам необхідно лише спробувати.
Також варто зазначити, що інформація про No-Code/Low Code інструменти пронизана маркетингом, тому з першого погляду не зрозуміло: чи то воно так є насправді, чи то вони прикрашають реальну картину в презентаційних матеріалах, обираючи прості лабораторні кейси для демонстрацій.
Спеціалістів, що хотіли б спробувати себе в таких технологіях, застерігаю бути обережними, тому що цей досвід може більше ніде не знадобитися, треба бути до цього готовим.
За останні 2 роки в Україні я знаходив
З погляду роботи компанії, використання подібних технологій автоматично додає процеси з оплати та підтримки внутрішнього напряму. Для великих компаній також необхідно буде сформувати критерії для навчання, розвитку та перегляду компенсації спеціалістів.
З погляду взаємодії з клієнтами, ми повинні шарити доступи з ними і у випадку розторгнення договору, весь проєкт потрібно буде клонувати та передавати іншій стороні. Тому замовник теоретично може бути не в захваті від використання подібної «ексклюзивної» технології на його проєкті.
Зрозуміло, що це неминучий технологічний крок — перехід до no-code, low-code механізмів, особливо для продуктів тривіальної складності для автоматизації, але я досі не впевнений, що на зараз це досить надійне рішення з погляду написання та підтримки.
Беріть до уваги низькорівневі кроки, такі як: API, DataBase, потреба у конфігураціях, створення тестових даних, синхронізації даних та інше. Якщо бачите ці особливості проєкту, то, найімовірніше, такі тулзи буде досить ризиковано використовувати.
Але щоб бути впевненими, просто спробуйте. Візьміть середню за складністю задачу та спробуйте реалізувати її за тиждень у вільний між релізами час. Так ви швидко зрозумієте, чи допоможе вам таке рішення на практиці.
Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!
22 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів