«Буде боляче». Мій шлях з мануального тестування до автоматизації

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

Вітаю українську спільноту ДОУ. Мене звуть Костя (Dneprokos-майже всюди). І я більше 16 років працюю у розробці програмного забезпечення на різних посадах, пов’язаних з контролем та забезпеченням якості. На даний момент працюю на позиціі QA Team Lead’а та Feature Owner’а (це специфічна роль у компаніі). Також являюся засновником QA Guild та гільд мастером у цій компанії. Це була моя ініціатива і я хочу іі розширювати.

Авжеж я бачив і динозаврів, і девів у светрах з оленями, і трохи появлення украінського аутсорсу у маштабі. Але сьогодні не про це. Буду відвертий, бо причина написання цієї статті полягає у тому, що я вже декілька раз пообіцяв це ком’юніті менеджерам ДОУ:) Я знаю, обіцяти то не значить одружуватися, але в якийсь момент мені вже просто стало соромно.

Ще одна ремарка, що ця стаття не була написана з нуля. Колись я вже публікував подібну статтю на Medium та разом з QA Group ми робили вебінар.

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

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

То про що ж ми сьогодні говоримо? Ми обговоримо непростий і подекуди болючий шлях переходу від ручного тестування до моменту, коли це набридає, і ви вирішуєте щось змінити. Або ж коли тиск суспільства змушує вас задуматися: всюди тільки й чути — автоматизація, автоматизація, Playwright, TypeScript, Python, AI-агенти... І врешті-решт ви здаєтеся під цим натиском.

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

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

Давним-давно, у далекій галактиці, у місті Дніпро мене взяли на роботу в мою першу компанію — ISD. Тоді я ще не розумів, що на мене чекає. Та що там, я взагалі не усвідомлював, куди потрапив.

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

Спойлер: він досі там працює, і не просто працює, а займає високу менеджерську посаду. В англійському футболі для таких людей є термін — «One-club men».

До речі, я — вболівальник Манчестер Юнайтед. І мені не соромно.

Буду прискорюватися, бо основна тема все ж про перехід в автоматизацію.

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

Що робити далі? Чесно, на той момент я не знав. До того ж, я не був зразковим у навчанні. Молодість. Але я спробував.

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

Дев-лід зробив ресерч і запропонував тестовий фреймворк на Java-Fucidia чи щось подібне. Чесно кажучи, зараз уже не пам’ятаю і спеціально не гуглив. Можете мене за це закидати камінням.

Я спробував... і застопорився. Спочатку намагався щось робити за аналогією (читай: копіювати). Але коли доходило до чогось складнішого, я просто впадав у депресію. Чесно кажучи, мабуть, я просто не хотів зробити крок уперед.

Це була моя перша велика помилка.

Так і завершився цей маленький проєкт, у якому я так і не навчився автоматизувати.

Але потім у моєму житті з’явилася інша продуктова компанія, яка дала мені другий шанс і допомогла перезавантажити цей процес.

Та все одно, Максе, дякую за спробу.

Sitecore

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

Або... можливо, вони просто не забули, що ми обіграли їх на футбольному турнірі. Хоча, навряд чи.

Цього разу все було інакше.

Вони погодилися взяти мене, але за умови, що я буду навчатися. За словами мого тезки-менеджера, 80% QA у компанії вже автоматизували свою роботу. І це дійсно було правдою.

Тоді я потрапив у зовсім інший світ.

По-перше, був дуже незвичайний probation period. Наприкінці потрібно було скласти усний екзамен та пройти практичну частину, де треба було написати сайт на Sitecore.

Це було важко, але — PASSED.

А далі?

А далі почалася автоматизація.

Але не все так просто...

Specflow / Cucumber

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

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

Якщо коротко, для тих, хто не знає:

👉 Ми писали тестові сценарії на специфічній мові Gherkin.

Потім усе це мапиться на мову програмування, яку ви використовуєте. У нашому випадку це був C#.

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

Боже мій, я це не продаю! 😅 Але іноді це справді може спрацювати, особливо якщо Product Owners або бізнес-аналітики розуміють цей підхід і готові писати історії у такому стилі.

Але є основна проблема:

🔹 Іноді менеджери чули і бачили cucumber/specflow, але ніхто не готовий приймати участі у будуванні вимог у такому стилі чи навіть дивитися у цей бік.
🔹 І ось тут у мене, вже з досвідом, завжди виникає логічне питання: «А навіщо воно вам потрібно?»

Часто тести потрібні лише самим QA, тоді як менеджерів цікавить лише результат — чи готові ми до релізу на основі тестування. Тому в майбутньому я завжди намагався відговорити менеджмент від цього підходу.

Але все ж таки повернемося назад у часі.

Мені пощастило: працюючи у Sitecore, я отримав досвід як у написанні API-тестів, так і в автоматизації через Selenium. Дуже дякую двом девелоперам, Дмитру та Олександру, за те, що терпіли мій спротив і все ж дуже допомогли мені. Я ніколи не забуду цей перший успішний експіріенс.

Нові горизонти та зміна майндсету

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

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

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

Тобто ні, у цілому я навчився писати API та Web-тести.

Але все одно це було більше про копіювання за аналогією.

16-17 травня, Київ. Квитки тут!👇

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

Але спершу я вирішив здати ISTQB.

Раніше я вже готувався до нього, але все ніяк не наважувався скласти іспит. Цього разу я вирішив діяти простіше — просто купив іспит на двомісячну перспективу. Всі два місяці я ретельно готувався. Кумедний момент: я навіть не звернув уваги на дату і призначив іспит на 7 березня. Здавав у SoftServe Academy. Вранці прийшов на місце і побачив, як всі бігають з квітами по офісу 😄 Здав дуже швидко. Аж сам «стреманувся», як швидко. Але найголовніше, що саме цей кейс дав мені зрозуміти одну важливу річ:

👉 Якщо чогось хочеш, ставиш мету, ретельно готуєшся — то ти можеш цього досягти.

Потрібно просто працювати. Помилятися. Вставати. І знову працювати. Це, мабуть, був один із найважливіших уроків. Бо бажання без дій — це просто мрія.

Є одна річ, про яку я забув згадати — я був геймером із 90-х і завжди мріяв створювати власні ігри. І ось у якийсь момент я натрапив на популярний рушій для інді-розробників відеоігор — Unity. Як же він мене захопив! Я раптом зрозумів, що можна не тільки грати, але й створювати ігри.

Unity — це рушій, який досить лагідний для новачків, але він вимагає знання мови програмування. Якраз C#, яку ми використовували у компанії. І тут я зламався. Довелося вчити не тільки сам рушій, а й саму мову програмування. Але і тут мені дуже пощастило (Lucky+8) — з самого початку на Udemy я натрапив на курси Mosh’a Hamedani.

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

Але повернемося назад.

Я пройшов декілька рівнів курсів по C#, а також курс по ООП.

Гру мрії я так і не випустив. Єдиний виняток (багато років потому) — це прощальна гра для однієї з моїх улюблених команд. Привіт, Retail Express!

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

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

Вогні великого міста та нові можливості

Так. Киів. А ще бонусний пакет — можливість працювати віддалено ще до епохи COVID. Офіс теж був доступний, бо вдома можна збожеволіти 😄 Мене взяли на позицію Senior QA Automation, хоча, чесно кажучи, я не був упевнений, що дійсно відповідав цьому рівню.

У Києві я познайомився з колегою, який теж переїхав із Одеси.

Ми дуже швидко здружилися і пропрацювали разом кілька років. Юра, привіт, якщо читаєш! 👋

Досить скоро, окрім роботи, ми з ним почали щотижня збиратися для вивчення різних тем.

Що саме ми вчили?

• Дизайн-патерни.
• Алгоритми.
• Контейнеризацію.
• Розв’язання задач.
• Та багато інших технічних тем.

Як це працювало?

• Ми разом (іноді до нас приєднувалися інші люди) вивчали тему.
• Готували презентацію.
• Обговорювали її та вирішували задачі.

Цей формат сильно підняв наші скіли на новий рівень.

Я вважаю такий підхід надзвичайно ефективним:
✔️ Він дає азарт.
✔️ Він створює дух змагання.
✔️ Він допомагає глибше зрозуміти матеріал.

З часом мені стало цікаво вивчати інші мови програмування.

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

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

Ще одним великим плюсом було те, що в нашій компанії вже працював мій хороший знайомий — Олексій, засновник Kyiv Testers Meetup. Олексій, привіт! 👋

На той момент це був мій улюблений мітап у Києві — з неформальною, дружньою атмосферою і крутою спільнотою. Саме там я зробив свої перші публічні виступи. Пам’ятаю, як ледь не зомлів під час першого, але склянка води (саме води 😄) допомогла зібратися, і врешті все пройшло чудово. Навіть знайшов звіт з того мітапу. А ще завжди були приємні after party. Ну це вже офтоп :)

Загалом QA-ком’юніті у Києві було набагато розвинутішим, ніж у моєму рідному місті. Це дало мені величезні можливості для розвитку, навчання та знайомства з цікавими людьми. Нагадаю, що то ще були доковідні часи, і більшість зустрічей була саме офлайн. Тому я дуже рекомендую всім знайти своє ком’юніті — це справді допомагає зростати і професійно, і особисто. А також зустрічати цікавих людей. А хто ще не знайшов — запрошуємо до Суворе QA Community. Кінець реклами :)

Далі було багато всього — як цікавого, так і не дуже.

• Написання тестових рішень як для enterprise-рівня, так і для невеликих проектів.
• Вивчення паттернів проектування.
• Вивчення бібліотек та написання проектів.
• Лідерство команд та навчання автоматизації з нуля.
• Написання статей на Medium.
• Вебінари, воркшопи, навчання груп — не лише на тему автоматизації.
• Створення гільдії і багато чого іншого.

Але давайте спробуємо подумати, як вам почати сьогодні? Так, саме тобі, {currentReaderName()}!

Як почати

Зараз буду Кепом. Скажіть собі: «Я вже автоматизатор». Ні, серйозно. Ви вже ним стали. Так, ви поки що нічого не вмієте, але не порівнюйте себе з тими, хто в індустрії вже багато років. Просто почніть працювати над собою. Ніхто вас не навчить, якщо ви самі цього не захочете.

Другий крок: відключіть AI. Так, він дійсно допомагає в роботі, але повністю ламає процес навчання. При навчанні важливо робити помилки і вчитися їх виправляти. Не біжіть відразу до ChatGPT, Copilot та всього іншого. Спробуйте витратити час та розв’язати проблему самостійно. Тому, коли навчаєтеся — AI у топку.

Третій крок: оберіть, з чого почати. Найкращий варіант для новачків — веб-автоматизація. Бо іі простіше зрозуміти тим, хто ще не полапав код. Selenium все ще популярний на ринку. Playwright зараз домінує у всіх топіках і набагато легший для початківців. Бачу, все ще багато педалять Cypress. Ніколи його не любив, але не буду відмовляти.

Також я не став би ігнорувати можливість вивчення автоматизації API. Але все по черзі — не варто займатися мультитаскінгом. Просто внесіть це у свій план навчання на майбутнє.

Оберіть свою першу мову програмування. Яку?

Це важке питання.

• TS чи Python — модні, зручні та широко використовуються.
• Java, C# — класика, яка все ще домінує в автоматизації.
• Ruby? Rust? Чому б і ні.

Можна перераховувати далі, але тут я би відштовхувався від кількох речей:

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

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

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

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

Що далі

Далі потрібно розширювати свої знання.

Що варто вивчати?

• Структури даних (Data Structures).
• Патерни проєктування (Design Patterns).
• Алгоритми (Algorithms).
• Розв’язування задачок.

Можна почати розбиратися, як працюють аплікації та сервіси зсередини, створюючи свої pet-проєкти.

Не забуваємо про:

• Командний рядок (CLI).
• CI/CD.
• Контейнери (Docker, Kubernetes).

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

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

Питання було таке:

«Чи актуально сьогодні вивчати мови програмування, дизайн-патерни, алгоритми? Чи, можливо, через розвиток AI усе більше зводиться до готових патернів, а ці речі вже застаріли?»

І ось які відповіді я отримав...

Інженер«Династія блокчейну»

Вивчення мов програмування, патернів, алгоритмів все ще актуально. Актуально на співбесіді. Актуально — на роботі. Основна проблема із застосуванням AI — це пояснити, ЩО ти хочеш від нього та ЗАВАЛІДУВАТИ те, що він тобі згенерував.

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

Інженер"Гурусай"

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

Інженер"Гарячий"

Я у захваті від сучасних AI-тулів. Моя рекомендація — НЕ МОЖНА копіпастити, не розібравшись з тим, що генерує АІ. Якщо ти не зрозумієш — поки не розберешся, не копіпасть.

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

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

Інженер"Кобзар"

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

Інженер"Кукумбер"

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

Дякую нашим експертам!

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

І наостанок

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

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