Про менторство QA-інженера DevOps скілам

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

Вітаю, я Євген Кошманов, ментор з DevOps напрямку, автор матеріалів на профільну тематику. Останні два роки я співпрацював з різними фахівцями галузі IT і вирішив поділитись з вами своїм досвідом. Цей матеріал буде цікавим, зокрема, спеціалістам з QA, які бажають покращити свій рівень та розширити навички в DevOps, та саме інжинірингу проєктів.

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

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

Цілі ментора і менті. Ролі, де кожен отримує своє

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

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

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

• Хмарних технологій
• CICD підходів та автоматизації.
• Контейнеризації.

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

Результатом менторства має стати персональне та професійне зростання підопічного, що супроводжується:

• підвищенням професійності;
• покращенням технічних навичок;
• поліпшенням комунікаційних навичок;
• зростанням досвіду;
• закріпленням позицій менті у професійному середовищі;
• набуттям корисних зв’язків;
• збільшенням рівня дохідності.

Що цікаво, питання дохідності не завжди є першочерговим для людей, які шукають менторства. Був у мене такий кейс, де фахівець потребував допомоги з вивченням DevOps, хоча формально не мав до цього жодного відношення. Але з огляду на цілі та мету цього спеціаліста, я вирішив взятись за менторство і допомогти йому вивчити технології, що його цікавили. Погляньте, як ми співпрацювали та яких результатів досягли:

Кейс менторства: як може трансформуватись початкова мета

Як я вже говорив, менторством займаюсь понад два роки й за цей період встиг попрацювати з близько 20 фахівцями різних профілів. Зокрема, запам’ятався випадок одного інженера, який був моїм менті, назвемо його Микола.

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

Як згодом виявилось, шляхом аналізу кількох фреймворків, їх можливостей та функціоналу (через збір фідбеків на профільних форумах), ми зупинились на тому, що йому потрібно було інтегрувати PlayWright в екосистему компанії. Нагадаю, Playwright — це автоматизаційний фреймворк з відкритим кодом від Microsoft. Він дозволяє автоматизувати тестування в веб-браузерах на основних платформах: Chrome, Edge, Safari. Більш детально про нього можна почитати на сайті проекту — playwright.dev

Мене і самого зацікавив новий досвід, тому угоду ми уклали досить швидко.

Завдання та концепція менторства

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

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

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

Таким чином, ми вибудували наступну концепцію співпраці:

1. Сформували чітке визначення виконаної задачі.
2. Виставили рівень складності на +10% від актуального рівня.
3. Розбили задачі на невеликі фрагменти (щоб цікаво і не в шкоду роботі).
4. Встановили жорсткі дедлайни.
5. Призначили періодичність та тривалість комунікацій.

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

Як ми працювали

Спочатку здавалось, що з процесом роботи виникатимуть проблеми, оскільки існувала деяка невизначеність щодо цілей Колі. Так, пріоритет ми розуміли (вивчення Playwright та його інтеграція в інфраструктуру компанії), але основна складність полягала в суміщенні саме вивчення фреймворку в контексті DevOps.

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

Крок 1. Написати основну інфраструктуру в AWS на Terraform

Що для проєкту найважливіше? Правильно, його архітектура та інфраструктура. Тобто спочатку ми організували фундамент на базі Terraform та AWS, налаштували робоче оточення.

Для цього спочатку потрібно було визначити мінімальний розмір інстанса, і які мережеві порти потребує фреймворк. Потім, базове налаштування Амазону: створення юзера, налаштування бюджету, конфігурація aws cli. І на прикінці описати MVP архітектуру в терраформі, задеплоіти на AWS.

Це стало відправною точкою, яка дозволила зрозуміти основу, отримати практичний досвід роботи над MVP (а це дійсно виглядало як повноцінний проєкт).

Крок 2. Налаштувати Playwright на сервері.

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

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

Крок 3. Встановити сповіщення від Playwright в Slack (для наочності)

Оскільки одна з цілей цього MVP це інтеграція в екосистему компанії, потрібно було продумати основні робочі процеси користувачів. Тому для тестування сповіщень був створений Slack канал, зроблен інформативний темплейт, та налаштовані самі сповіщення.

Крок 4. Пропрацювати структуру репозиторія тестів

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

Крок 5. Підготовка презентації та стратегія переходу до Playwright

Напевно найголовніших крок це підготовка презентації та створення стратегії. Швидкість переїзду та простота впровадження, в життєвий цикл розробки (SDLC), були основними критеріями успіху стратегії. Була поставлена задача створити основні фази переходу на новий підхід, а також, поставлені орієнтовні дедлайни. Згодом цей план був також застосовна в презентації для менеджерів проекту.

Результати

Всього за три місяці Микола отримав досвід та навички роботи з технологіями, методологіями та принципами організації DevOps процесів, як у розрізі посади (Automation QA Engineer), так і поза її межами. З ролі Middle Engineer він трансформувався в лідера команди з розгортання та впровадження Playwright, навчився спілкуватись з Ops-фахівцями спільною мовою, і в результаті цього зміг на наступному перформанс рев’ю значно підвищити свою компенсацію.

Менторство як один з факторів успіху

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

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