На просторах редіту натрапив на рефлексію з приводу автоматизації. На думку автора, раніше вона мала економити час, але тепер підтримка тих же скриптів — це окремий спринт.
Один змінений локатор і доводиться пару годин фіксити тести. Нова версія фреймворку і половина пайплайну ламається, а менеджмент все ще питає «А можемо ще щось автоматизувати?»
Тож як ви думаєте: коли автоматизація перестає допомагати і починає створювати хаос?
Як казала моя керівниця ще в попередньому сторіччі: «якщо автоматизувати бардак, то буде автоматизований бардак». Тому перед автоматизацією треба бізнес процеси розробити та почати впроваджувати разом з автоматизацією. Інколи дебаг бізнес процесів складніше за дебаг коду.
Автоматизуючи бардак, на виході отримуєш автоматизований бардак.
Vad Tymoshyk
Technical Lead, AWS Professional Services | Cloud, DevSecOps & SRE Strategy
18.10.2025 00:40
Перший продукт, який запровадив пайплайни (чи знаєш який?) використовував саме Баш для пайплайнів. Ми в
Повер шел скріпти на своєму білд агенті працюють безвідмовно з 2017 року. На відміну від MS-hosted образах макосі чи, прості господі, лежачий по тижню, fastline.
Ніколи не було проблем, на відміну роботи з «чужими» рішеннями.
Чому PS — тому шо той самий андроід може працювати на трьох ОС одночасно.
diminishing marginal returns в чистому вигляді.
Тобто кожен скрипт з першої сотні написаних окупиться за півроку, з другої — за рік, з третьої — за два, з четвертої — не окупиться, з пʼятої- має відʼємну прибутковість.
Як кажуть досвідчені люди: «Якщо ваші процеси — це накидання лайна на вентилятор вручну, то автоматизація не поліпшить процеси, а навпаки — лише збільшить потік автоматизованого лайна та радіус розкидання»
Чудова тема, це біль багатьох команд. На мою думку, хаос починається в той момент, коли вартість підтримки тестів перевищує цінність, яку вони приносять. Коли команда витрачає більше часу на виправлення «червоного» білду, ніж на створення нових тестів чи ручне тестування.
І тут, мені здається, AI вносить цікаві корективи. Він не вирішує проблему поганої архітектури тестів, але може значно знизити вартість їх підтримки. Наприклад, замість того, щоб годинами дебажити тест, що впав, можна «згодувати» лог помилки та код тесту в AI і попросити його знайти ймовірну причину. Це перетворює 2 години роботи на 15 хвилин.
О, ні, штука яка потенційно може зекономити сотні людино-годин мануальщиків вимагає роботи кількох людей для її підтримки, не може бути.
Увесь low lvl design в програмуванні націлений на простоту впровадження змін. Змінюється продукт, змінюються й тести, тому в автоматизації треба застосовувати ті ж прийоми.
Один змінений локатор і доводиться пару годин фіксити тести.
Тут прекрасно абсолютно все. По-перше, якщо треба прям фіксити кілька годин, отже цей локатор тупо скопійований на n тестів. Де одна пейджа/фрагмент, до якого всі тести звертаються?
Окей, допустимо пейджа у нас вже є, але з кожним оновленням юая локатори злітають і треба їх апдейтити. Для цього Господь дав нам дата куа атрибути. Повісили їх на контроли і навіть якщо фронти перенесли їх в іншу галактику, тести продовжують бачити ці контроли.
Окей, допустимо, ми повісили все це, але всі тести падають, бо фейлить, наприклад, логін пейджа. Не робіть прекондішени на юаї, завантажуйте дані зі снепшота бази або готуйте сетап по апі (в залежності від того, як буде швидше).
Робіть параметризовані тести. Менше коду фіксити в разі змін.
Окай, уявімо, у нас мільярд тестів, мільйон з яких падає кожен реліз. Не ставтеся до е2е тестів, як до юніт тестів. Якщо у вас не лайф крітікал проект, якщо робите save, можете перевірити його через read, не треба ходити в базу і дивитися там. Так, якщо read поламаний, тест на save теж впаде, але підтримувати кілька апі колів набагато легше, ніж динамічно будувати sql з джойнами.
Не треба плодити 1000500 параметризованих тестів, юзайте класи еквівалентності, граничні значення і все те, що ви скіпнули бо подумали, що автоматизатору то не треба.
Скорочуйте флоу. Якщо це юайний тест, не робіть великий тест на crud. Зробіть по одному на кожну операцію. Коду більше, але працюватиме значно стабільніше.
Якщо у вас немає жорсткої вимоги до контракту апі, ігнор полів, які ламають десеріалізацію, підвищить стабільність тестів. Але обережно з цим, бо можна пропустити баги.
Ретраї. Flaky тести існуватимуть завжди. Тому перезапустити впавший тест разок, значно підвищить стабільність всього білда.
Контрольоване середовище. Якщо у вас один стейджинг на всіх або ви ганяєте тести локально, ви приречені на рандомні таймаути. Майте окремий інстанс апки і окремий інстанс де ганяються тести. Так ви точно будете впевнені, що проц/пам‘ять/мережа не забита якимись важкими запитами інших людей.
Це все не складно, треба просто підходити з розумом, а не «я написав скріптік на джиесі, тепер звільнимо всіх мануальщиків»
Vad Tymoshyk
Technical Lead, AWS Professional Services | Cloud, DevSecOps & SRE Strategy
15.10.2025 20:25
Автоматизація справді починалася зі звичайних скриптів. Проте сьогодні це вже повноцінний внутрішній продукт, який варто розглядати за рівнем важливості та складності так само, як і основний продукт: ті ж принципи SDLC, тестування, планування тощо мають застосовуватися й тут. Лише з таким підходом усе стає на свої місця — адже автоматизація потребує часу, зусиль і ресурсів — як технічних, так і людських.
По-перше — автоматизація чого саме? А створювати хаос вона починає на етапі проектування. Для створення ефективної системи автоматизації необхідне глибоке усвідомлення проблеми, яку планується вирішити за допомоги автоматизації, обізнаність з методами її вирішення, а найскладніше — обізнаність з методами, якими цю проблему буде вирішувати виконавець.
Это означает, что в автоматизации накоплен большой технический долг и пришло время его фиксить. Если, конечно, уровень автоматизаторов позволяет его осознать и пофиксить.
Бажила такого багато, і це при тому, що автоматизатори отримають зп більше
До такої гіперболізованої ситуації не доходило, але певне відчуття «йой, тести пофіксав — і більше нічого не встигаю» таки траплялося.
Тому став вимірювати розподіл часу автоматизаторів на різні види діяльності. При роботі наодинці і до рефакторингу фреймворку час на його підтримку сягав 40%. Але це все одно економія, бо так я витрачав свої умовні 16 годин/тиждень, щоби автоматизація працювала — а мануальники на ті самі щоденні регресії та смоуки витратили би сотні людино-годин.
До речі, показ цього «на що пішов наш оплачений час» виступає доволі непоганим аргументом на користь розширення команди і необхідності рефакторингу. Бо якщо одна людина повністю зайнята підтримкою, то всі інші тим часом можуть і покриття розширювати.
є такий бізнес-роман «Мета», автор Еліяху Голдрат
www.yakaboo.ua/...vnogo-vdoskonalennja.html
за допомогою джпт витягнув з нього приклад:
.....................
Ось типова ситуація з книги «Мета», але узагальнена:
✅ Ситуація: «Нова технологія заради технології»
На заводі встановили сучасний високошвидкісний верстат, який може обробляти деталі у 2 рази швидше. Керівництво вважає, що це підвищить продуктивність.
Але в реальності:
Цей верстат не є вузьким місцем у процесі.
Деталі після обробки чекають у черзі на іншому, повільнішому обладнанні.
Щоб «завантажити» новий верстат по максимуму, оператори запускають великі партії продукції.
У результаті:
— ростуть запаси незавершеного виробництва (WIP),
— збільшується час проходження замовлення,
— склад перевантажений,
— з’являються збої у логістиці та плануванні.
Висновок: нова технологія не тільки не покращила результат, а погіршила роботу системи, бо її встановили не там, де було справжнє обмеження.
...............
Примітка:
Еліяху Голдрат вважав, що люди приходять на роботу, для того, щоб заробляти гроші... тобто успіх компанії оцінюється виключно у грошових одиницях..
У зв’язку з чим впровадження нової технології має сенс лише у тому випадку, коли це позитивно вплине на фінансові показники...
Персонально може вплинути -VP (CTO) може отримати премію або відкат
Один змінений локатор і доводиться пару годин фіксити тести. Нова версія фреймворку і половина пайплайну ламається
Нє, ну як воно навайбкодено лівим полужопієм — то шо ж вже, це ж звісно автоматизація як така винна, а шо ще.
Mykhailo Kondratiuk
Михайло Скубченко
Grez
Dmytro Bondarenko
Б Артюшенко
Oleksandr Viter
Mykhailo Tsymbaliuk
Вова Москаленко
Дмитрий Мирошник
Yaroslava Malash
Borys Yevstyhneiev
Юра
Evgeny Sergeev
Юра
Yuri Glushko
19 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів