Пошук по «test automation» нічого особливого не дав:-)

Особливо враховуючи про пошук по матеріалам для автоматизації тестування в межах конкретної сфери/мови програмування

learn-anything.xyz/...​e-testing/test-automation

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

Спецом доречі писав пост так щоб не сильно до чогось опонувати. А просто висловити думку. І зупинитись на цьому. Ти назбирав своїх аргументів на те що потрібен новий термін. Я описав більше коментом «статтю відповідь» що мені здається що ні. Весь мій посил якщо коротко зводиться до того, що все що тобою описано входить в роль тестувальника та його компаньйонів по команді, все це вже давно описано в практиках DevOps і Agile. Про це написані й книжки, це входить в програму як просто навчальних тренінгів так і практичних програм по впровадженню цього на проектах. Це коли приходить досвідчений консультант і допомагає команді побудувати DevOps/Agile не по книжкам, а з точки зору свого досвіду. На проектах з якими я зустрічався і де команди займалась всім описаним у статті вище — проблем з розподіленням ролей, і потреби в новому терміні не було. Все вже описувалась в контексті DevOps/Agile. Але світ динамічний і не однаковий, все в контексті. Судячи з усього у твоєму досвіді певна потреба вирішення якихось проблем через введення нового терміну є :) Ну чи не «проблема» а щось інше, що ти новим терміном хочеш «вирішити». Ну вперед:)

Уточню лиш пару моментів, де судячи з усього сталось непорозуміння.

дякую, кеп! підручники я теж читав. Не зрозумів, до чого саме ця критика. Тому прошу додаткового роз’яснення

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

SDET. Все вже придумали до нас

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

Так що згадувати SDET — тут недоречно.
Ну раз вже про нього згадали. SDET — це термін для девелоперів виділених під задачі технологічної організації автоматизації. Цей термін був введений наскільки я знаю гуглом. По суті це інженери які «пишуть фреймворки», технічно забезпечують команди інструментами для автоматизації. Так ця ідея і дійшла до нас в Європу. І в СНГ. Тут все ще так його і юзають. От тільки в гуглі це не взлетіло, і SDET перетворились на «окремі команди інженерів що пишуть автотести (а не фреймворки) замість девелоперів». Тому зараз дехто вважає цей термін скомпрометованим... Ну це так) Для справки.

P.S.
Олексій, давай на цьому зупинятись. Дискусії тут не потрібно, вже виклали наші карти на стіл. Думаю достаньо)

> Все що описано в статті, як на мою думку вже включено і в наявні на ринку ролі і в практики і шаблони.

Як я вже згадав, це просто моя думка. Ймовірно суб’єктивна. В цілому про те що наявних на ринку термінів/ролей/методологій за адекватного їх розуміння — достатньо для успішного SD. Там де я бачив «не достатньо» — там просто люди не розуміли що таке DevOps і Agile, чи не знали як його правильно впровадити... З іншого боку... Можливо таке «масове непорозуміння» якраз і говорить про те що «наявні на ринку терміни/методології» — недосконалі. І варто вводити/формувати нові методології/терміни. Судячи з мого досвіду — це не так. Проблеми не в наявних методологіях/термінах, а в іншому. Можливо в чомусь ще більш базовому... І можливо в чомусь, де таки і нові терміни знадобляться (більш базові, на мою думку не в дусі TestOps). Але це вже окрема історія. Окреме дослідження. Я б його виходить повів в інший бік. Ти його повів в бік TestOps. Пробуючи замінити те що на мою думку вже описане і так в DevOps/Agile. Ну успіхів) В тому числі і з конференціями які згадуєш в наступному коменті;) Там якраз люблять новімодні терміни і хайпові теми.

Це хороше питання «чи прийшов час ввести новий термін» і «що дасть його введення». Про нього можна поговорити окремо. Але, Олексій, я б тут не відповідав питанням на питання. Це не дослідницький шлях. Ти підімаєш тему про новий термін. Так уже давай, відповідай на критику в деталях:)

DevOPS — це дійсно методологія, навіть «культура». Цей термін з’явився не просто так. А щоб принести щось нове в старе. Він НЕ з’явився щоб дати назву адмінам які почали налаштовувати частину інфраструктури для девів.

Він з’явився тому що раніше стадія продакт лайф сайклу — підтримка/мейнтененс/оперейшенс — жила окремою тусою. По своїм законам.

А потім деякі компанії почали практикувати певні практики — до речі QA практики — практики що не завжди напряму відносяться до тестування (що є QС — контролем якості). Такі практики як gradual roll out, feature toggle та інші які стали дуже важливі для Continuous Delivery i Deployment. Виявилось що для того щоб можна було в будь-який момент тицьнути на кнопку і запустити версію продукту в прод і передати відповідальність команді оперейшенс — потрібно почати слідувати певним практикам на боці розробки, підлаштувати білд систему і пайплайн. По факту поміняти процес розробки — для легшої роботи оперейшенс. А оперейшенсам підлаштувати свій бік, щоб зрозуміти як жити з цим усім новим, як швидко по гарячому робити в проді ролбеки, як вимикати по гарячому фічі, в яких виявились баги. Як моніторити. Виявилось що взаємодія між командою розробки та командою оперейшенс стала ще більш важливою, назбирались шаблони й кращі практики в цьому контексті. Так і виникла саме методологія нова і дали їй назву DevOps.

А от навіщо вводити TestOps поки не зовсім ясно...

Ще раз, у слові DevOps — dev — це команда розробки, а не програмісти. Вже давно у світі еджайлу — тестери є частиною команди розробки. Скрізь де по серйозному впроваджують девопс — дуже близько говорять про автоматизацію, про тестування, про роботу з вимогами. Це комплексний підхід. В DevOPS вже і доволі давно входить набір практик і шаблонів, які вже включають і тестерів, і бізнес-аналітиків/продакт-овнерів, і девів. Нічого не змінилось, це все передбачено, і описано.

Навіщо ж тоді вводити новий термін TestOps?

Хоча стоп... мабуть, таки треба... Заради консистентності...
Ну чо... Як у нас завжди буває...

Прийшов Agile, почав говорити про відповідальність за якість всією командою, про QA практики ... Ніхто цього не зрозумів, нічого не змінилось. Але наших тестерів які й далі продовжували займатись суто QC — почали тепер називати QA Engineer.

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

То може так само давайте і новий термін введемо для тестеро-автоматизаторів-адмінів? А може ще давайте девелоперів які, обоги, поки ніхто не чує — «пишуть авто тести» — почнему називати TestDev-ами? хм... чи може краще DevTest-ами? як краще звучить? :)

Те що науково технічний прогрес росте, і інструменти стали потужніші, але й складніші, і тепер оперейшенсам чи адмінам — треба трохи більш впахувати — хіба заслуговує на нову назву? Може давайте роботу робити, а не вигадувати 100500 термінів, яку більшість все одно не розуміє і перекручує як з тим же DevOps. Як з QA:)

А то у нас люблять на себе погонів навішати. Ні, не тестер який задумується над більш ефективним виконанням своєї роботи через автоматизацію своїх рутинних дій. А — QA Automation, йоу. Написав фреймворк (в той час коли можна додати задачу в беклог, добре подумати над вимогами, дизайном — і потім деви це втричі швидше зроблять) — о, тепер я SDET. І так пішло поїхало.

Що, багато задач по адмініструванню інструментів? — виділіть роль адміна, який це все буде сапортити.

Треба «контролювати якість? — тобто по факту коли щось зроблене, перевірити чи воно відповідає поставленим наперед вимогам (верифікація) чи адекватним потребам його користувачів (валідація)» — і не важливо де це робиться, на якій стадії. Для цього вже давно є термін — QC, Testing. У всіх класичних підручниках написано, що тестування застосовується до всіх стадій починаючи з формування вимог.

От в тому ж еджайлі є така хороша QA-практика (практика що в профілактичному стилі забезпечує якість наперед, а не контролює те що вже нафакапили) — 3 Amigos Meeting — це коли на грумінгу чи пре-пленінгу — збираються і деви і тестери і продакт овнер чи БА — і все разом обговорюють вимоги, прояснюють їй. В деяких командах — коли багато такої роботи, ПО — працює на більш високому рівні в плані формування бізнес-вимог, а деви разом з тестерами вже розбивають їх на аксептенс критерії. Не виділяють же після цього нову роль BaTestDev :)

Хто зна, може і є сенс в нових ролях... Нових термінах. От лиш мені здається, що нам би розібратись з тими термінами що вже є:) Навчитись всім гуртом відповідати за якість. Думати перед тим як починати щось робити, а не після. Зробивши — поглянути на результат, перед тим як передавати іншим в роботу далі — о так, не тільки тестери в команді мають «перевірками займатись». Взявши впроваджувати певну методологію типу DevOps — розібратись в деталях що воно таке в повному обсязі, комплексно. Там ще дуже багато цікавого чого. Якщо робити все як задумано адаптуючись до контексту звісно, то і навряд будуть з’являтись нові «качконоси». Хех, та ні, звісно будуть. Але вони й так завжди з’являються тому що не існує чогось один в один схожого на те що описується в книжках. Я більше про те — що в кожній команді будуть якісь свої версії універсальних солдатів і спец-ролей. Але навряд всіх вийде під одну планку підрівняти.

На мою думку, зараз же з’являється «нова планка» більше через те що народ масово не розуміє ні що таке QA ні що таке Agile ні що таке DevOps. А ще не має досвіду як це все впроваджувати. І виникають тренди масового однакового непорозуміння) На таке меми треба нові вводити, а не терміни/ролі.

Можливо вжити слово «Єдина» було і недоречно. А можливо й добре — аби привернути більше уваги :)

А от подібного роду реагування на всі фрази зі словами «єдина» не є «єдиним рефлексом реакції», від якого пахне «шаблонним мисленням»?

Олексій, якщо просто потролити, то гарно виходить, доволі не замасковано:) Явно і помітно. +1

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

Поки мені й не ясно на що відповідати. Що ускладнює трохи процес)

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

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

Монополізація? Хм, мабуть, хочеться... монополізувати ту нішу яку зараз займає більшість навчальних закладів, надаючи або дуже дорогі курси, які мало чому корисному вчать (це видно по загальному рівню більшості наших інженерів). Або безкоштовні, але не дуже якісні. Або якісні, але не доступні потрібною мовою — не тільки мовою нації, але й «мовою аудиторії» — не завжди якісні матеріали можуть бути сприйняті усіма. При цьому під монополією зазвичай розуміється «витіснення конкурентів». З приводу останнього — можна дуже просто прояснити питання уважно прочитавши передостанній абзац статті, і хоча б по моєму сайті поблукати трохи. Підхід який я використовую базується на інтенсивному використанні тих матеріалів і інструментів що вже є на ринку. Я постійно посилаюсь і раджу інші навчальні платформи. І стараюсь не готувати матеріали на теми, які вважаю дуже добре розкриті в інших місцях. В більшості випадків можна помітити прям принциповий мій підхід в цьому питанні. Що, мабуть, і теж не дуже добре є. Що занадто то не здраво.

Зрештою я згоден, що від слова «Єдина» трохи пахне... Ну як вже є, мене самого муляло коли нашвидку вигадував заголовок. Але знову ж... Ми ж не собаки павлова щоб діяти з точки зору інстинктивних рефлексів і намуляних мозолів. Дорослі люди ж. Інженери і дослідники в кінці кінців.

Год назад был детальный разбор по теме: seleniumcamp.com/...​ess-vs-selenium-wrappers
;)

„Плагиатю” Дмитрия:)
youtu.be/GEcpbOaS6Bw
www.slideshare.net/...​h-bdd-automation-engineer

типа "трушным:-)
lurkmore.to/Православно

Почитай вот это: dou.ua/…​mns/epistle-to-switchers ;)

И найди знакомого айтишника, только хорошого, именно програмиста, — что-бы тебя оттестировал, и дал фидбек, получится из тебя кодер и как быстро. Поспрашивай знакомых, у кого то из друзей полюбому должен найтись добрый человек.

Я сам не один раз так людям помогал.
Вдруг что — напиши в ФБ — ищу хорошего программиста среди знакомых, который за пиво меня протестит...

Если не найдешь знакомых — помучай себя на exercism.io
Если задачки такого типа будут тяжело идти — значит возможно ответ «нет» или «не скоро».

Если получишь ответ — «да». Тогда просто начинай пахать. 8 месяцев — хватит с головой.
На другой язык врядли стоит переключаться. Добей джаву. У нее есть достаточно плюсов. И доля на рынке, достаточное количество учебных материвалов. Тех же аналогов javarush для других языков — не так много.

Поставь себе цель — за 8 месяцев создать реальное приложение. Придумай идею — или возьми любую уже готовую... Погугли — на форумах люди делятся... Бродят даже списки в эксель шитах — разных социально важных идей для стартапов. Походи по хакатонам — там часто что то начинают а потом забрасывают... Возможно тебе нравиться какой то сервис, но чего то в нем не хватает тебе — создай свой альтернативный:) Или найди уже какой то оупенсорс проект — и начинай контрибьютить в него, начиная с простых задач. И вперед колбасить.

Залезай в какие то чаты, типа таких: github.com/dou-ua/general

Спрашивай советов, с направлением, что где найти... Какой инструмент выбрать для реализации приложения.

Возможно найди хорошие курсы. Но не сразу. А только после того как все бесплатные доступные перепробуешь:) типа каких то на edx.org и coursera.org
Лучше уже идти на курсы с багажом... Так более эффективно сможешь выбивать инфу с преподов. Да и проще сможешь определить где толковые ребята а где развод.

если чувствуете что не понятенете — то НАФИГАЙТИ.

Кто не тянет и йдет в кюей — это мазохисты которым нравится быть слабым звеном в команде, работать за намного меньшие деньги, не потому что кюей, а потому что дуб, и никто таким не поднимает ЗП, и получать при этом смешки за спину от программистов.

Идти в кюей стоит только:
— если действительно нравиться быть именно QA
— если не хватает времени доучиться на кодера, а работа нужна позарез

Спочатку визначись — твоє чи ні.
Не треба братись за високі матерії — типу сайтів чи ще чогось такого. Спробуй розібратись з самою базою на ресурсах типу:

— javarush.ru, learnjavaonline.org
— www.learn-js.org, www.learnpython.org
— чи будь-які безкоштовні курси на всяких coursera.org, edx.org

, і повирішувати практичні задачки на сайтах типу:
— exercism.io
— www.codewars.com
— checkio.org
або щось повеселіше:
— codinggame.com
або щось попростіше пошукай, типу зовсім ігрові платформи:)

Якщо це все піде — то тоді можна задумуватись і про веб-розробку чи ще там про що...

Якщо не піде — то скоріше за все як мінімум «зараз — воно не твое»...

А от чи є сенс «зробити» його твоїм... Це вже інше питання... І інше питання як цього досягти...

начни учиться сам, а потом видно будет:)
Не думай что курсы сразу насыпят манны с небес :)
Экономь свое время — используй его более эффективно. Попробуй выучить по максимуму сам — а потом уже искать «учителей»... Уже что то зная — ты сможешь их использовать как учителей более эффективно. Плюс сможешь уже и сам выбрать их более осознанно.

Джавараш норм вариант для старта. Там 10 занятий должны быть бесплатными. Начни с него. А там видно будет. Будет сильно нудно — переключайся на learnjavaonline.org + exercism.io
накачаешься на них — и если все еще будешь спешить — поищешь какие то уже продвинутые курсы по джава разработке в той сфере которая тебе будет интересна.
А не будешь спешить — сам в инете найдешь материалы. Чаты/форумы — помогут;)

Прочти этот отзыв: automated-testing.info/…​ostoyannyj/9339/41?u=ayia

И подпишись на нашу страничку в фб:
www.facebook.com/automician

мы как раз переводим наш курс на питон. Где то к середине лета будет. А может и раньше.

Если просто не хватает знаний — то тогда проси помощи в чатах... например тут: software-testers.herokuapp.com
Если будешь по делу спрашивать — ответят. Там куча крутых инженеров сидит, которые с чем только не сталкивались.

Если же проблемы с базовыми вещами... Не умением находить решение, когда оно «под носом»...
То начинай с базы... Только не той что тебя на курсах учили а базы «быть хорошим инженером который умеет решать проблемы». Можешь потренироваться «решать проблемы» вот здесь: exercism.io
решай задачки, и когда начинаются проблемы — гугли и проси помощи в их gitter чате

еще один способ тренироваться «решать проблемы» — попробуй поставить линукс какой то типа gentoo или arch linux — ту версию которая с нуля ставится :)
набьешь кучу шишек, нагуглишься — так и научишься;)

Ментор тебя гуглить не научит :) Ну... поможет... Но такая возня для тебя обойдется слишком дорого :)

начни с
javarush.ru
потом подключай exercism.io
а там видно будет;)

и да, цитирую себя же:

если проблемы с английским — то с него и стоит начинать.
если проблемы с онлайн-обучением — то пора «просыпаться», в нашем мире каждый разработчик только этим и занимается каждый день — ищет решения проблем и дополнительные знания в интернете. Так что чем раньше начнешь учиться «учиться онлайн» тем лучше ;)

Ни о каких курсах с действительно «православным» обучением кроме: devclub.com не слышал :)

А так то, вот лучшие «курсы» по джаве и притом беслпатно:
javarush.ru (бесплатны первые 10 уроков)
learnjavaonline.org
exercism.io
;)

если проблемы с английским — то с него и стоит начинать.
если проблемы с онлайн-обучением — то пора «просыпаться», в нашем мире каждый разработчик только этим и занимается каждый день — ищет решения проблем и дополнительные знания в интернете. Так что чем раньше начнешь учиться «учиться онлайн» тем лучше ;)

пускай занимается тем что ему нравится, и только если его предпочтения как то пересекаются с программированием — тогда есть смысл его учить...

Например.

Любит делать что то руками? — купите ему какого то робота программируемого.

Любит шпилить в игры? — пускай попробует написать свою :) Для начала пусть загуглит «Как написать свою первую самою простую игру».

Еще мелкий но уже андроид/айос-гик? — Пускай попробует написать свое мобильное приложение... И так далее..

При этом зачем идти на курсы? Пусть учится всему сам. Будущее — за самообучением и умением выживать в мире интернет технологий. И так уже полно бесплатных онлайн курсов и материалов — главное уметь их находить. Нужны менторы? — есть полно форумов и чатов тематических. Это у взрослых нет времени на весь этот «фан» — и они хотят чтобы их побыстрее на курсах научили да еще и палкой вбили знания в голову... Правда иногда уже вбивать не куда... Нет там места, ибо оно забито чем то другим :) И освободить это место для новых знаний очень тяжело :) А ребенку что? — спешить не куда :) На работу он сейчас все равно вряд ли пойдет :)

Платите лучше уж репетиторам по математике и английскому языку. Первое даст нужное строение ума и возможность очень быстро выучить программирование когда понадобиться (если математику не забудет к тому времени). А второе даст доступ к куче бесплатных онлайн материалов по обучению.

конструктивно отвечали тут radio-qa.com/035-testing-javascript