Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!
Чи може хтось з власного досвіду підказати, яку мову програмування для створення авто тестів варто обрати+ можливо хтось може підказати, порекомендувати відповідні курси
обычно выбор определяется выбором framework’а
Питання вибори мови дуже комплексне. Цілком нормально спробувати одну, або іншу мову програмування та свічнутися у процесі вивчення на іншу.
Зараз на ринку праці України домінують: Javascript (Typescript), Python, Java. Є деякі проєкти на C#, ще менше — на чомусь екзотичному, типу Go або Scala. 10 років тому, коли я починав кар’єру, я вчив Java, а на першій роботі писав тести на C# :).
Як обрати мову (короткий гайд для тих, кому важливий час та хто не хоче вчити мову just for fun):
— Хочетe використовувати найновіші інструменти та мати багато варіантів роботи з Web`ом — обирайте JS. Але може бути складно вивчити деякі концепції з нуля.
— Хочете вивчити просту мову, які можна використовувати як для автоматизації, так і для швидких прототипів, скриптів, data science, мережевих штук, хакінгу — обирайте Python.
— Хочете працювати на великих, стабільних, але трохи монструозних проєктах — ваш вибір Java. Інструменти тут стабільні, змін завозять вкрай мало. Вчити може бути складно з початку, але потім звикнете і все буде в порядку.
Поради:
— подивіться на чому пишуть у вас на проєкті (автоматизатори або девелопери). Швидше за все ви будете писати спочатку або UI або API тести.
— якщо є автоматизатори — знайдіть ментора. Якщо є тільки девелопери — все одно знайдіть ментора в команді — який хоча б буде робити вам code review.
— обговоріть з лідом чи менеджером те, як ви будете застосовувати автоматизацію прямо тут та зараз. Може це будуть скрипти генерації даних, прості автотести, тощо. Якщо пройти курси, але не закріпити знання на практиці — сенсу від такого навчання не буде.
P.S. Взагалі не так давно я писав велику статтю на цю тему.
Ну конечно же лучше всего Go, хорошо подходит для написания всяких мелких консольных программ. Есть встроенная возможность для юнит-тестов. К тому же выучить можно быстрее всего.
На тій самій, на якій пишеться все інше
Коли автоматизатор знає мову девелоперів і має доступ до їхнього коду (може глянути зміни у вчорашніх комітах), то іноді це суттєво допомагає в root cause аналізі. Плюс можна налаштувати спільні code inspections, перевикористати DTO-класи та Utils, і т. п. Тому, якщо все одно вчити, логічно обрати те, що використовується на проекті.
А особисто мені подобається Java + Selenide, бо із ним можна будувати гарні ланцюжки команд. Типу BDD, але без Кукумберів (якщо, звісно, акуратно реалізувати поділ по рівнях Page Object / Business Logic / ... / Test).
Беріть Python і не думайте. Автотести на ньому можна написати будь-які, а у порівнянні з якоюсь там Java чи С# код буде у півтора рази коротший. Менше кнопок натискати :)
по-перше то не мова, по-друге краще вже Playwright
По вашому новачок знає що таке тест-раннер? Новачку якраз Cypress і потрібен. Флексібіліті потрібне тільки коли воно потрібне, але точно не на початку навчання.
свого часу я багато писав на Java, але якщо вибирати зараз, тоді точно JS, особливо у звʼязці з Playwright
VisualBasic або Assembler
😨😨😂😂
У хороших командах деви також можуть писати автотести, щоб QA не був ботлнеком якщо команда не встигає, а автотести є частиною definition of done. Якщо автоматизатор 1, то точно потрібна людина яка буде робити код рев’ю, також деви можуть запропонувати імпрувменти у фрейморк. Java Script / type script зараз добре розвивається як інструмент автоматизації і багато девів можуть допомогти якщо треба. Але взагалом краще зробити пару mvp та оцінити що краще підійде саме для вашого проекту, враховуючи чи готова компанія інвестувати у тули і фічі, чи хоче безкоштовну базу для фрейморку.
Девелоперам на таких проектах додатково платять
Ну то ящо ви не бачили команд де автоматизатори допомагають також девам закривати таски, то що ж поробиш.. Це devops culture...
Саме через майндсет шо «то не моя робота» qa потестять й маємо стільки гавняного софта й просрані дедлайни, тому що виходить що, шо перформанс усієї команди залежить від того скільки тасок qa може опрацювати, особливо якщо автотести є частиною DoD( якою вони повинні бути)
стільки гавняного софта й просрані дедлайни
Бо керують цим процесом некомпетентні погонщики і 23 річні сіньйори, які навіть приблизно не розуміють SDLC, компетентні керівники це все передбачують на етапі планування та дають команді час на форс мажори.
де автоматизатори допомагають також девам закривати таски.Це devops culture
Може їм ще допомогти пса вигуляти та машину помити? Це 3.14здабольний менеджмент калче, який наобіцяв на вчора реліз, щоб галера не порушила SLA. Якщо девелопери б покривали свій код різними видами тестів та аналізували різні corner cases, то половину мануальних тостерів треба було викинути на мороз.
перформанс усієї команди залежить від того скільки тасок
запланували та якої вони складності
Це не devops culture, а культура експлуатації. Кривий софт і просрані дедлайни трапляються лише з ефективним українським менеджментом та процесами, де все наобіцяли на вчора, як вам відписали в сусідньому коментарі. Відповідно, все релізиться як-небудь, коли продукт починає неприємно пахнути, плануються мейнтененс релізи, які вже нікому, звісно, не допоможуть і команда починає розсипатись.
Технології динамічно розвиваються, складність та необхідний рівень знань збільшується. Через це і виникають нові ролі на проектах з окремими зарплатами, а не коли розробник це 5в1 за миску рису.
В результаті, відсутність адекватної декомпозиції ролей на проекті це червоний прапорець для будь-якого спеціаліста з рівнем інтелекту вище кімнатної температури.
Додаткове запитання до знавців:
Чи мають бути автотести написані тією ж мовою що і проект?
Типу якщо проект на C# то і тести треба на C# + Selenium (якщо казати про веб)?
Які плюси і мінуси якщо наприклад проект на C#, а тести писати на Java?
жодного разу не було плюсів від того, що мову автоматизації вибирали такою ж, як мова розробки.
Різні кодові бази, різні середовища та запуску.
і часто розробники «щось підхоплюють»? мені дійсно цікаво. Бо в моєму досвіді в них самих дофіга роботи і додатково автотести писати ніхто не хоче. Це ж питання не просто знання мови, а знання фреймворку тестування. Тобто це тільки в теорії звучить класно.
Більш практичний варіант — знайти (чи вже мати) автоматизатора, і дозволити йому робити автотести ефективно. Тією мовою та тим фреймворком, що він добре вміє
Юніт тести — зазвичай так.
Авто тести — ні. Хіба що проект дууже специфічний, і якась проблема з іншими мовами.
Як на мене, тут залежить від того наскільки подобається і лягає сама мова програмування спеціалісту, що буде готувати автотести. Особисто працював із JS Cypress і Python. Залишився на варіанті другому суто через його легкість в порівнянні із js для мене.
Послухаю.
До речі, можливо було б варто уточнити, що саме тестувати — API, UI, etc
Пітон зазвичай — він дуже зручний, простий та лаконічний. Підтримується усіма фреймворками та бібліотеками.
Вивчати можна прямо за офіційним туторіалом docs.python.org/3/tutorial/index.html
підтримую — можна вчитись за офф туторіалом. чи пошукати на youtube курс по пайтону. їх багато, на будь який смак
Alexander Dyachenko
Andrey
Oleksandr Romanov
schwarzlichtbezirk
Roman Pavlyuk
Borys Yevstyhneiev
Andrey
Володимир Корнійчук
Mike
Petro Franko
Dmytro Svyrydenko
Roman Sheremeta
Артур Шев
Ян Сварчевський
Дарина Котеленец
Taras Terletsky
Дарина Котеленец
seal
Alex Radchenko
Михаил Змиев
Oleg
Oleksii Ostapov
anonymous
Denys Poltorak
Oleksii Ostapov
Nazarii Zavada
Andrii Bosonchenko
Denys Poltorak
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів