Робота QA ліда: не про кількість тестівЧасто QA ліда оцінюють по тому, скільки він тестує руками і скільки багів знаходить особисто. Але це не той фокус. Правильне питання інше: чи потрібен я команді, щоб вона випустила якісний реліз? Чим правильніша відповідь, тим більше часу залишається на все інше - в тому числі на тестування руками, коли воно справді має сенс.Час з'являється не від дисципліни, а від автономії. Якщо календар QA ліда постійно забитий - це не показник завантаженості, а симптом. Значить, дрібні рішення про те, що і як тестувати, досі не делеговані команді, і все впирається в нього. Коли тестувальники самі можуть визначити критичні зони, розставити пріоритети і сказати "готово / не готово" без узгодження нагору, з'являється простір для іншого.Тестування руками - це не рутина, яку треба здихатися. Це спосіб не втратити зв'язок з реальністю. Раз на якийсь час зануритись у конкретний фліт і пройти його самому цінніше, ніж будь-який звіт про метрики. Так видно, де тест-кейси застаріли, де команда звикла закривати очі на нестабільний функціонал, де процес існує лише на папері. Свіжий погляд плюс широкий контекст - комбінація, яку має лід і не має тестувальник, зайнятий у рутині щодня.Тут є дві пастки.Перша - тягнути перевірку на собі, замість того щоб побудувати процес (критерії готовності, автотести там, де вони справді економлять час), який дозволяє команді самій відловлювати проблеми задовго до релізу.Друга - стати критичним шляхом. Взяти тестування задачі з дедлайном і самому перетворитися на бутилкове горлечко, бо день ліда складається із зустрічей і переривань, а не з довгих блоків фокусу, як у тестувальника.І ще важливо: тестування - лише один канал фідбеку. Поряд з ним є ретро, аналіз багів, що дійшли до продакшену, покриття, реакція команди на інциденти. Це теж інформація про стан якості, і часто вона важливіша, ніж особисто знайдений баг.Підсумок простий: мета не в тому, щоб QA лід перевірив кожен реліз власноруч. Мета - команда, яка тестує настільки добре, що ліду вона майже не потрібна для цього, а в нього залишається час зануритись у продукт саме тоді, коли це дає найбільше розуміння.
📈 Зі зростанням кількості IoT- і MilTech-проєктів компанії активніше шукають QA-фахівців, які вміють тестувати не лише софт, а й hardware.Побудуйте embedded QA workflow: від тестування пристроїв, роботи з обладнанням і протоколами та автоматизації тестів на Python — до аналізу результатів та використання сучасних інструментів, — на курсі «Embedded QA Engineer».Після 20 занять ви зможете:⚙️ писати тести на Python і pytest⚙️ працювати з UART, GPIO, I2C, SPI, BLE, Wi-Fi та MQTT⚙️ створювати HIL-стенди для automated hardware testing⚙️ запускати hardware-тести в CI/CD⚙️ дебажити firmware, hardware та network-проблеми⚙️ зібрати власний embedded QA toolkitУ фіналі — презентуєте свою розробку та отримаєте технічне ревʼю від лектора й фідбек щодо презентації від HR-ів та рекрутерів.Лектор: Богдан Горбанич — Senior Embedded QA Engineer у SQUAD, який має понад 7 років досвіду в QA Engineering: тестував software та embedded-рішення для hardware-продуктів.Старт: 28 липняДеталі, програма та реєстрація ⬅️
Документація, статті, курси, відео, AI-інструменти, нові технології — інформація накопичується швидше, ніж ми встигаємо її осмислити. Тому сьогодні головний виклик не «де знайти інформацію?», а «як навчитися працювати з нею ефективно?»Саме для цього Certified Unicorns створили воркшоп Smart Learning with AI tools, який проведе Олександр Романов, Senior Software Engineer in Test із 14+ роками досвіду в IT. За останні роки Олександр не просто дослідив десятки підходів до навчання та роботи мозку, а й перевірив їх на практиці: від підготовки до IELTS за місяць до вивчення нової мови та постійного освоєння нових технологій та навичок.На воркшопі ти дізнаєшся:🧠 як працюють увага, пам'ять і процес навчання;📚 які техніки допомагають не просто споживати інформацію, а справді її засвоювати;🤖 як використовувати AI для аналізу, структурування та глибокого розуміння нових тем;⚙️ як швидше вивчати нові технології, продукти, документацію, мови чи будь-які інші дисципліни.Після нього ти зможеш не лише швидше навчатися, а й створити власну систему, яка допоможе ефективно опановувати будь-які нові знання.📅 Старт — 6 липня.Якщо ти регулярно навчаєшся, але хочеш витрачати на це менше часу й отримувати кращий результат — велкам.📌 ДЕТАЛІ ТА РЕЄСТРАЦІЯ
FitBit Air: купив за $99, продав через 6 днів. Чесний огляд від людини, яка серйозно тренується.КонтекстЯ активно тренуюсь і маю усталений сетап: нагрудний пульсометр, велокомп'ютер, Garmin Fenix 7X і платформа intervals.icu для аналізу тренувань. Єдина незручність – спати з Garmin не дуже комфортно. Коли вийшов FitBit Air, ідея трекера для сну і відновлення мені сподобалась. Замовив 12 травня на Amazon за акційною ціною $99 (+ силіконовий ремінець у комплекті), отримав в Україні через NP Shopping 6 червня.Проблема 1. Підключення.З коробки браслет не синхронізувався з телефоном через Bluetooth. Не допомагала навіть заміна GPS-координат на US. Рішення знайшов у відгуках на Amazon: треба вручну виставити таймзону Europe/Tallinn у Google Health. Після цього запрацювало. Очевидний баг застосунку.Проблема 2. HRV.Носив FitBit Air на правій руці, Garmin – на лівій. Три ночі паралельних замірів HRV дали таке:Garmin 36ms, 38ms, 41msFitBit 22 ms, 29 ms, 27 msFitBit систематично занижує HRV майже удвічі. Це підтверджується масою скарг на Reddit. Як наслідок, Daily Readiness Score виявився штучно низьким: там, де Garmin показував 86–90, FitBit давав 36.Трекінг сну – несподівано непоганийТут FitBit здивував позитивно. Коли я прокидався, відверто не відпочивши, Garmin видавав Sleep Score 94, а FitBit – 86. За суб'єктивними відчуттями FitBit за 6 ночей був ближчим до реальності.Автовизначення активностей також приємно вразило: велостанок розпізнав як Stationary Bike, ранкові прогулянки до школи – як Morning Walk. Garmin так не вміє.Точність пульсу під час тренуваньПротестував на двох заняттях з нагрудним ременем як еталоном:Z1 відновлення (60 хв): MAE 1.6 bpm, кореляція 0.85Інтервали МСК 40/20 (23 хв): MAE 2.2 bpm, кореляція 0.96Загальне навантаження і зони пульсу – надійно. Стабільний пульс – точність ±2 bpm. Але в перші 30–60 секунд різкого інтервалу похибка сягала 27 bpm. Для більшості тренувань прийнятно, для серйозного інтервального аналізу – знадобиться нагрудний ремінь.Проблема 3. sample rate і інтеграції.У intervals.icu з'явилося попередження: "This activity has been recorded with approximately 6 seconds per data point. Please disable smart recording." На Garmin це вирішується перемиканням на 1-секундний семплінг. У FitBit такого налаштування немає взагалі. Детальний аналіз пульсу через Strava або intervals.icu – недоступний.Остання крапля: Google Health не має публічного API. Wellness-дані (сон, HRV, відновлення) не можна синхронізувати з intervals.icu. Дані тренувань ще можуть потрапити в Strava, але не більше. У Garmin Connect з цим усе гаразд.Google випустив оновлення під час мого тесту, але виправили лише косметику в застосунку.Підсумки✅ Трекінг сну – точніший за Garmin за суб'єктивними відчуттями✅ Автовизначення активностей – вражає✅ Точність пульсу на стабільних тренуваннях – прийнятна❌ HRV занижує систематично і суттєво❌ Sample rate 6 сек – детальний аналіз неможливий❌ Немає API → дані заблоковані в Google HealthДля кого підійде: людям, яким потрібен простий трекер сну і загального руху без глибокого аналізу даних.Для кого не підійде: всім, хто використовує intervals.icu, Strava або Training Peaks і хоче повноцінно аналізувати відновлення і тренувальне навантаження.Через 6 днів продав у стані нового девайсу за 3600 грн.
🦎 5 червня на безкоштовному вебінарі "Agile навички тестувальника: сертифікація 2026 vs наболіла реальність"від Certified Unicorns відбудеться обговорення одного з найцікавіших оновлень ISTQB цього року — сертифікації ISTQB Advanced Level Agile Tester 2.0Зіркові спікери:🌟Олександра Ковальова — BUG-иня ISTQB — просмажить нові терміни і неочікувані зміни🌟Артем Биковець — Agile-практик з тестувальницьким бекграундом — зматчить це з реальними потребами команд на сьогодніПро що піде мова на зустрічі:🧪Чому Agile виснажує тестувальників🧪Навіщо тестувальникам переходити до продуктового мислення🧪Нові слова в Agile техніках 2026-го року — mob testing, vibe testing, holistic testing, test smell, tissue testers та інші звірів🧪як AI проліз в офіційні Agile техніки тестування🧪Чому на ринку хардові навички більше не гарантують успіху🧪Огляд новой сертифікації Agile testing 2.0 — що там має сенс, а що маркетингКому точно буде цікаво:☑️ QA, які хочуть навчитися відрізняти Agile від хаосу та “вічного пожежогасіння”☑️ тестувальникам, які хочуть розібратися, як змінюється Agile Testing у 2026 році☑️ QA Lead’ам, які відповідають за процеси в Agile-середовищі☑️ автоматизаторам, які хочуть більшого впливу та експертності в Agile-процесах☑️ всім, хто любить накидать на вентилятор Agile :)💪 Вебінар безкоштовний, але ми будемо вдячні за ваші донати на дружню банку збору 10 000 000 грн від DOU для корпусу «Хартія», який обороняє Куп’янськ на Харківщині. Кожен донат у 300 грн — ваша можливість виграти цінні призи від організаторів і партнерів збору. Детальніше тут.🔗Посилання на банку зборуhttps://send.monobank.ua/jar/2XDFyC3WZc📌ДЕТАЛІ ТА РЕЄСТРАЦІЯ
Друзі, більшість із вас знає, що 11 травня ми втратили колегу, друга, захисника – Геннадія Міщевського.Він автор одного з найпопулярніших топіків на DOU – «Тестування. Фундаментальна теорія». У 2023 році став переможцем першої Премії DOU в номінації «Найбільший внесок у розвиток спільноти DOU».Від початку повномасштабного вторгнення активно волонтерив для спільноти SocialDroneUA. У 2024 році долучився до війська у складі батальйону «Братство» ГУР МО України. Загинув під час виконання бойового завдання на Запоріжжі.У Гени залишилися двоє дітей і дружина. Підтримати його родину можна тут:🔗Посилання на банкуhttps://send.monobank.ua/jar/ADXENaogDC💳Номер картки банки4874 1000 3860 3463 Міщевський ГеннадійПрощання з Героєм відбудеться завтра, 20 травня, в Києві. 12:00 – відспівування в Михайлівському Золотоверхому монастирі. 12:50–13:00 – піша хода від Михайлівського до Майдану Незалежності. 13:50–14:00 – виїзд з Майдану Незалежності до кладовища, с. Крюківщина, вул. Каштанова, 1. Орієнтовно поховання відбудеться о 14.40–15.00.Якщо ви знали Гену, його родина була б рада, щоб ви долучилися й поділилися спогадами про нього. Після поховання відбудеться поминальний обід. Напишіть Олександрі Ковальовій (@molly4air) в особисті, якщо плануєте залишитися на прощальний обід.🕯Світла пам'ять тобі, Гено.
🤖 ШІ та робота QA: що показує нове дослідження AnthropicAnthropic опублікувала дослідження "Labor market impacts of AI", яке вимірює не теоретичну загрозу, а реальну експозицію до ШІ прямо зараз.Ключові цифри: • Програмісти: 74,5% спостережуваної експозиції • Служба підтримки клієнтів: 70,1% • Оператори введення даних: 67,1% • Для комп'ютерних спеціалістів: ШІ теоретично здатен виконувати 94% завдань, але реально виконує лише 33%Що це означає для QA?Тестування входить у ту зону, де розрив між можливістю та реальним впровадженням величезний. ШІ вже скорочує час на рутинні тест-кейси, але критичний аналіз, планування стратегії та розуміння бізнес-контексту – це те, що QA повинні укріплювати прямо зараз.Несподівана деталь:Найбільше під загрозою – не низькокваліфіковані робітники. Це люди з ступенямимагістра, вищою освітою, які заробляють на 47% більше за середній рівень.Конвеєр молодих фахівців вже розривається: 14% падіння рівня найму для людей 22-25років у високоекспонованих професіях після запуску ChatGPT.Що робити?Розвивай soft skills, архітектурне мислення, розуміння продукту. Це то, що ШІ поки що не замінює.https://www.anthropic.com/research/labor-market-impacts
Цікава статейка про Layofs через AI🧠 The AI Layoff Trap (2026) — самаріГоловна ідея:Ринок може “сам себе зламати”, якщо компанії занадто швидко замінюють людей AI. Навіть розуміючи ризики, бізнес все одно продовжує автоматизацію — через конкуренцію.1. ⚠️ Проблема: AI знижує попит в економіціПрацівники = споживачіЯкщо їх масово замінюють → падають доходи → падає попит на товариУ крайній ситуації:компанії стають дуже продуктивними, але нікому купувати їх продукцію2. 🏁 Чому компанії не зупиняються?Навіть раціональні фірми не можуть “натиснути гальма”, бо:є конкуренціяякщо ти не автоматизуєш — це зробить конкурентформується “гонка автоматизації” (arms race)👉 У результаті всі діють раціонально індивідуально, але система приходить до поганого результату глобально.3. 📉 Результат: надлишкові звільненняЗвільняють більше людей, ніж оптимально для економікиСтраждають:працівники (втрата доходу)компанії (через падіння попиту)4. 🚫 Чому стандартні рішення не працюютьАвтори показують, що це не виправляється через:підвищення зарплатнові робочі місця (reskilling)UBIподатки на капіталучасть працівників у власностіпереговори (Coase)👉 Всі ці механізми не усувають проблему конкуренції між фірмами5. 💡 Єдине ефективне рішенняАвтори пропонують:➡️ Податок на автоматизацію (Pigouvian tax)Ідея:зробити автоматизацію “трошки дорожчою”щоб врахувати шкоду для економіки (втрата попиту)🧩 ВисновокAI може створити економічну пастку:продуктивність росте → попит падає → система деградуєПроблема не в технології, а в стимулах конкуренціїПотрібно регулювати сам процес автоматизації, а не лише її наслідки Для староверов лінк на статтю https://arxiv.org/html/2603.20617v1
⚙️ ISTQB Advanced Test Automation Engineer 2.0 — новий курс від Certified Unicorns — стартує 9 квітня!🤓 Під час навчання ви:✅ розберетеся, як автоматизація працює в різних SDLC, її переваги та обмеження, і навчитеся будувати pre-sale стратегію, аргументовано демонструючи цінність автоматизації клієнтам;✅ навчитеся аналізувати систему, бібліотеки та фреймворки й доносити результати аналізу технічним і нетехнічним стейкхолдерам;✅ заглибитеся в технічну частину: побудову архітектури фреймворку, принципи написання коду, архітектурні патерни та дизайн із GoF — просто й прикладно;✅ розберете технічні та нетехнічні ризики TA solution, навчитеся структурувати тести, організовувати логування, оновлення та підтримку фреймворків у довгостроковій перспективі;✅ детально пройдете пайплайни автотестів: типи, етапи та практичну реалізацію на прикладах GitHub Actions і GitLab Pipelines;✅ дізнаєтеся, які метрики варто збирати з автоматизації, як їх презентувати та використовувати для покращення процесів тестування;✅ розглянете практики перевірки інфраструктури та підходи до підтримки test automation solution;✅ зрозумієте, як масштабувати та розвивати фреймворк: ШІ, метрики, дашборди, аналітика, код і процеси — у контексті реальної роботи.🦄 А ще на вас чекають tips&tricks щодо організаційних моментів самої сертифікації та стратегії її успішного складання.🟠Організаційні деталі📆 Старт: 9 квітня 2026 року⌛️Тривалість: 2 місяці🗓 Розклад: понеділок та четвер, 18:30-20:30 (Kyiv time).🎥 Формат: прямі трансляції та відеозаписи. Всі заняття записуються та доступні учасникам в будь-який час.🧑🏫 Q&A cесії з тренером: додаткова можливість для розбору ваших запитань.📌ДЕТАЛІ ТА РЕЕЄСТРАЦІЯ
Одна фіча. 15 циклів «деплой → фікс» за один тиждень.У Kindgeek змінили підхід: QA «після» → QA «паралельно».QA жодного разу не робив ретест. Жодного.Як це виглядає в більшості команд:Розробник релізить → QA 30-60 хв готує тестові дані → знаходить баг → створює тікет → розробник бере через кілька годин → «можеш відтворити?» → Slack-переписка → фікс → і по колу.Помножте на 15 - це до 15 годин роботи QA. Два повних робочих дні. На одну фічу.Це не тестування. Це затримка.QA пише автотести разом із розробкою. Як тільки відбувається деплой - тести запускаються автоматично.У Slack одразу прилітає звіт:- всі кроки- точні тестові дані- expected vs actual- логиРозробник відкриває → знаходить проблему → фіксить.Без тікетів. Без «пінг-понгу». Без очікування.Результат:- фіча за 1 тиждень замість 2–3- релізи: з разу на 2–3 місяці → щотижня- баги: 15 хв замість пів дняAutomation-first - це не про QA. Це про контроль швидкості доставки.А як у вас: тестуєте після релізу чи ще до того, як код з’явився?https://kindgeek.com/blog/post/test-automation-strategy
TGLIST.COM.UA
