Хто ти — Automation Engineer чи SDET? І чи справді автоматизатори більше не потрібні

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

Всім привіт і Слава Україні! Я SDET lead в продуктовій компанії Corva. Працював у великих аутсорсах, аутстафах і трохи в консалтингу, отже бачив різні команди і різні підходи щодо автоматизації тестування. Відтак у мене сформувалося своє бачення цих посад, щодо яких я і пропоную подискутувати.

Disclaimer: моє бачення — то є моє бачення, яке не претендує на істину в останній інстанції, але заохочує на диспут, адже тільки так можна докопатися до тієї самої істини. Також мої висновки базуються на моєму досвіді та досвіді моїх знайомих, тож конкретно твоя думка, друже, може кардинально відрізнятися від моєї, і це нормально :)

Хто такий автоматизатор тестування в принципі зрозуміло, а ось що то таке SDET — вже не зовсім. Принаймні тому, що, погугливши саме англомовні джерела, я знайшов багато різних трактувань і всі вони були досить різними. І, так, моя думка, що автоматизатори не потрібні. Але «не всьо так однозначно». Тому почекайте кидати помідори і давайте розбиратися.

Test Automation Engineer

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

Але тут важливий досвід саме UI автоматизації і способи розв’язання типових проблем, на кшталт правильно дочекатися елемента чи ввести текст так, щоб не зникали літери. Звичайно, треба ще побудувати automation solution.

Найімовірніше там будуть page objects в якомусь вигляді і, можливо, на цьому все. Дуже просте рішення з купою наслідування, яке на дистанції призводить до того, що щось зробити неможливо, або дуже довго через обмеження дизайну рішення, крім того, щось постійно не працює і зелені джоби — то свято. Фіксиш в одному місці — падає в іншому. У кого ніколи не було такого досвіду — поділіться своєю історією :)

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

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

Мій перший проєкт з автоматизації починався приблизно так само, і навіть люди, яких брали потім, не мали серйозного досвіду з JS (на якому був написаний проєкт). Тоді тільки з’явився ES6 і я пам’ятаю натхненні розмови типу «я знаю різницю між map та forEach!». То були цікаві часи :) Поділіться своїм першим досвідом в автоматизації, дуже цікаво!

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

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

Software Development Engineer in Test (SDET)

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

З назви посади зрозуміло, що навички такого спеціаліста мають починатися в першу чергу саме в програмуванні і спрямовані на автоматичні тести. Це означає, що спеціаліст може сам визначити, до якого рівня піраміди тестування відноситься тест і сам його імплементувати, лишаючи UI рівню мінімальну кількість end-to-end flow.

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

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

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

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

А тепер перейдемо до складніших речей, а саме дизайн-архітектури automation solution. Чим він простіший (тільки page objects на наслідуванні) тим, на жаль, менше можливостей і більша складність у підтримці. А задля того, щоб зробити гнучку систему, яку буде легко підтримувати та розширювати, треба мати добрі навички в програмуванні. Ну, і позаяк SDET — це повноцінний розробник, то він має вирішувати будь-які задачі, пов’язані з тестуванням без обмежень.

Необхідні навички: знання та досвід мануального тестування, знання і розуміння мови програмування на рівні «девелопери звертаються по допомогу», знання і вміння правильно застосувати патерни програмування, вміння писати код так, щоб його розуміли джуни, досвід автоматизації тестування, розуміння front-end/back-end технологій на рівні «можу писати юніт тести та фіксити баги».

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

Підсумки

  1. Задача автоматизатора — написати якомога більше автотестів, тоді як задача SDET — написати якомога менше тестів, але так, щоб вони принесли якнайбільше користі.
  2. Одного разу на співбесіді кандидат на позицію senior сказав, що якби він знав відповіді на мої питання, то був би розробником.
  3. Наразі на українському ринку для SDET роботи менше, бо і коштує такий спеціаліст більше і, знов-таки, багато кому треба просто накидувати тестів.
  4. І відповідь на головне питання: навряд чи професія автоматизатора колись зникне, але частка SDET буде поступово зростати. В Україні це зростання може бути трохи швидшим за умови вектора розвитку ринку в продукт.

Порівняльна таблиця

Навички

Automation Engineer

SDET

Мануальне тестування

+

+

Програмування

Базовий/ середній рівень

Просунутий рівень

Фреймворки для авто тестів

+

Не обов’язково

Досвід UI автоматизації

+

+

front-end/back-end технології

-

+

На додачу

Мене часто запитують про кількість тестів і мені цікаво, що дає ця метрика. Бо можна написати один е2е тест, який розріже весь додаток і буде мати велике value, а можна наплодити 100500 тестів, які будуть перевіряти, що елементи є на сторінці, або щось типу того.

Які метрики ви збираєте і вважаєте доцільними? Прошу у коментарі :)

Ще чув, що є окремі позиції TestOps. Хто на такій працює, розкажіть про себе :)

Дякую, що дочитали, все буде Україна!

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось17
До обраногоВ обраному3
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
знання і розуміння мови програмування на рівні «девелопери звертаються по допомогу»

Иметь такие знания это конечно круто для профессионала, но если СДЕТ знает язык лучше девов на проекте, то это звоночек что у проекта большие проблемы. Либо у кого-то большая звезда во лбу))))

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

а як щодо SDET і перевірки серверсайду?

Обов’язково, але то простіша історія, тому в статті упущена.

щодо кількості тестів, то є цікавіша метрика — покриття функціоналу

Ось чогось це мене не питають, а от кількість тестів та. Але в покритті мене також цікавить якими саме тестами воно покрите.

Сподіваюсь, автор читав «Як тестують в Гугл». Уітакер наче добре розкрив цю тему і як по факту зароджувався SDET

Те що описано в статті це зазвичай сінйор автоматизатор. Просто накидувати тести і джун справиться.
В мене коли була позиція чисто СДЕТ, то помимо написати тест, було і розширити спочатку рест сервіс новим ендпоінтом, який мав би робити задану задачу, при чому сервіс той був до мамонтоподібного
Десктоп-сервер продукту з декількома базами даних і кучою обрахунків. Тобто перед тим як написати ендпоінт потрібно в продукті ще передбачити взаємодію з рест сервісом і обмін даними.
Тобто виходить, що є запит на автоматизацію певного функціоналу продукту, автоматизація через рест апі. спочатку пишеш код продукту, щоб його автоматизувати, потім сам тест. Вроді і дев, а вроді і тестер

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

Задача автоматизатора — написати якомога більше автотестів, тоді як задача SDET — написати якомога менше тестів, але так, щоб вони принесли якнайбільше користі.

Це в аутсорсі так працює, щоб побільше людино-годин продати? Що автоматизатори, що STED, що деви мають писати прості та лаконічні тести, достатньо включити здорове мислення, а не гнатись за кількістю і додавати туди якусь мега-складну логіку, це ж internal річ для команди щоб релізити швидше. Зустрічав з досвіду, що навіть досвідчені тестери писали ті самі тести, що девелопери, просто іншою мовою, бо в багатьох командах є величезний розрив між дев і тест командами. Якщо б більшість девів писали достатньо якісних тестів ще на етапі написання самого коду (по-модному TDD), то потреба у такій кількості тестувальників відпала, мануальних так точно.

дякую за статтю, але дуже дуже дуже багато пунктів холіварні.
особливо вислови — сдет це єволюція автотестувальника. і далі шось по типу «сдет це майже розробник» тоді по логіці виходить шо єволюція сдета це повноцінний розробник ? )))) але це ж не так))

SDET має вміти самостійно пофіксити баг у додатку,

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

Задача класичного автоматизатора тестування в Україні — це покриття мануальних тест-кейсів автоматичними тестами

 — якшо у вас так то, вибачте, це діч повна. класичне мислення джуна яки тіки навчися писати файндбай і йде в автоматизацію.

Чим він простіший (тільки page objects на наслідуванні) тим, на жаль, менше можливостей і більша складність у підтримці.

— ага і потім на таких проектах виходить шо такі автоматизатори роблять офігенно гнучкий фреймворк , пилять його пів року а тестів у нього НОЛЬ. бо ну ми ж пилили КОР ФРЕЙМВОРК!!!111 шоб гнучкий і тд. і клиент тупо релізить такую команду бо з нею профіта нема. задача автоматизації — найменшими зусяллями зробити найбільший кавередж. усьо. шо занадто то не здраво. тести повинні перш за все велью приносити а не буди мегагнучкими.

ну і наостанньок —

Мене часто запитують про кількість тестів і мені цікаво, що дає ця метрика. Бо можна написати один е2е тест, який розріже весь додаток і буде мати велике value, а можна наплодити 100500 тестів, які будуть перевіряти, що елементи є на сторінці, або щось типу того.

— якшо у вас тест який перевіряе весь додаток один то вам також треба міняти стратегію тестування )))

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

в нас шо сдет шо автомейшн однакові — набір скілів трішки відрізняється додатковими ачівками, проте ЦІЛЬ у них однакова (і це не написання якомога більше або якомога менше тестів). це створення солюшену для максимального кавереджу з мінімальними ефортами.
дякую :)

багато пунктів холіварні

такий був задум ) Це ж не точна наука, мені було цікаво почути, що там у інших і інші точки зору.

єволюція сдета це повноцінний розробник ?

Якщо мені тут стане скучно, то куди ж мені ще йти, якщо не менеджмент?

а нащо тоді розробники?

а хто ж буде ті баги робити ) Знову ж таки, я не кажу за всі баги.

— якшо у вас так то, вибачте, це діч повна. класичне мислення джуна яки тіки навчися писати файндбай і йде в автоматизацію.

зараз у мене не так, але я був на таких проектах. Ви ніколи не зустрічали такий? Їх повно і керують ними далеко не завжди джуни.

— ага і потім на таких проектах виходить шо такі автоматизатори роблять офігенно гнучкий фреймворк , пилять його пів року а тестів у нього НОЛЬ. бо ну ми ж пилили КОР ФРЕЙМВОРК!!!111 шоб гнучкий і тд. і клиент тупо релізить такую команду бо з нею профіта нема. задача автоматизації — найменшими зусяллями зробити найбільший кавередж. усьо. шо занадто то не здраво. тести повинні перш за все велью приносити а не буди мегагнучкими.

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

— якшо у вас тест який перевіряе весь додаток один то вам також треба міняти стратегію тестування )))

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

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

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

максимального кавереджу

тут ви маєте на увазі виключно UI тестами кавередж?
будь ласка, навзаєм :)

Цікаві думки. Поки читав, прям бачив як міняються тези. Думка, що автоматизатори не потрібні була озвучена, але не підтверджена тезами та фактами і не запропонована альтернатива. Чомусь автоматизаторів звели лише до Web UI, чого б це. Досить контроверсійно виглядає теза, що автоматизатори намагаються створити якого більше тестів. Якомога більше тестів, це взагалі ніколи не було задачею в тестуванні. Навіть навпаки, ідеальний сферичний тестувальник робить якомога менше тестів, але при цьому, заявляє про відповідність продукту заявленим вимогам.
Цікаво, що в коментах ви доповнюєте свою думку, або навіть знімаєте якісь холіварні моменти, але чому їх одразу було не написати у статті?

І заголовок і холіварні моменти були задля втягнення читачів у бесіду. Бо коменти типу «все гівно, аффтор ні о чьом» — то не цікаво. Цікаво, коли у людини інший досвід, інший шлях і вона ділиться своїм досвідом.

Реально назва тайта не має ніякої різниці

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

Крипта жеж

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

Что только не придумают что бы повесить больше обязаностей на человека )

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

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

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

Т.е как я понял СДЕТ фиксит только простые баги? Что если пофиксил а отвалилось в другом месте? Что если начал фиксить а проблема оказалась глубже чем ожидалось? Что если из-за не знаний особенности языка напилишь какой-то говнокод за который девелоперы проклянут?

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

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

Якщо ’бага блочить тест’, то хіба це не має бути щось серйозне, що кладе апп намертво, або видає якийсь 404 і т.д. еррор., коли дійсно продовжувати роботу над тестом неможливо?
Інакше, якщо ’проблема проста’ і наприклад не відпрацьовує якась кнопка або не видаються дані, то ’увидел багу — завел дефект — продолжаешь работать’ з тимчасовим пропуском проблемної частини або хардкодом даних вручну + TODO ’змінити коли дев пофіксить баг’ виглядає кращим варіантом, ніж лізти до чужого і фіксати самому.
В нас наприклад флов, що failed результат правильно написаного скрипта через помилку в коді програми ніяк не блочить написання власне самого скрипта — дефект репортиться, скрипт мерджиться в головну бренчу і додається в джобу, а щоб він перестав фейлитись — то вже обов’язки девелопера, який має пофіксити баг, але не автора скрипта.
Також питання — як саме швидше це все відбувається?Бо на всіх серйозних проектах, де я був, флоу всюди +/- однаковий — заводять дефект, який падає в беклог, потім з нього додають його в якийсь спринт, на це робиться окремий бренч з окремим багфікс ПРом в feature чи develop. То все займає часу звісно, але швидше це хіба не трекати нічого ніде і/або фігачити комміти напряму без ПРів, без жодного рев’ю — не дуже вдала практика, з потенційними проблемами на виході

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

Не обов’язково. Одного разу мені заважало неправильне сортування елементів. Фікс DESC -> ASC. А був і краш, який взагалі пофіксився додаванням лише одного символу.

продолжаешь работать’ з тимчасовим пропуском проблемної частини або хардкодом даних вручну + TODO

Мені подобається підхід Боба Мартіна — todo можуть бути лише в коді в in progress і в головну гілку не йдуть.

лізти до чужого і фіксати самому.

Знову ж таки не бачу в цьому проблеми. Не можна ж завжди працювати виключно зі своїм кодом. Одного разу у мене взагалі була задача бігати по різним командам і фіксити їх проблеми в коді. Очевидно, що то був не мій код. А, якщо ти приходиш на проект, на якому був 1 автоматизатор і він звільнився, то весь код не твій. То що робити?

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

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

швидше це хіба не трекати нічого ніде і/або фігачити комміти напряму без ПРів, без жодного рев’ю — не дуже вдала практика, з потенційними проблемами на виході

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

Не обов’язково. Одного разу мені заважало неправильне сортування елементів. Фікс DESC -> ASC. А був і краш, який взагалі пофіксився додаванням лише одного символу.

може бути і таке, але знову ж таки — чому б в такому випадку не написати деву з проханням пофіксити проблеми, а лізти в чужий репо в чужий код самому?

Мені подобається підхід Боба Мартіна — todo можуть бути лише в коді в in progress і в головну гілку не йдуть.

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

А, якщо ти приходиш на проект, на якому був 1 автоматизатор і він звільнився, то весь код не твій. То що робити?

Тоді на тебе падає не тільки код, але і відкриті і майбутні відкриті фічі, таски і баги, які не встиг закінчити попередник, в такому випадку передача комплексного овнершіпу ’всього’ між dev-dev, qa-qa — в цьому нема проблеми. Але це і інше, ніж коли qa залазить в код до актуального дева, який активно над ним працює.

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

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

Для девелопера це, так, беклог, грумінг, планінг, спрінт, фікс.

Для вас ні, ви поза спринтами? чи в вас він динамічний і створюється на ходу?

Я ж роблю в рамках своєї задачі тут і зараз. З фіча бранчою, динамічним енвом для теста, ПР-ом і всім, чим треба.

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

може бути і таке, але знову ж таки — чому б в такому випадку не написати деву з проханням пофіксити проблеми, а лізти в чужий репо в чужий код самому?

Бо це може бути на 2 дні — 2 місяці довше ніж я це зроблю сам за 5 хвилин. Ну і нема такого, як чужа репа/чужий код. Хто сказав, що для дева, який мав би це фіксити, цей код не буде «чужим»? Ми всі працюємо над спільною ціллю і це є наш продукт.

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

2 місяці гілка буде лежати на ремоуті з тою тудушкою, а потім 100500 конфліктів. Нащо воно таке треба? Краще тоді вже залити в головну, вимкнути недороблений тест і зробити таску, прилінкувати до баги.

Для вас ні, ви поза спринтами? чи в вас він динамічний і створюється на ходу?

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

З таким підходом ясне діло, що на рев’ю часу не стане, взагалі ні на що не стане, якщо робити чужу роботу замість когось

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

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

Одного разу на співбесіді кандидат на позицію senior сказав, що якби він знав відповіді на мої питання, то був би розробником

Цікаво дізнатись що то були за питання?

1. Усі методи классу Object (напам’ять)
2. Крутити графи та дерева на шматочку паперу (та інші leetcode запитання)
3. Як працює Хешмапа
ще багато чого дивного запитують....

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

Проходжуся по солід, прошу навести приклади, питаю які патерни застосовував і для яких проблем, архітектуру рішення на останньому проекті, тощо. З більш низькорівневих речей по js мені подобається питання які аргументи приймає колбек мапа і з нього витікає чи можна змінити оригінальний масив, змінивши третій аргумент того колбеку. Приводжу невеликий приклад коду з різним використанням this і дивлюсь, як людина орієнтується в контекстах. Може бути щось інше. Мене на поточній проект співбесідував девелопер. Просив вирішити задачу: є функція типу sum(1, 2) == 3; її треба карирувати тільки так, щоб кількість аргументів могла бути будь-якою. Тобто функція завжди має повертати функцію. Але при порівнянні має повертати суму: sum(1)(2)(3) == 6; // true Але то вже занадто )
Але то все для синіорів. Джунів питаю по досвіду і прошу вирішити маленькі задачка (не на листочку:) ) Там мені головне — базове розуміння і бажання вчитися.

Ммм...сидит такой на работе автоматизатор и думает — " эх а давай я залеплю такую структуру данных что бы хрен пойми где какой контекст был и добавлю возможность бесконечного карирования, вот же офигенно будет!"

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

Мне кажется что такие вопросы задают люди которые код пишут ради кода. Я не представляю как можно накосячить с контекстами если не упарываться в какие-то сложные структуры.

Поки не упорююшся у важкі речі можна і не вивчати, якщо воно не цікаво. То ж така справа.

Тогда зачем использовать какие-то оверкил конструкции (тем более в автотестах) в которых так сразу и не разберешься? Я так понимаю KISS вы не любите?)

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

хто ти — есдет чи ейкюей ?

каже шо сдет а виходить еникейшик :D ru.wiktionary.org/wiki/эникейщик

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

Багато в чому з Вами не згоден. Дозвольте пояснити чому.

1. Задача автоматизатора не обмежена тільки UI рівнем. Доволі часто автоматизуються API рівень. До того ж це може бути як високорівневі бібліотеки, так і щось максимально наближене до конкретної технології (наприклад мобільна автоматизація).

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

3. SDET — то більше про великий продукт. У аутсорс компаніях SDET тайтли придумали, щоб зробити додатковий ступінь у розвитку інженера (та довше його тримати у компанії). Але знаю багато проєктів, де люди з тайтлом SDET займається тією ж автоматизацію, як і інші. АЛЕ Ж ТАЙТЛ!!!

4. SDET або SET — це інженер, який розуміється на тестуванні більше ніж пересічний девелопер. Головна задача SDET не допомогти автоматизувати тести, а зробити процес тестування швидшим та легшим для ВСІХ учасників процесу розробки. Це можуть бути покращення testability продукту, написання інструментів та скриптів для девелоперів, покращення пайплайнів, написання інструментів для тестувальників. У команді, де є нормальні тест інженери, один SDET пише фреймворк, а потім інші тест інженери, разом з тестуванням, покривають функціональність автоматизованими тестами.

5. З попереднього пункту випливає те, що у продукті виділяти окрему команду автоматизації дуже незручно. Краще навчити автоматизувати тестувальників (та дати їм час на написання та фікс тестів). SDET в такому випадку відповідає за інструментарій.

6. Я розумію навіщо у Гуглі співбесіда на SDETa = 80-90% співбесіді на розробника. Бо там наймають інженерів, которі доволі легко переходять з позиції на позицію, з технології на іншу. Але у реаліях аутсорс-аутстафф айті — чекати від SDET такого ж набору знань, як від девелопера — доволі нерозумно. Він краще піде у розробку (беручі до уваги практично повністю відсутню культуру SDET інженерів у наших компаніях).

7. SDET що фіксить баги — звучить начебто як «SDET то недорозробник, якому будемо давати усю чорну роботу». Нащо туди пхатись? Чому тоді думати, що це — «вершина» еволюції тестувальника?)

8. Написання автоматизації недосвідченими інженерами — так, це є проблемою. Яку потрібно вирішувати.

У будь-якому випадку, SDET — це інженер-розробник, який допомагає розв’язувати проблеми бізнесу. Як? Робити процес тестування легшим, швидшим, стабільнішим.

Лайк на першому рядку )
1. Згоден. Апі я навмисно упустив, бо це більш проста, і від того менш показова, історія.
2. Насправді, це основна причина підняття цієї теми. Мені особисто дуже хотілося б, щоб інженери на таких проектах задумалися, чи можуть вони робити щось краще. Я таким був — накидував тести, бо були неавтоматизовані тест кейси. Розуміння, що так робити неправильно прийшло не одразу.
3. Так і є. Мені б дуже хотілося б, щоб ми колись доросли до правильного використання тайтлів, а не «дамо йому ту личку, щоб був задоволений». У мене була личка sdet коли я робив перші кроки в автоматизації просто тому що всіх на проекті так називали. Чому? Мабуть менеджмет вирішив, що так крутіше.
4. Не можу не погодитися. Єдине, тут конкретно про мене і мій поточний проект, проект складний і великий. І так як ми не накидуємо багато тестів, то тут більше саме sdet роботи. Тому автоматизаторів я до себе не беру.
5. Робота sdet в моєму кейсі складає 90%. Задизайнити рішення, імплементувати все для тестів — то складно. А от написати потім самі тести — то вже проста справа, яка не займає багато часу. То ж і не турбую з цим тестувальників.
6. Тут є така проблема. Я на продукті і мені тут добре )
7. Це ж не означає, що цю роботу мені хтось має дати. Це та робота, яку я сам обираю виконати, бо мені так зручніше. І це ні в якому разі не «вершина».

покращення testability продукту

як на мене, більш важка справа.

Дякую за конструктив! )

Підкажіть будь ласка, пишу софти які автоматизують різні задачі за допомогою puppeteer або просто на http запитах (парсери, чекери, реєстратори, постери) і так далі, чи тяжко буде перейти в test automation?

puppeteer інструмент для автоматизації UI. Це дуже корисний скіл у вашому напрямку. HTTP запити згодяться для автоматизації апі, та й ще для багато чого. То ж вектор непоганий, але все ж залежить від проекта. Як ви могли здогадатися, для мене важливіші навичку у програмуванні. Впевнений, що знайдеться проект, для якого ваших поточних знань буде достатньо. Питання тоді тільки — чи достатньо вам буде цього проекту. Я всім рекламую 2 канали (обох знаю особисто — дуже кваліфіковані хлопці):
www.youtube.com/c/OleksandrKhotemskyi
www.youtube.com/...​c/SimpleAutomationTesting
подивіться, може допоможе скласти план куди і як розвиватися далі

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

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

TestOps, SDET, SET, Test automation, AQA, і найбільше яке мене бісить «автаматчік». Скільки цих лічок не придумуй, а сенс одинаковий. Ми хочемо назвою позиції описати обов‘язки. Але це не правильно. Бо не назва визначає позицію, а обов‘язки. Обов‘язки залежать від конкретного проекту чи компанії і завжди відрізнаються, бо не може бути одинакових бізнес процесів у різних компаніях. Тому, оці всі порівняння яка у кого лейбочка взагалі нічого не варті.
Історично терміни SDET/SET пішли від Microsoft/Google і описані у їхніх книгах. Але через їхню специфіку такий розподіл там оправданий. Бо потрібно окремі люди які будуть будувати інструменти для тестування, бо стандартні не дуже підходять.
Виходячи з того всього дуже не люблю коли пишуть — оцей може робити це, а оцейвот може робити ось це. У тайтлі у вас може писати QA інженер і ви можете писати пайплайни, а можете бути і Java інженером, а по факту ковиряти XML і фіксати CSS
Але звісно SDET звучить трохи солідніше ніж якийсь там Test Automation (це жарт)

P.S. Ще існує давній батл — хто крутіше Developer чи Software Engineer чи Programmer

Для мене лички — це і є обов’язки. У нас їх просто не юзають за призначенням, але то проблема нашого ринка. Навіщо придумали назви паттернам, якщо паттерн — це типове рішення типової проблеми? Щоб не описувати це все кожного разу. Так і з личками.

але то проблема нашого ринка

це не проблема «нашого ринку». У нас ситуація не сильно відрізняється від іншого ринку
Так усюди. Людям легше сприймати, коли мислити категоріями. Типу, тестер — тестує, девелопер — девелопить.
Але в реальності не так — реальність дуже залежить від конкретного проекта\компанії. Десь, людина котру називають SDET виконує лише ручну регресію. А десь QA інженер пише фреймворк з 0.

Навіщо придумали назви паттернам, якщо паттерн — це типове рішення типової проблеми?

з патернами трохи по іншому. Бо у них є чітке визначення. А ось у описі лічки немає цього. ти не можеш сказати дуже чітко де закінчується SDET і починається не SDET. Але от дуже чітко можеш пояснити це на прикладі одинака та фабрики.

Як на мене, все геть неправильно написано

Задача автоматизатора — написати якомога більше автотестів, тоді як задача SDET — написати якомога менше тестів, але так, щоб вони принесли якнайбільше користі.

Це якісь неосяжні рівні логіки, не розумію, як до такого можна було дійти

Можна трошечки більше конкретики? Знаю купу проектів, де автотести накидуються пачками. То як описати ту задачу? Знаю проекти, де не міряються кількістю автотестів, але валью вони приносять багато.
Напишіть правильно з вашої точки зору. Це ж топік для обговорення. Бажано, конструктивного )

Власне гарні приклади. Але тут проблема процесів чи підходів до автоматизації, а не тому що на проекті не SDET

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

Драйвити процес має інженер/людина. І не важливо чи у тебе написато, що ти sdet, test automation чи developer.

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

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

Залежить, на основі чого береться початкова кількість
Якщо є 300 рекваєрментів, які відповідають всім критеріям і на них є 300 кейсів, які тестують свій окремий незалежний від інших функціонал, і які треба автоматизувати, то в якому місці написання 50 замість 300 принесе більше користі?

Бо можна написати один е2е тест, який розріже весь додаток і буде мати велике value, а можна наплодити 100500 тестів, які будуть перевіряти, що елементи є на сторінці, або щось типу того.

Чудово, один здоровезний кейс, який перевіряє 100500 різного функціоналу одночасно і коли він падає, потрібно кожен раз парсити тисячі рядків логу, щоб знайти а що ж саме на цей раз зламалось, і який видає чудову метрику 50/50 — в нас або все ок, або від 1 до n фейлів, які ще треба знайти
Замість того, щоб ’наплодити 100500′ незалежних атомарних тестів, які видають цілком нормальні метрики % успішності, і де можна досить легко навіть за ID визначити конкретний зафейлений кейс?

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

Тут теж таке, а 100500 юніт тестів підтримувати легше? Я не кажу за 100500 е2е тестів, але на кожному рівні повинна бути достатня кількість тестив і якшо на ривні е2е треба 100500 тестів, і це ніяк не перенести на рівень нище, то що робити?

Очевидно, що писати 100500. Знову ж таки, з мого досвіду багато хто пише 100500 з потрібних 100.

Ви наче не були на проектах з десятками тисяч тестів, джобами по 8 годин і вічно червоним CI.

Був, ми мали запускати їх на ніч, а на другий день розібрати всі фейли і відрfпортувати баг або в один з дев проектів, якщо це баг аппки, або в тест девелопмент проект, якщо це баг самого тесту/інфраструктури, причому встигнути розібрати за день
Але
1) «вічно червоний CI» це проблема більше ситуації на проекті, ніж до кількості. Ок, є 100 ’простих накиданих’ тестів, з яких 20% падає з різних причин, так якщо їх переписати в 30 складних e2e сценаріїв, які перевіряють те саме, але об’єднане в складніші флови, то і фейли нікуди не дінуться, і CI червоний буде все одно
2) На етапі звітів і логів, буде все одно те саме, просто трохи різні рівні — не бачу великої різниці, чи в тебе 10 кейсів по 3-4 степи, чи 1 складний е2е кейс, але в ньому ті ж ~10 степів по ~3-4 сабстепи.

Тут справа не в тому, що з 10 маленьких зробити те саме, але 1. А в тому, що взагалі тестувати на UI рівні. Тобто 10 маленьких непотрібних викинути взагалі, 1 побільше додати.
PS не стверджую, що к вас були саме непотрібні )

А в тому, що взагалі тестувати на UI рівні. Тобто 10 маленьких непотрібних викинути взагалі, 1 побільше додати.

Мабуть, що описано в вимогах, сторях, специфікаціях, те і тестувати. Непотрібні тести це взагалі щось незрозуміле, якщо тест перевіряє щось, якусь логіку, функціональність чи вимогу, навіть чи якийсь лейбл написаний правильно як в дизайні чи є лого клієнта в хедері, він вже потрібний, він вже містить value і вже виконує свою роботу, так воно менше, ніж перевірка сортування і т.п., але воно є, а edge кейси ’low severity, high priority’, особливо на демках з клієнтами, ніхто не відміняв.
Свідомо викидати кейси, це свідомо знижувати покриття вимог кейсами, свідомо пропускати потенційні дефекти і відповідно знижувати потенційну якість самої аппки, буквально протилежне тому, що ви повинні робити як QA
У мене взагалі складається враження, що ви свою потребу і роботу SDET/QA бачите в тому, щоб в логах/джобах все обов’язково було зелене і passed, ні одного зафейленого кейса, навіть якщо для цього потрібно виключити частину перевірок, бо вони вам псують всю картину.

Ви читаєте тільки ті рядки, мабуть, які вам хочеться прочитати.

А в тому, що взагалі тестувати на UI рівні

на UI рівні. Лого, лейбли і все інше маленьке треба виносити в юніт тести. Які є швидкі і надійні на відміну від UI рівня. В цьому взагалі головна суть статті.

можна:

Задача автоматизатора — написати якомога більше автотестів, тоді як задача SDET — написати якомога менше тестів, але так, щоб вони принесли якнайбільше користі.

неправильно
1. В ідеалі, коли є правильний розподіл і розуміння ролей та обов’язків, то задача AQA — писати автотести і проводити саме тестування, тоді як задача SDET — розробляти і підтримувати інфраструктуру і тестові ліби/тули/конфігурацію/стенди за допомогою яких QA пишуть тести, ранять їх, збирають результати/метрики, парсять логи фейлів і т.д. В деяких випадках, SDET може і писати самі автотести чи скрипти, але знову ж таки — він їх не ранить, не тестує ними функціонал, не репортить результати тестів і баги — він повинен займатися виключно тестовою інфраструктурою як такою.
На прикладі того ж PageObject-a: SDET описує всі пейджі і всі методи для них, які клікають, селектають, чекають чекбокси і т.д., QA пише тестові сценарії з використанням написаного PO і відповідних методів; Чи у випадку API — SDET пише клієнта, в якому огортає всі ендпойти в методи, з параметрами і опрацюванням різних статус-кодів і помилок, QA — пише автотести, в яких використовує логіку написаного клієнта для перевірки певного функціоналу і т.д.

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

2. Відповідно, і навичок мануального тестування SDETу не потрібно на такому ж рівні, як M/A QA, лише базове поняття, а так то — в основному програмування, трохи по девопс, трохи по тест фрейморках і лібах типу того ж селеніума чи requests.
3. Але оскільки в Україні оця дурнувата мода на ’овнершіп’, коли з тебе хочуть зробити всього потроху, і не так багато проектів з великими командами, то і SDETів як таких мало хто може собі дозволити. Це ще повезло, якщо тебе як AQA не грузять мануальщиною чи роботою девопса

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

Може й має, але точно не повинен — в девів є репо з product code, в сдетів/автотестерів є репо з test & tools code, кожен працює в своєму і не лізе своїми руками до чужого

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

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

неправильно

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

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

Може й має, але точно не повинен — в девів є репо з product code, в сдетів/автотестерів є репо з test & tools code, кожен працює в своєму і не лізе своїми руками до чужого

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

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

Так. І це нормально. А, якщо людина, яка написала гімнокод, вже не працює на проекті? Не викидати ж функціонал ) Ну а під юніт тести дуже часто приходиться рефакторити код і це абсолютно нормально. При цьому не обов’язково буди оунером того коду. Погоджуватися не обов’язково, переконувати не планую )

1) А з чого ви визначаєте, що саме SDET повинен покращувати тестабіліті коду? То є справа кожного QA. Якщо мануальний тестувальник не може щось протестувати, він же все одно просить дева допомогти якимось речами (це як приклад).
2) Я чимось згоден з попереднім коментарем про те, що QA не повинен лізти до коду аплікації. Да, гарний QA, навіть манульшік може то зробити, але не повинен. На те є якісь процеси. І якщо вам складно переключатися з таски на таску то проблеми не процесу. Розробники ж переключаються коли фіксять баги.
3) Якщо під юніт тести треба рефакторити код, то то чи тести погано продумані, чи той, хто їх пише не розуміє, що він робить. Єдине, коли це працює, то коли використовують ТДД, але і там рефакторінг, то вже найостанніша річ, тому що рефакторінг, це найрискована активність з точки зору роботи з кодом.

1. Це, доречі, один із оригінальних гуглових пунктів, якщо я не помиляюсь. Мануальник просить, а sdet йде і міняє. Але тут більше мова про тестабельність під юніт тести.
2. Будь-яке перемикання то є втрата контексту і часу. Як у sdet так і у девів. І я є адептом теорії, що процеси мають працювати на людину, а не людина на процеси. У мене на проекті ніхто не жаліється, що я баги фікшу, локатори ставлю, тести додаю.
3. Тут у нас абсолютно протилежне бачення

Авжеж ніхто не буде сперічатися, коли ти робиш роботу за іншіх )
Про рефакторінг, то холіварка, тож можемо пропустити )

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

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

Тут все ще простіше:
1. Юніт тести на свій код пишуть самі девелопери
2. Код якоїсь фічі/змін, не покритий юніт тестами або який їх фейлить — він не готовий в принципі до того, щоб з ним починали працювати MQA/AQA/SDETи
Стосовно драйвлення тестабельності коду — згоден, але у вигляді співпраці з девами — на початку розробки зібратись узгодити якийсь стиль, які і де проставляєм ідшки і т.д., можна додати ще рев’ю їх коду з сторони SDETів як обов’язковий етап аппруву, і залишати коменти з реквестами змін в місцях, де і які бажані зміни вам потрібні. Але ж не лізти безпосередньо в чужий код, це якась дічь. От є девелопер, якому дали якусь фічу в розробку, за яку він відповідає — робить собі бренчу, щось там коммітить, мерджає, резолвить конфлікти і тут в один момент до його коду залазить навіть не інший дев тіммейт чи дев тім лід, а чувак з QA департменту і починає щось там фіксати, чи переписувати, чи проставляти якісь айдішки, це трохи дивно

Так. І це нормально. А, якщо людина, яка написала гімнокод, вже не працює на проекті? Не викидати ж функціонал )

На девівський гімнокод є свій Dev лід чи менеджер, який за нього і відповідає, в т.ч. і хто замінює автора гімнокоду, і має його рефакторити, це не Ваші проблеми як QA Manager-a.

Ну а під юніт тести дуже часто приходиться рефакторити код і це абсолютно нормально.

Ну виглядає трохи дивно, а хіба не може бути таке, що після такого ’рефактору’ юніт-тест запрацював, а сам функціонал змінився від очікуваного?

1. Юніт тести на свій код пишуть самі девелопери

А якщо не пишуть? Або пишуть, але недостатньо, або написали, але не зовсім те, що треба протестувати? Або практика написання юніт тестів з’явилася після перших пів мільйона рядків і тепер юніт тести пишуть тільки на новий функціонал? Якщо це не сферичний проект в вакуумі?

2. Код якоїсь фічі/змін, не покритий юніт тестами або який їх фейлить — він не готовий в принципі до того, щоб з ним починали працювати MQA/AQA/SDETи

Дуже здорова думка. Я про такі проекти не чув )

узгодити якийсь стиль, які і де проставляєм ідшки

так я теж раніше пробував — не заїхало. Важкувато девам пояснити де саме мені треба. Та і вони дуже не люблять то робити.

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

Ось тут впевнений, що не поїде. Я був 1 на 30 девів. У мене фізично не вистачить часу всі рев’ю робити. І зробити рев’ю важче ніж поставити локатори.

От є девелопер, якому дали якусь фічу в розробку, за яку він відповідає

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

На девівський гімнокод є свій Dev лід чи менеджер, який за нього і відповідає, в т.ч. і хто замінює автора гімнокоду, і має його рефакторити, це не Ваші проблеми як QA Manager-a.

Я тут віщаю з точки зору sdet ) І якщо мені треба покрити тестами функціонал — я не буду чекати пів року, поки у когось іншого дойдуть до цього руки. Responsibility is not something to be given but something to be taken.

Ну виглядає трохи дивно, а хіба не може бути таке, що після такого ’рефактору’ юніт-тест запрацював, а сам функціонал змінився від очікуваного?

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

А якщо не пишуть? Або пишуть, але недостатньо, або написали, але не зовсім те, що треба протестувати? Або практика написання юніт тестів з’явилася після перших пів мільйона рядків і тепер юніт тести пишуть тільки на новий функціонал?

Тоді ви будете виловлювати більше своїми тестами, якщо код буде взагалі здатний до того, щоб його автоматизовувати без юніт тестів

У мене фізично не вистачить часу всі рев’ю робити.

Якщо перестати робити роботу за інших, то глядиш і час з’явиться

І зробити рев’ю важче ніж поставити локатори.

Само собою, зробив і забув, розрулювати ваші ’фікси’ потім потрібно не вам, а деву, на якому цей таск висить

І нема різниці, який тайтл у людини, яка лізе в його код, якщо ця людина знає, що вона робить.

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

Тоді ви будете виловлювати більше своїми тестами,

не буду, бо я не пишу юніт тести на рівні UI.

Якщо перестати робити роботу за інших, то глядиш і час з’явиться

Ви певно знущаєтесь просто? Скільки разів я вже казав, що я собі тим час економлю?

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

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

Грубо кажучи, вся та теорія з istqb силабусу і вміння та досвід її правильно застосовувати, але там є важливе уточнення — на такому ж рівні, що і MQA, база все одно необхідна. Однак, оскільки чистий SDET, на мою думку, мінімально або взагалі не залучений до тестових активностей як таких, тим більше мануальних, то хороші MQA знання чи досвід — це чудово і зайвим не буде, але застосовувати буде практично ніде, він девелопить, а не тестує(на те і SDET, а не STET).
А так то стати може хто завгодно, навіть Client Happiness Manager

Погодьте, тут чи я щось не так розумію, чи вам є що ще пояснити. «Навички мануального тестування непотрібні» і «база на такому ж рівні, що і MQA все одно необхідна». Чи ці ствердження не протирічать одне одному? Взагалі ваш концепт зрозумілий якщо ввести в дискусію ще одного звіра — Test Engineer. От тоді мабуть так, SDET може бути власне розробником, спеціалізованим на розробці тестових фреймворків.

заплутано написано, про рівень — це було щодо навичок, а не бази:
«навички мануального тестування SDET не потрібні на такому ж рівні, які MQA», але знову ж таки, залежить від того, наскільки виключно SDET залучений в сам процес тестування, якщо це наприклад якась internal tools тім, яка пиляє кастомний аллюрподібний репорт, який би генерував красиві графіки і діаграми для клієнта з тестових логів, то в такому випадку взагалі можна обійтися без, тому що навряд чи в тому інструменті буде якась складна тестова логіка, звичайний девелопмент.

мабуть так, SDET може бути власне розробником, спеціалізованим на розробці тестових фреймворків

ну так, не те що може, а має бути, на мою думку.

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