Я Олексій Вовк, Senior Test Automation Engineer, працюю в IT вже 10 років, з них останні сім років займався автоматизацією тестування в Sigma Software. За цей час брав участь більш ніж у 20 великих проектах компанії. 

Зараз я викладаю курс з автоматизованного тестування в Sigma Software University. Поєднавши свій практичний досвід із викладацьким, вирішив сформулювати в статті головні принципи, які впливають на вибір мови програмування для автоматизації тестів. 

На мою думку, серед таких принципів можна виокремити три найголовніших:

1. Вартість розробки та підтримки;
2. Доступність бібліотек та фреймворків;
3. Можливість залучення інших членів команди.

Розглянемо кожен із них докладніше. 

Вартість розробки та підтримки

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

Зараз дуже популярна мова Python – вона доволі проста, лаконічна, і не треба писати багато коду. Те, що на Python займатиме один рядок коду, на Java може зайняти 10-15. А написання навіть 3-4 зайвих рядків коду в кожному методі суттєво впливає на витрату ресурсів. Це актуально не лише для довжини коду, а й читабельності. 

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

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

Якщо ж ви ви робите візуальне тестування (наприклад, із порівнянням скріншотів), то вам краще підійде Python, тому що в цій мові є бібліотека Open CV. Насправді, версії для Java і C# теж існують, але саме для Python в ній є багато додаткових функцій та суміжних бібліотек, які надають додаткові методи порівняння. Це дозволяє виходити за межі стандартних методів OpenCV. А от що точно не підійде для візуального тестування, так це PHP. 

На вартість розробки і підтримки автотестів, звісно, впливає і ціна спеціалістів на ринку праці. Спеціалісти на Python трошки дешевші, бо їх просто більше. А якщо у вас щось більш специфічне (наприклад, той же C# менш популярний для написання автотестів), то такі спеціалісти будуть дорожчими. 

Доступність бібліотек та фреймворків

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

Якщо ви робите UI-тестування, то в 90% випадків ви використовуватимете Selenium або Playwright. З Selenium трошки простіше, бо він підтримується майже всіма основними мовами програмування, які використовуються для автоматизації тестування, а от з Playwright трошки складніше. Селеніум під кожну мову має сталий функціонал і він однакових для всіх. А Playwright трошки не так, бо для Javascript- і Typescript-стеку там є додаткові функції, наприклад дебаггер, який може викликати під час тесту дебаг і дивитися … В джаві його не було раніше. Також вебрепорт до останнього працював з javascript/typescript-стеком. 

Отже, ще “на березі” перевіряйте, чи сумісні потрібні вам інструменти з обраною мовою програмування, і чи надає ця мова доступ до всіх функцій базового фреймворка. Це дуже важливо, бо доводилося бачити таке: люди обирали той самий Playwright заради того, щоб не прикручувати Allure і щоб все було з коробки – а в якості мови для автоматизації обрали Java, яка з цим фреймворком не працює. І їм довелося переписувати це все на Javascript. Команда просто змарнувала час і ресурс, хоча хотіла зробити якраз навпаки. 

Також далеко не всі специфічні бібліотеки є “кросмовними”.  Якщо ви проаналізували проект і у вас є якісь задачі, для яких вам не вистачить функціоналу тих самих Selenium і Playwright, і ви знаєте, що вам потрібно налаштовувати додаткові модулі та бібліотеки, ( наприклад, з тим самим порівнянням зображень чи навігації по системі через зображення), то варто ретельно перевіряти потрібні вам бібліотеки на доступність в обраній мові програмування. 

Можливість залучення інших членів команди

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

Якщо ви єдиний автоматизатор на проекті і плануєте робити автотести так, як вам заманеться, то це вирішує проблему (до того моменту, коли ви звільнетесь). Але в моїй практиці було більше випадків, коли я створював фреймворки під ключ, а далі команда проекту рухалася одним із подальших шляхів. Наприклад, залучала 2-3 автоматизаторів або лише одного автоматизатора і в разі необхідності підключали мануальних тестувальників до написання автоматизованих тестів. Отут вже треба добряче подумати над усіма змінними. Фреймворк, можливо, краще було б написати на C#, але от знайти автоматизаторів на C# не так просто, так само як і навчити мануальників розуміти цю мову (вона суттєво складніша за Javascript і Python). Треба тверезо оцінювати наявні ресурси і скілли людей в команді. Правильний вибір мови програмування може зробити дешевшим навчання та підключення додаткових людей до вашої команди для написання тестів. 

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

Case study 

Зараз я готую пропоузал із вибору мови програмування для тестування на одному з проектів. Розкажу, як я це роблю і на що саме звертаю увагу. 

Отже, бекенд проекту пишеться на C#. Весь фронтенд – це Javascript Angular. На проекті є команда з трьох мануальних тестувальників. Двоє з них вже працювали з автоматизацією, один із них працював із Java і Javascript, а зараз ходить на курси по автоматизації на Java. Другий автоматизатор працював із Javascript на Cypress. 

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

Далі – технології. Маємо Angular. Проект передбачає велику кількість UI-тестів, бо це велика legacy-система. Значить, скоріш за все, потрібно буде запускати автотести паралельно. А з паралельним тестуванням трохи краще справляється Playwright, бо він потребує значно меншої кількості налаштувань. До того ж, тести на Playwright відбуваються швидше, тож при паралельному запуску можна зекономити до 20-30% часу. 

Також в Playwright є такі класні дебаг-фічі, як Playwright Inspector. Ми можемо поставити тест на паузу, вискочить віконечко з дебаг, і ми прямо там можемо шукати локатори, дивитися логи, які ми пишемо під час тесту, і так далі. І я розумію, що якщо будуть підключатися мануальники, то ці фічі суттєво спростять їм роботу.

Потім я поспілкувався з командою розробки. Спитав, чи хотіли би вони підключатися до тестування, дивитися, щось писати. Хлопці сказали, що в них просто нема часу, в них самих не вистачає покриття юніт-тестами. 

Я прийшов до висновку, що для автоматизації тестування на проекті пораджу використовувати Playwright у поєднанні з Typescript. Бо Typescript більш схожий на C#, ніж Javascript, і якщо розробники знайдуть час туди заглянути, їм буде простіше розібратися. А мануальники, використовуючи Typescript, зможуть у разі чого наробити менше біди, бо це суворо типізована мова, яка накладатиме на них обмеження. Нарешті, Playright як технологія підійде оптимально, бо дозволяє паралельний запуск і найкраще підтримується Javascript/Typescript. 

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

Ну, і не варто забувати, що Playwright зараз стрімко набирає популярність, так само як Javascript/Typescript в автоматизованому тестуванні. А тому під цю технологію буде не так складно знайти спеціалістів, якщо раптом з’явиться така необхідність. А от якщо обрати C# (на жаль, не настільки популярний для написання автотестів), то заміну спеціалістам буде знайти складніше. 

«Зоопарк технологій»: плюси і мінуси

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

До яких потенційних плюсів може привести робота з декількома мовами і технологіями? За такого сценарію ми можемо обрати спеціалізовані інструменти для різних типів тестування. 

Наприклад, у вас великий проект, де треба протестувати UI, API, а також зробити performance-тестування. Для останнього ви обираєте стандартний Apache JMeter – там у нас Java. Потрібно знати маву, можливо й Javascript, якщо ви пишете код в семплерах. Для UI-тестування ви можете обрати Playwright і Typescript. А для API-тестування – Golang, бо там робиться все просто, лаконічно і швидко. 

Що це може нам дати? Для кожної сфери ви обираєте найефективніші тули. Якість вашого тестування зросте. Але в реальних умовах досягти цього важко – вас швидше за все обмежать використанням однієї мови програмування + якоїсь тули, якщо ви її знаєте (наприклад, пишете UI-тести на Javascript або Typescipt, а на Java будете писати семплери для JMeter.

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