Чому мій ранок сьогодні почався не з кави ☕️

Передісторія.
Минулого тижня я вирішила трохи «навести порядок» у Jira.
У багатьох багах не було parent epic - я спокійно додала parent там, де його не вистачало.
Здавалося, абсолютно безневинна і правильна дія. Щоб усе було акуратно ✅

———

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

Я знала, що в нас є Jira Automation, але, якщо чесно, на той момент я про неї просто не подумала.

Виявилося, що в багів, які я оновлювала, були поля (наприклад, Fix Version), які чіпати не можна.
Але коли я прилінкувала Parent, automation автоматично підтягнула Fix Version з parent epic — і це було некоректно ❌

———

І так, мій ранок почався не з кави.
Мені терміново потрібно було:
✔️знайти всі баги, де я минулого тижня додавала parent
✔️зрозуміти, які поля були автоматично змінені
✔️і відкотити все назад

Спочатку я звернулася до Atlassian Rovo (AI-агент Jira) - думала, що він допоможе знайти потрібні тікети.
Але ні 🤷‍♀️
Він нічого корисного так і не знайшов, а я розуміла, що таких тікетів було близько 300🗿

———

І тут, як завжди, мене врятував Python 🐍

Я швидко написала простий скрипт, який:
✔️проходив по історії змін
✔️знаходив моменти, де я додала Parent
і де Jira Automation одразу після цього автоматично змінювала поля

На все пішло приблизно 4 години,
але в результаті:
✔️всі потрібні тікети були знайдені
✔️всі автоматично змінені поля — відновлені

Якби не Python - я навіть не уявляю, як би я рятувала цю ситуацію 😳

Колеги, з наступаючим Новим роком вас!

Цього року я не робила списків, тому не фіксувала, що вийшло, а що - ні.

Із такого явного:
✔️Почала трохи вести YouTube, але треба розібратися зі звуком. Не було навіть часу цим займатися. Але я рада, що почала.
✔️Відклала ISTQB на 2026.
✔️Провела близко 20 консультацій - 80% усіх запитів були про страх почати писати авто-тести. 20% запитів - про те, що автоматизація «зайшла не туди» і все сиплеться.
✔️Рік був періодом сильної адаптації, бо в моїй команді було дуже багато релізів. **Навіть 31 грудня зараз готуємо реліз. Я ще звикаю до такого темпу. Збираю release candidates майже через день, тому була вимушена все інше поставити на паузу.
✔️Ну і, звісно, війна… Сильно змінює пріоритети.

З наступаючим вас!
Дякую, що були цей рік зі мною.
Сподіваюся, ви дізналися щось корисне і нове завдяки цьому каналу.
У 2026 буду намагатися вести канал більш активно❤️

▶️Soft/Hard Assertion in Automation

Дуже важливо в автоматизації , тому хочу лишити це тут, щоб нагадати і раптом хтось не знав - дізнався, бо це база🙏

🔴 Hard assertion — це перевірка, яка одразу зупиняє виконання тесту, якщо умова не виконалась.
Перша помилка → тест упав ❌

Приклад:

from assertpy import assert_that

assert_that(status_code).is_equal_to(200)
assert_that(response["name"]).is_equal_to("John")  # не виконається, якщо перша впала

⸻

🟡 Soft assertion — це перевірка, яка не зупиняє тест одразу, а дозволяє виконати всі перевірки.
Усі помилки збираються і показуються в кінці тесту ⚠️

Приклад:

from assertpy import assert_that, soft_assertions

with soft_assertions():
    assert_that(status_code).is_equal_to(200)
    assert_that(response["name"]).is_equal_to("John")
    assert_that(response["age"]).is_greater_than(18)

У результаті ви отримаєте повний список всіх помилок, а не тільки першу.

⸻

📌 Коли що використовувати:

Hard assertion
✔️ критичні перевірки
✔️ без яких подальший тест не має сенсу

Soft assertion
✔️ перевірка багатьох полів або UI елементів
✔️ коли важливо побачити всі проблеми за один запуск

Як часто ви робите resolve conflict)? 💃

▶️Таке оманливе «Partially»

Є 2 випадки, коли ми найчастіше кажемо «partially».

✔️«Partially automated»
Коли на фічу є трошки тестів. Наприклад, зі 100 всіх тестів є декілька автотестів. Тоді дійсно ми кажемо, що фіча трошки / або не повністю автоматизована.
Тобто partially automated.
Тут зрозуміло.

✔️«Partially failed.»
Тут складніше. Так ми зазвичай кажемо, коли впало кілька тестів. Але тут треба бути уважними, і я завжди прошу колег, коли ми так кажемо, давати більше інфи:
🔸те, що впало - чи є там продакшен баг?
🔸обовʼязково казати у відсотках, скільки саме тестів упало;
🔸ідеально - додати, чому саме щось упало.

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

❌Бажано НЕ казати: «partially failed»

Буде краще сказати, наприклад, так:

▪️3% тестів упало
▪️2 продакшен баги
▪️або тести упали, бо зайшла така-то фіча і змінила такий-то сервіс.

Тому що в автоматизації дуже складно щось зрозуміти без цифр.
І проміжні статуси типу «частково», «трошки», «майже працює / не працює» - дуже оманливі. З цим треба бути обачними.

В автотестах і в регресії загалом є лише два стани:
🔹регресія пройшла;
🔹регресія не пройшла.

Варіант «трошки пройшла» - недоречний і незрозумілий.
Без цифр та конкретики такий статус бажано не вживати

🫰Пʼятниця, Київ. І розмови про AI

Колеги, добрий вечір!
Давала собі обіцянку не зникати з радарів, тому ділюся просто статусом - як є 🙏

**Київ зараз дуже сильно без світла. Приблизно по 16 годин на день без електрики. На вулиці –18. Води майже немає. Я навіть не знаю, як передати ці відчуття словами.

———

Тема, якою сьогодні хотіла з вами поділитися, - AI.
А саме: чим я користуюся, а чим - ні.

✔️Copilot
Для роботи - так. Зручний для автокомпліту коду. Користуюся.

✔️Rovo Dev (AI agent від Atlassian)
Чат для роботи з Jira. Якщо чесно, я ще не зрозуміла, наскільки це для мене комфортно.
Я дуже люблю фільтри та дашборди Jira - всю потрібну інформацію і так бачу там.
Намагаюся користуватися, але поки не бачу кейсів, де це реально суттєво покращило моє життя.

✔️ChatGPT
Звісно, є. Поправити орфографію, інколи “погрумити” думки - так.

✔️Google Gemini
Поки для мене те саме, що і ChatGPT.

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

✔️AI для творчості
Поки відчуття таке, що AI-творчість програє живим кадрам, голосу, людині.
Це цікаво подивитися один раз, але штучність швидко починає дратувати.
Тому я особисто не користуюся.
AI-пісні, вірші, кліпи - у моєму колі мало хто це любить.
Іноді трапляються прикольні AI-відео, але це радше виняток.
Сама не роблю.

✔️MCP AI Agent
Те, чим займаюся зараз.
З командою налаштовуємо агента, який генерує тест-кейси та пише автотести.
Поки все в стані розробки й експериментів.

AI-агент - це не просто чат і не «розумний пошук».
Це програма, яка може самостійно виконувати дії для досягнення заданої мети

Якщо дуже спростити:
▪️Chat / LLM → відповідає на питання
▪️AI-агент → отримує задачу і йде її робити

У агента зазвичай є:
✔️ціль (наприклад: згенерувати тест-кейси)
✔️контекст (код, документація, Jira, вимоги)
✔️інструменти (API, репозиторій, файли, CI)
✔️логіка дій (що зробити, в якій послідовності)
✔️памʼять (що вже робив і що з цього вийшло)

Приклад: «Згенеруй тест-кейси для нової фічі».
Агент може:
✔️прочитати опис у Jira
✔️подивитися схожі фічі в коді
✔️знайти edge cases
✔️згенерувати тест-кейси
✔️(інколи) одразу написати автотести

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

Отакі справи

По можливості буду ділитися апдейтами.

Гарних вихідних 🙏
Світла - і зовні, і всередині ❤️

Жарт)

**продовження

https://www.atlassian.com/software/rovo-dev

Забула сказати про code review.
Звісно, code review за допомогою AI.

Декілька років тому я пам’ятаю часи, коли в review було дуже багато субʼєктивних речей:
✔️по синтаксису
✔️по формулюванню
✔️де які helper-класи і в які папки
✔️що виносити в конфіг

Зараз всього цього майже немає. Ми користуємося в команді AI agent для code review (плюс pylinter).
Він виправляє і підсвічує прості семантичні помилки, орфографію, синтаксис, консистенсі коду.

Але ми НЕ прибрали те, що інша людина має поставити APPROVE на code review.
Мені здається, це правильно. Бо людина знає більше контексту всього проєкту.
Без того, що колега «подивився» / «заапрувив» код, ми не дозволяємо заливати в master.

Колеги, привіт!
Вчора була на тренінгу з налаштування MCP-агентів.

Хочу поділитися.

Тренер запитав мене:
уяви, що тобі потрібно написати певний код, у тебе є 3 хвилини. Як ти це зробиш швидко? Які варіанти?

Я, не замислюючись, «ляпнула»:

- ой-ой, де мій ChatGPT? 😅

І отримала відповідь:

- Катя, ти вже не в 2024. Забуваємо про ChatGPT для копіювання коду чи ТЗ кудись поза вашою IDE.

О божечки 🙂

Якось я зовсім пропустила, що в Google з’явилася можливість змінювати електронну адресу облікового запису.
Тепер можна нарешті поміняти не дуже вдалі імена, створені багато років тому 💃

І от питання: чи потрібно нам додавати якісь додаткові тести для аутентифікації в продукті у зв’язку з цією зміною?
Як думаєте?

https://support.google.com/accounts/answer/19870?hl=uk&co=GENIE.Platform%3DiOS&sjid=5157438649889467512-EU

2026 рік. Компанії, які впроваджують AI, обовʼязково задають собі це питання - «яка ефективність AI-агента?»

Скільки людської роботи він реально забрав + чи не зламав якість.

Наприклад, візьмемо AI для написання автотестів.

Компанії, які це впроваджують, дивляться, скільки людина робить реквестів і accept/reject. Для цього є спеціальні дашборди на рівні компанії, де видно статистику по кожній людині.

Тобто саме так - компанія, коли дає користуватися ліцензією, наприклад Cursor або Copilot, має доступ і дивиться, скільки саме реквестів ви робите.

Так міряється:
Speed × Quality × Cost

Тобто:
✔️Якщо в командах є люди, які НЕ використовують Copilot — у них обовʼязково запитають чому. Бо це видно.

✔️Якщо високий reject rate — це ідеально на ранніх етапах, бо це можливість зрозуміти, чому саме AI генерує «неправильний код», і прописати / покращити файли конфігурацій AI-агента. До таких людей ідуть за порадами і проханнями налаштувати файли з конфігурацією і додати більше деталей.

✔️Якщо високий accept rate — також непогано, людина, значить, пише хороші промти.

https://github.blog/changelog/2025-10-28-copilot-usage-metrics-dashboard-and-api-in-public-preview/

———

Що далі? Яка ж найбільша цінність QA в 2026?

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

✅Ну і звісно люди з хорошими софтскілами - бо роботу в командах ніхто не відміняв 🤭

———-

**Трохи випала з Telegram, бо збираюся на воркшоп у Тель-Авів наступного тижня. Готуюся.

Потім, коли повернуся, поділюся думками.

▶️На скільки глибоко QA треба знати Kubernetes?

Друзі, привіт! Хочу поділитися своїм баченням, що треба вміти:

✔️Вміти логінитися на потрібний кластер.
✔️Розуміти, що таке pod. Вміти робити pod start/stop/delete.
✔️Розуміти, що таке namespaces.
✔️Вміти дивитися logs (наприклад логи серверу)
✔️Виконати щось у shell (наприклад подивитися структуру файлів або запустити тести)
✔️Подивитися, який Docker image використовується всередині pod.

Все, цього повністю достатньо.

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

https://lenshq.io/

Колеги, привіт🙏 Нарешті дійшла до телеграму розповісти вам, як пройшли мої тижні
Я їздила на воркшоп в Ізраїль. Вперше побачила колег і команду наживо — це звісно зовсім інші відчуття, ніж онлайн.
✔️ Із новенького для мене - робили цікаву вправу в парах на комунікацію: одна людина має завʼязані очі, а інша словами керує, що потрібно зробити (ми складали пташку).
Тобто дівчинка керувала мною, а я із зав’язаними очима збирала пташеня з кольорових паличок. (Це HR придумали таку гру 😀)
✔️ Звісно, дуууууже багато говорили про AI-агентів.
✔️ Про взаємодію між людьми і про те «як нам усім триматися..»
✔️ І я вперше за останні 5 років побувала в офісі — так відвикла від цього. Це звісно зовсім інше відчуття, ніж коли постійно працюєш з дому

** не можу вам нічого новенького розповісти про АІ агенти, бо ще сама не розібралася глибоко🙏

Сьогодні буду на QA івенті в Києві про General QA.
Якщо хтось також буде - підходьте, буду рада побачитися.
Завтра поділюся враженнями і думками після зустрічі.
https://eventmate.app/events/share/obrio-tech-track-qa?locale=en

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

Навіть якщо у вас складний сетап.
Навіть якщо треба підняти k8s, docker, VPN і ще пів інфраструктури.

Бо дуже часто я бачу ситуацію, коли тест багато разів перезапускають на CI.

Тоді питаю:

“А локально проходить?”

—
чую:

“Ні, локально не вийшло запустити”.

Ах..😞
Коли я це бачу перезапуск тестів на CI «всліпу», в надії що фікс спрацює…
На мій погляд - це просто втрата часу.

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

Хороша автоматизація - це та, яку інженер може зрозуміти, відтворити і перевірити у себе на машині.

❤️Вчора у Kooperative (Київ) говорили про перехід manual QA → general QA на прикладі досвіду компанії Obrio

https://obrio.co/

1️⃣Загальний перехід у них зайняв 8 місяців.
2️⃣Команда рахувала ROI, щоб пояснити бізнесу: що саме компанія отримає від цього переходу.
3️⃣Щоб люди краще вивчили програмування, їх цілеспрямовано просили НЕ користуватися AI під час навчання.
4️⃣Однією з труднощів стало додаткове навантаження на automation QA, які в цей період активно менторили manual QA.

Що вийшло в результаті:
4️⃣Більшість змогли освоїти базу automation framework і почати писати прості тести.
5️⃣Архітектура і складні рішення залишилися на automation QA команді.

6️⃣Ще обговорювали, чому позиція Junior QA Automation зустрічається рідко.(Одна з причин — складно бути junior і при цьому писати хороші тести та розуміти, що саме потрібно тестувати.)

7️⃣З гарячого 😅: Саша Хотемськмй дуже активно пушив ідею перейменувати всіх AQA у Obrio у Staff QA.

А саааме найгарячіше питання було:
чи підняли зарплату людям, які перейшли в general QA? 🤓
(здається, так 🫢)

8️⃣Також трохи холіварили про різницю між
Staff QA / Principal QA / QA Lead.
І зійшлися на тому, що градація дуже залежить від компанії, структури команд і навіть країни — універсального стандарту немає.

Загалом зустріч пройшла щиро і дуже тепло.
Мені справді сподобалося.
——————————————-
Від себе додам:

Колись я також проходила цей шлях у своїх командах - навчала manual QA автоматизації.

Це було давно.
**Останні роки в моїх командах ми беремо одразу SDET / automation QA, тому навіть термін general QA у нас не використовувався - їх просто не було.

Але з того, що памʼятаю колись давно коли я робила такий перехід і навчання👵👵😅:
▪️Не всі люди хотіли вчити automation - а тягнути когось «було боляче».
▪️Деякі QA, які освоїли automation, але не отримали суттєвого підвищення зарплати, переходили в інші компанії вже як automation QA.
▪️Дуже багато часу займало code review (тоді ще не було AI review).
▪️Були дійсно люди, які дуже швидко підхопили всі знання і досить легко увійшли в автоматизацію/і все те що треба знати. Вийшло круто.

В будь-якому разі це дуже цікавий досвід трансформації команд🫰

Ще трохи про вівторок.

**Була на панельній дискусії від Obrio.
Вони створюють продукти, дотичні до додатків для духовних порад та астрології.

Найбільше «любові» зібрало питання із залу:

“Чи будуєте ви натальні карти кандидатам на співбесіді, щоб зрозуміти чи підійде людина в команду?”

Відповідь була: ні. Але… можливо пізніше 😀😂

🐤Коли в команді є авто-тести — чи треба, щоб була людина, яка «черговий» і дивиться за ними?

**Duty Regression Owner. Чи треба він?

Дуже сильно залежить від того, як налаштований CI.

Є 2 популярні сценарії:

1️⃣ Сильний Continuous Integration/ Delivery

Білд не збереться / PR не замерджиться, якщо тести падають.
Часто в таких командах черговий НЕ потрібен. Бо процес побудований так, що якщо десь падають тести - команда це одразу бачить. Всі «заблоковані» і одразу чинять (QA / SDET / Dev - whoever).

2️⃣ Тести запускаються, але нічого реально не блочать.

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

В таких випадках

черговий потрібен

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

Особисто я більше «люблю» перший варіант.
У мене був досвід, коли БЕЗ чергових працювала велика команда. Навіть коли в R&D було близько 200 людей, нам не потрібен був черговий. І всім було комфортно.

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

Всі проєкти унікальні. Немає одного рецепту.

Але головна думка, яку хотіла донести:

✔️ червоні автотести - це відповідальність ВСІЄЇ команди.

Основні фактори (від чого залежить, чи потрібен черговий):

1️⃣ Розмір тестового набору
2️⃣ Кількість pipeline запусків
3️⃣ Стабільність тестів (flaky чи ні)
4️⃣ Кількість команд
5️⃣ Чи блокує regression реліз

А у вас є черговий?

🐤Ніколи такого не було і от знову

2 тижні до релізу, команда в повній запарі.
Безкінечні баги і фікси.
При цьому у нас досить багато автотестів.

І от з сотні тестів 1 тест інколи падав:
✔️1 раз на 3–5 ранiв.
✔️Всього 1 тест із сотні.
✔️З помилкою 400 Bad Request.
✔️Раз падає. Потім не падає.
✔️Ми цю помилку бачили ще місяць тому.

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

————

І от реліз відклався на пару днів, купа людей в запарі - бо з’явилася проблема на бекенді, де при певних обставинах 400 Bad Request…

Ми зібралися всією командою.
Зробили брейнштормінг.
Знайшли багу і, о боже:
Звісно, це була та сама бага, яку бачив тест….

Висновок:
Довіряти автотестам, бути більш уважною.
Це проходила купу разів🐤👩‍💻🫰

🚀Хто відповідальний за падаючі автотести?

Гарне питання, але сильно залежить від команди і структури:

✔️Може бути, що відповідальний розробник, який зламав тести - він і фіксить (у мене так було на минулій роботі). Але у нас був сильний CI/CD і лише один пайплайн, де і збирався білд, і паралельно ранилися всі тести. Тобто місце, де ранилися ВСІ тести, було одне. Не було пайплайнів з фіче-флагами, різних конфігурацій і т.д.
І так: у нас розробники також писали e2e авто-тести 🕺
✔️Може бути, що відповідальний черговий QA automation - він дивиться, що де падає, і фіксить по ходу.
✔️Може бути, що черговий QA просто заводить баги і розкидує їх по людям, які будуть «розбиратися».
✔️Може бути, що чергового немає, але всі поділені на зони відповідальності, і кожен фіксить та розбирається зі своїм.

———————-
Можу сказати, як у нас зараз:
1️⃣У нас немає manual/general — всі automation QA.
2️⃣Ми тримаємо чергового, який дивиться за тестами.
Черговий - ми називаємо його «Duty Regression Owner”
У нас в QA є ротація кожен спринт

ВАЖЛИВО: Ця людина НЕ заводить сама тікети.

3️⃣Ми налаштували AI-агента - він проходиться по помилках з автотестів в усіх pipeline і створює тікети по нових еррорах.
AI не знає, кому краще заасайнити тікет, тому асайн на когось ми НЕ робимо через AI.
Duty regression owner сам асайнить.
4️⃣Також AI робить нам summary-репорт по тестах кожен день. Але цей репорт запускає на створення людина: спочатку перевіряє очима, і якщо все ок -> репорт летить у чат команди (бо AI може інколи написати щось не зовсім правильно).
5️⃣Кожен день покращуємо і фіксимо AI для репортів.
6️⃣Головна цінність Duty regression owner -> зрозуміти, тест падає через баг чи тому що тест зламаний.
Це AI робить погано, тому у нас це робить людина.
7️⃣Також із простого: у нас є під кожну фічу канал у Slack, куди прилітає репорт після кожного рану. Там ми обговорюємо, якщо щось падає. Ну і бачимо статус, не відкриваючи CI.
8️⃣А ще ми в автотестах використовуємо tag annotation - над кожним тестом додаємо ім’я людини, яка писала цей тест. Тоді легко зрозуміти, кому заасайнити.
9️⃣Бувають випадки, коли тест ми вішаємо не на людину, а на команду. Тобто це означає, що будь-яка людина з цієї команди, яка має capacity, може його взяти в роботу.Але формально кожен тест має owner’а - це людина, яка його створила. І саме ця людина його фіксить, якщо він зламаний, бо вона краще знає логіку (або людина з команди цієї людини, що писала тест).
🔟 Буває, що всі тести падають, бо впав прекондішн. Тоді цей один тікет з помилкою, яка ламає всі тести, фіксить той, хто краще знає, як швидко це пофіксити