Порівнюємо 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, а також з десктоп-застосунками, файлами, форматами та багато з чим іншим. Також є достатньо велика кількість налаштувань, операцій над об’єктами, «синтаксичного цукру».

Якщо налаштувати проєкт, використовуючи найкращі практики, то його досить легко підтримувати, і це не потребує великої команди дорогих спеціалістів. Платформа може бути інтегрована в CI-процес, мати календарні правила ранів, досить зручний репортинг з можливістю його конфігурації.

Щодо навчання, продукт має ідеальну документацію та навіть власну академію із записаними лекціями, тренінгами, завданнями для самоперевірки, практикою. Вони навіть створили систему сертифікацій, які є певними досягненнями серед 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-реалізації, для деяких систем це теж може бути критичним лімітом.

Підсумок

Кожен інструмент і технологія має місце на існування і може бути ефективна, якщо враховувати умови розробки продукту та технічні ризики. Бувають проєкти, де треба, наприклад, тестувати 2-3 форми з великою кількістю логічних відхилень.

Такий проєкт буде уже автоматизований на Tosca, поки Java-спеціалісти розгорнуть свій фреймворк. Але, по-перше, за такі тули треба платити, по-друге, їм ще достатньо далеко до того, щоб нівелювати можливі ризики, які ми розглянули на прикладі цього кейса.

Висновки

Я не мав змоги досконало протестувати всі інструменти, але з мого аналізу можна зробити деякі висновки. Свої враження я зібрав на малюнку нижче:

Окремо я хотів би зупинитися на комерційній таємниці щодо вартості та спеціальних умов для великих компаній. Це не дуже прозоро, не викликає довіру, особливо якщо у компанії цей процес новий і вам необхідно лише спробувати.

Також варто зазначити, що інформація про No-Code/Low Code інструменти пронизана маркетингом, тому з першого погляду не зрозуміло: чи то воно так є насправді, чи то вони прикрашають реальну картину в презентаційних матеріалах, обираючи прості лабораторні кейси для демонстрацій.

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

За останні 2 роки в Україні я знаходив 10-20 вакансій на Djinni за ключовим словом «Tosca». Щодо інших інструментів, я не бачу в LinkedIn багато вакансій навіть всюдисвітно.

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

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

Зрозуміло, що це неминучий технологічний крок — перехід до no-code, low-code механізмів, особливо для продуктів тривіальної складності для автоматизації, але я досі не впевнений, що на зараз це досить надійне рішення з погляду написання та підтримки.

Беріть до уваги низькорівневі кроки, такі як: API, DataBase, потреба у конфігураціях, створення тестових даних, синхронізації даних та інше. Якщо бачите ці особливості проєкту, то, найімовірніше, такі тулзи буде досить ризиковано використовувати.

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

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

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Назва Tosca говорить сама за себе

Шикарная статья, мне понравилось. Я раньше с тоской и прочими такими инструментами не работал, всегда писали фреймворки сами под наши нжды, так что эта статья хорошо расширяет кругозор. Также теперь буду иметь ввиду, что можно весьма хорошо использовать No-Code инструменты такие как Toska и прочие в будущем)) Спасибо автору

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

Дякую за статтю, але я своєї думки не змінив. Low-code та No-code автоматизація це скам :)

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

Дуже цікава стаття, дякую за пізнавальний огляд та аналіз!

Пане Армене, чи можу поцікавитися вашою думкою про лоу-код автомейшн інструменти? Шукаю людей, яким ця історія подобається, щоб зрозуміти для себе переваги. Питаю саме вас, бо сподобалася стаття всього п’ятьом. 3 невідомі (один з них вчора зареєструвався і комент сюди — єдине, що він зробив), ПР менеджер і, власне, ви. Досвід у вас найбільш релевантний, тому і питання до вас.

Наш замовник також колись купився на це, і вклався в low-code систему Qualisystem Cloudshell. З якими ж матюками ми два роки злазили з того лайна. Це треба було все переписати на нормальній мові програмування, весь цей час підтримуючи старі тести. І як я розумію, що і ціна ліцензій була якась захмарна, бо простіше було випросити собі нове залізо для тестування ніж додаткову ліцензію. Страшно лімітований фреймворк, розрахований лише на якийсь один воркфлоу і ні шагу в сторону. Вся хмарна частина тормознута і з калічним інтерфейсом з віконечками амбразурами. Ні на який скейл воно не було розраховано і просто збільшення тестів в сьюті з 10-20 до 50+ призводило до крешів інтерфейсу налаштування в браузері. І навіть коли воно працювало — один і той же тест, що робить ті самі кроки, біг в два-три рази довше в цьому фреймворку ніж після переписування на чистий пайтон, просто через оверхед запуску того фреймворку.

Якщо побачите десь лоу-код тули, то біжіть звідти швидко, бо діла не буде.

Дякую за статтю, прочитав на одному диханні

Сорі, шо багато )
Це вже друга стаття на low-code тему за короткий період часу. Таке враження, що хтось комусь заносить для того, щоб це неподобство популяризувати. До минулої статті написав ряд консьорнів, не відповіли. Спробую тут. Бо таке враження, що заносять за статтю, але не заносять за коменти )

Насправді No-code automation інструменти можна розглядати як еволюцію Cucumber

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

Cucumber створили для того, щоб допомогти бізнес-аналітикам та програмістам працювати над спільним визначенням вимог

можу повірити, що для того геркін придумали, але той огірок тут до чого не дуже зрозуміло.

зручніше, ніж читати Алюр репорт

я вибачаюся, яким саме чином? Саме з тими інструментами я не працював, але трохи бачив EndTest (хоч десь про нього згадають :) ). То яким саме чином то зручний репорт? Він каже по яких локаторах які дії воно зробило. Більше інфи у нього нема. Приклад мого алюр репорта:
1. [loginAction] loginAs (email)
— [loginPage] {emailInput} enterText (someEmail)
— [loginPage] {passwordInput} enterText (superman)
— [loginPage] {signInButton} click ()
2. ...
одразу видно на якій сторінці, з якими елементами (по назві, а не локатору), яка дія і з якими аргументами виконувалася. Високорівневі дії по дефолту схлопнуті, якщо хайлевельно треба подивитися шо тест робив, якщо треба в деталях, то розкриваєш і дивишся з якими саме елементами була взаємодія + є час виконання на кожну дію. Написано в бдд стилі. І ці логи також формуються автоматично, їх в коді писати не треба. Дивитися на імена елементів значно зручніше ніж на локатори. Приведіть будь-ласка приклад репорта якогось інструмента, щоб ми предметно бачили про що розмовляємо. Дякую.
Ну і найголовніше
1. Беремо будь-який лоу код тест автомейшн інструмент і пишемо на ньому 3000 тестів. Потім цей інструмент якось дуже дорожчає, або взагалі перестає існувати. На скільки просто мігрувати всі тести на інший інструмент? Коли пишеш тести з розумом будь-якою мовою на будь-якому інструменті, то можна той інструмент максимально ізолювати і відносно безболісно переїхати за потреби.
2. Що робити з підтримкою? Коли тестів стає багато і змінюється якийсь зашарений компонент на фронті, то падає одразу багато тестів, які треба окремо ручками піти і оновити. Коли є пейдж обджекти/фрагменти, компоненти, екшини і тести написані в бдд стилі (не плутати з кукумбером), то ледь не будь-яка зміна на юаї, яка афектить багато тестів, має відповідну одну зміну в коді тестів і все продовжує працювати.
3. Що робити з пре/пост кондішинами для тестів? Якщо є потреба в створенні перед тестом і видаленні після тесту ряду сутностей через апішку. При чому коли для створення наступної сутності, треба спочатку отримати респонс від попередньої. І тут теж постає питання підтримку, так як контракт апішки теж може мінятися.
4. Ще мене турбують питання гнучкою параметризації тест рану (найпростіший приклад енв) та налаштування і інтеграція з CI, щоб, наприклад, зробити quality gate. Робота з куками та local storage... Це простіші питання і, впевнений, є ряд інструментів, які то все підтримують, але питання гнучкості залишаються відкритими.
5. Я вже не кажу про обмеження. Ми просто погоджуємося, що ми не зможемо покрити все, що хочеться, а тільки те, що дозволить нам тула.

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

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

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

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

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

Я би сказав, на своєму досвіді бачив, що використання Лоу коду було обувлено безпосередньо вимогами клієнта в деяких кейсах. І якщо взяти наприклад шляхи пошуку автоматизованих тулзів для SalesForce, то Гугл в пошуку і видає, щось по типу Provar чи Tosca. Тому вірогідно перед тим як переходити на автоматизацію, клієнт вже спочатку дивиться на те що рекомендують різного роду джерела. І для клієнта це виглядає розумним, тому що здається, що автоматизація на CodeBased солюшені буде надто дорогою через залучення автоматизаторів, а No-Code вимагає тільки мєнюал спеціалістів, які пройдуть деякі базові тренінги. Плюс, якщо подивитись зі сторони бізнесу, фінансів і структури команди, то він не залучає додатковий ресурс, не витрачає час на перехід вже інснуючих тестувальників у Auto QA, він просто зберігає ту ж тім композішен.

Безумовно це дешевше в day 1. Але коли нетехнічний замовник робить такі рішення без залучання технічної експертизи воно, зазвичай, закінчується погано. Been there. Тут дуже важливо дивитися на перспективу. Лоу код інструменти значно дешевші на початку, але це той випадок коли на дистанції вони стають дорожчими за рішення з залучанням автоматизаторів через складність підтримки. Бо коли тестів вже багато і змінюється якийсь комон компонент чи модалка, наприклад, то падають одразу багато тестів і у тебе нема одного місця, в якому можна зробити фікс. Треба йти і фіксити кожен тест окремо. І може так статися, що команда планувала на спринт одне, а посередині спринта виявляється, що цей і наступні 2 треба робити тільки фікси. Передказати це дуже важко. То ж для прийняття рішення рухатися з лоу код інструментами, треба дуже багато аналізу і чітке розуміння куди проєкт далі буде рухатися і як він буде розвиватися, що в сучасних умов дуже часто неможливо, так як плани і задачі змінюються на льоту.

@Hennadii Mishchevskyi Не все так катастрофічно погано) Взагалі, це достатньо тривіальна ситуація.
Наприклад в нас є процес створення Persons Account, що складається з двох степів: Address Information та Personal Information. Ми робимо моделі що описують окремі скріни, викликаємо їх та описуємо екшени, з урахуванням вейтерів та можливих умов. Потім ми заключаємо ці тестові степи в реюзабельний компонент з можливістю передавати в нього вхідні параметри (як метод)
Потім в ході розробки продукту у нас додається третій степ : Contact Information, та після нього вискакує модалка. Принцип той же: описуємо потрібні нам кроки та дії, після чого додаємо їх в уже існуючий реюзабельний компонент і все — тести підхватять ці зміни

Не тривіальна ситуація стається при необхідності роботи з даними (мови програмування, все ж таки, в першу чергу і заточені під обробку даних та імплементацію логіки). Чи якщо ми хочемо оперувати більш складними об’єктами, але це теж здебільшого не про UI частину.
Tosca має багато успішних кейсів з SalesForce та SAP, наприклад. Тому що там все стандартизовано з точки зору API, Apex колів та інших способів взаємодії з інтерфейсом бек-енд частини.
В цілому так, потрібен дуже детальний аналіз усіх можливих викликів на проекті, можливо навіть створення прототипу із тестовими флоу. Тому що використовуючи мову програмування завжди можна «викрутитися», а в Tosca все ж таки достатньо багато хардкоду

Ну це вже трохи краще, якщо є можливість умовно описати пейджі, передати їх в шось типу екшинів і використовувати екшини, як параметризовані методи. Але тоді ще одне «але» намальовується ) Хтось має знати, як організувати то все. Останні 5,5 років я працюю тільки з рішеннями, які робив сам з нуля. У мене є певний досвід, як правильно організувати код з точки зору дизайну архітектури. Якщо ми говоримо про мануальників, які без зміни тім композішн будуть навалювати ті тести, то маю сумнів, що вони з першого разу і без досвіду вгадають, як то правильно організувати ) Я вже не кажу про рішення типових проблем саме автотестів, де шось не клікається, шось не вводиться, половина текста губиться, шось треба почекати і т.д. У мене, наприклад, була ситуація, що був data-testid на елементі і ми не могли по ньому клікнути — промахувалися. По координатам теж не допомагало. Допомогло зробити масштаб 80%. Тоді точно в ціль ) Якщо ще зменшити масштаб, тоді промахувалися в іншу сторону ) Рішення — брали координати по Х, з ними проблем не було, потім вісь У і йшли по ній зверху вниз з кроком 0,9 * висоту потрібного елемента поки не натрапимо на потрібний. Я то все до того, що у вас є бекграунд автоматизатора і автоматизатор, якщо дозволяє інструмет, як описано вище, може шось просте зробити в рамках обмежень. Але мануальник — прям дуже сумніваюся. А ще дуже сумніваюся, що багато автоматизаторів захочуть з цим працювати. Бачите отам справа від моєї іконки написано «в пошуках виклику» ) Одного дня фаундер і СЕО прокинувся і вирішив, що нам більше не потрібне мануальне тестування і всі будуть писати лоу код автотести. Я там був куа менеджером. Нам не вистачало 4 мануальники, щоб хоч якось на мінімалках виживати, бо ті хлопці та дівчата робили дуже багато роботи. Було 12 мануальників і 4 автоматизатори. Тепер всі мануальники мають писати лоу-код тести, ті, хто не хочуть — звільнено. Автоматизатори і дивитися в ту сторону не хочуть, що досить очевидно. Проєкт найбільший та найскладніший, який я тільки бачив в житті. Як думаєте, які шанси в команди? Але найголовніше, що мене цікавить, на що спирався фаундер коли приймав таке рішення. У них досі нема ні плана, ні віжина, ні цілі, ні саксес крітеріїв, нічого. Але рішення прийнято. Десь він дізнався про лоу код, хтось же йому сказав, шо воно вирішить всі його проблеми. Як розумієте, мені ця тема наболіла )

Як там кажуть — «No code — No money» *тікає*

Насправді No-code automation інструменти можна розглядати як еволюцію Cucumber фреймворку

Перестав читати

Підписатись на коментарі