Playwright продовжує рухатись в максимальну інтеграцію з AI агентами.Якщо ви будуєте складні системи автоматизації, експериментуєте з AI-агентами або хочете мати ідеальний візуальний контроль над тим, що відбувається під капотом під час прогону E2E-тестів то цей реліз точно вартий уваги.https://playwright.dev/docs/release-notes#version-159А це вам AI вижимка1. Нове Screencast API (page.screencast)Playwright представив абсолютно новий уніфікований інтерфейс для захоплення контенту сторінки. Він набагато гнучкіший за старий параметр recordVideo.Що всередині: Точний контроль запису відео (start() / stop()), візуальні оверлеї, захоплення кадрів у реальному часі та візуальні анотації дій."Agentic video receipts" (Відео-звіти від ШІ): Якщо ви використовуєте AI-агентів для тестування або скрапінгу, після завершення завдання агент може записати відео-доказ своєї роботи. Завдяки методу showActions(), на відео будуть підсвічені всі елементи, з якими взаємодіяв агент, та відображені назви дій (куди клікнув, що ввів).Точний запис: Запис відео тепер можна вмикати та вимикати прямо під час тесту (наприклад, знімати лише момент оплати, а не весь 10-хвилинний флоу).
2. Метод browser.bind() та Підтримка MCPРаніше браузер був "прив'язаний" до одного процесу. Тепер з'явився метод browser.bind(), який дозволяє запустити браузер і "розшарити" його через WebSocket або іменований канал (named pipe) для інших клієнтів.Що це дає: Тепер до одного запущеного браузера можуть підключатися кілька клієнтів одночасно через chromium.connect(endpoint).Ви можете підключити свій сервер MCP (Model Context Protocol) напряму до працюючого браузера (@playwright/mcp).Можна підключитися через нову CLI-утиліту прямо з вашого улюбленого AI-помічника (наприклад, Claude або Cursor).
3. Дашборд та ObservabilityЯкщо ваші тести або скрапери працюють у бекграунді (або ними керує ШІ), тепер за ними набагато простіше стежити.Що нового: Команда playwright-cli show відкриває візуальний Дашборд, де списком відображаються всі запущені браузери (які були "забінджені").и можете в реальному часі бачити, що робить ваш код чи AI-агент у фоновому браузері. З дашборда можна в один клік "увійти" в сесію для ручного втручання або відкрити DevTools для сторінки, якою зараз керує автоматизація. (Щоб побачити всі звичайні тести в дашборді, достатньо додати змінну PLAYWRIGHT_DASHBOARD=1). 4. Інші корисні API дрібниціrequest.existingResponse(): дозволяє отримати об'єкт відповіді без необхідності чекати на неї (зручно для синхронних перевірок).tracing.start({ live: true }): нова опція для оновлення трейсів (Trace Viewer) у реальному часі, а не лише після завершення тесту.browserContext.debugger: тепер ви маєте програмний контроль над дебагером Playwright.
FOMO vs. FOWT: Чи варто бігти за кожним АІ-потягом? 🧠🚂Спостерігаю зараз цікавий феномен, який дуже нагадує класичну пастку трансформацій, тільки тепер у площині Штучного Інтелекту. Назвемо це битвою: FOMO (Fear Of Missing Out) проти FOWT* (Fear Of Wasting Time) (*цікаво чи існує такий термін, бо я певен, що сам його щойно вигадав 🤪 …).🤯 Раунд 1: Хайп і FOMOЗараз усі стрічки забиті: "AI-агенти за 5 хвилин", "Як впровадити Claude Cowork у вашу рутину», "Мануал по Claws для початківців". Здається, якщо ти сьогодні не проходиш новий курс по ШІ - завтра ти вже динозавр.Це класичне FOMO. Страх пропустити "ту саму срібну кулю", яка вирішить усі проблеми.🔄 Але давайте згадаємо...Приблизно рік тому всі божеволіли від "Курсів по правильному написанню промптів" та «автоматизації на n8n». Де ці знання зараз? Вони або стали базовою гігієною, або застаріли, бо самі інструменти еволюціонували і стали розумнішими.Швидкість змін шалена. Те, що вчора було проривом, сьогодні - legacy.⏱️ Раунд 2: Прагматизм і FOWT*І тут вмикається FOWT - страх даремно витраченого часу.Як Лідер трансформацій, я дивлюсь на це системно. Проблема не в тому, щоб вивчити новий інструмент. Проблема в тому, навіщо ми його вчимо і що це змінить у нашому потоці цінності (value stream).Витратити місяці на глибоке вивчення конкретного AI-інструмента, який через півроку замінять вбудованим функціоналом, - це класичне Муда (втрати) у Lean.💡 висновок і порада лідерам:Ми ж з вами не про інструменти, як основу, а про структури, системи й мислення. ШІ - це надпотужний акселератор, але він не замінить здоровий глузд і правильний оргдизайн. Як там було? 🤔 «Agile AI has no Brain. Please! Use your own…»Не піддавайтеся FOMO. Балансуйте з FOWT.1. Не вчіть "інструмент ради інструменту". Вивчайте принципи роботи ШІ та його можливості для автоматизації рутини.2. Тестуйте швидко, впроваджуйте обережно. (Inspect and Adapt(с)). Створіть пілот, подивіться, чи зросла швидкість, ефективність і тільки тоді масштабуйтесь й вкладайте більше часу.3. Головна навичка - адаптивність, а не знання claude-blabla. Вчіться й будьте готові постійно вчитись!Інструменти змінюються щомісяця. Принципи ефективної роботи та Лідерства залишаються.А як у вас? Більше FOMO чи FOWT, коли бачите черговий "революційний" AI-тул? Пишіть у коментарях 👇#Agile #Leadership #Transformation #AI #Mindset #FOMO #FOWT
Хто в Києві, тут 10 березня о 18:30 для вас офлайн івент готують по тестуванню. Сходіть,, випийте чаю, послухайте розумних людей, поспілкуйтесь, проведіть гарно час в гарній компанії.Вхід за донат від 500 грн на Благодійний Фонд «Солом'янські котики»➡️ Реєстрація тут https://eventmate.app/events/share/obrio-tech-track-qa(після реєстрації редірект в телеграм і вже в ньому лінка на донат)Все добре коли люди збираються разом, ще й збирають гроші на благодійність. В форматі панельної дискусії говоритимемо про «QA Evolution: навіщо бізнесу General QA та що це змінює для Automation QA»🎤Спікери:📎 Анастасія Кононенко — QA Engineer, OBRIO7 років в automation. Будує та масштабує фреймворки для API, UI та Mobile, інтегрує тестування в CI/CD та розвиває культуру automation як частину інженерної стратегії📎 Віталій Сенченко — QA Lead, OBRIO10+ років у QA, 7 — у лідерстві. Трансформує manual-команди в General QA, масштабує автоматизацію та будує процеси з фокусом на time-to-market і бізнес-результат📎 Антон Говорушкін — Head of QA, OBRIO (модератор)10 років у QA. Будує команди на основі прозорих quality-метрик та максимізує ROI автоматизації. Прихильник General QA-підходу
У багатьох командах test automation починається з правильних намірів — і закінчується фреймворком, який складно підтримувати, масштабувати та інтегрувати в delivery процес.Якщо вам знайомі ці болі:▪️ фреймворк працював добре на 50 тестах, але «посипався» на 500+▪️ підтримка автоматизації займає більше часу, ніж її розвиток▪️ кожна зміна в продукті тягне за собою масові рефакторинги тестів▪️ automation існує окремо від архітектури продукту▪️ складно масштабувати підхід на кілька команд або проєктів▪️ немає розуміння, де закінчується «швидке рішення», а де має починатися системна архітектура➡️ — значить проблема не в окремих тестах, а в архітектурі автоматизації.На вебінарі “Page Object не врятує: архітектура фреймворку, яка реально масштабується” ми будемо говорити про реальні інженерні причини більшості болей у test automation:✅ як будувати архітектуру автоматизації з урахуванням швидких перемог, масштабування та pragmatic підходу✅ чи потрібні core teams для розвитку фреймворків і де межа між порядком та бюрократією✅ чому створення фреймворку й написання тестів ≠ побудова automation ecosystem✅ що таке тестабіліті системи та як вона безпосередньо впливає на стабільність тестів✅ чи варто застосовувати SOLID та GoF патерни в automation codebase✅ чому capture/playback підхід періодично “повертається” і які ризики він несеЦей вебінар буде корисним для:✔️ Automation Engineers, які стикаються з технічним боргом✔️ Test Leads, які масштабують автоматизацію✔️ команд, де automation вже перестала бути “швидким рішенням”Мета — не ще один фреймворк, а розуміння, як будувати стабільну, підтримувану та масштабовану архітектуру автоматизації. Якщо хочете перейти від “написання тестів” до інженерного підходу в test automation — велкам на вебінар.Як це буде🗓 Коли: 18 лютого о 18:00 за Києвом📌Де: онлайн🚩Участь безкоштовна, але реєстрація обов'язковаРеєструйтеся самі та запрошуйте колег, щоб обговорити інсайти та долучитися до дискусії!▶️ДЕТАЛІ ТА РЕЄСТРАЦІЯ
Цікава ситуація виникла під постом Інни Осінної про те, скільки повинна тривати лекція: [https://t.me/qa_innaosinna/576].Якщо глянути на голосування і коментарі людей, які проходять курси, то більшість за те, щоб лекції були короткими. Так навчатись легше і завжди можна знайти на це час. Але якщо почитати коментарі людей, які викладають і стали майстрами своєї справи, то там картина діаметрально протилежна.Рома Марінський пише:Важко щось технічно складне впихнути в 10 хвилин відос, чи навіть у 30. Є певні речі або доповнення, що можна дозаписати на 20-50 хвилин. Але фактично тему розкриваю 6-12 годин. Основна практика - година-півтори, допоміжні - ще години 4-6, а ПМП сесії - ще по 2 години на тиждень.
Саша Хотемський:Готуйтесь до 3+ годин лекцій на день, і хоча б ще 3-4 години самостійної якісної роботи в день, а не паралельно перегляду серіальчіку із залипанням в телефон, поки перед тобою лежить пустий файл IDE. Голова має боліти в кінці - значить мозок розвивається. Якщо легко, крепатури нема - значить мʼязи не ростуть.
Олександра Ковальова:Але в курсі, де під одним топіком лежить ще 2-3 шари діп дайву - відосіками по 20 хв не вийде, хоч вбийся 🤷♀️ І на менеджерські теми не поставиш практичне завдання на півгодини-годину-парочку. Там топати на проєкт, якщо робити, то це аналітична робота.Он учні Ріни та Артема, наскільки я розумію, роблять практичні по Тест Лідству, то одну таку, щоб на практиці для проєкту накидати - може і пару днів / тиждень / тижнів бути треба 😉 Моя думка збігається з колегами: якщо ви дійсно хочете чогось навчитись, будьте готові до того, що треба буде страждати. На жаль, це єдиний дійсно працюючий спосіб стати професіоналом у своїй області. Для навчання треба знаходити час, і не 20-40 хвилин, а 2-3 години на день (краще більше), і так, щоб у вас голова пухла від цього. Без концентрації і зусиль ефекту майже не буде.Якби формат ПЕРЕГЛЯДУ коротких лекцій працював, то до мене на навчання не приходили б люди після десятків курсів з Udemy. Люди, які лише після реальної роботи над собою і кодом писали мені, що нарешті воно все в голові стало на свої місця і з'явилось розуміння того, що вони роблять.Де знаходити цей час?На роботі! Старайтесь якомога більше застосовувати вивчене одразу і в робочих умовах. Щось вивчили - застосували. Нема зараз таких задач - створіть їх. Переконайте інших, що те, що ви зараз робите - ЦЕ РЕВОЛЮЦІЯ, і ви просто повинні це зробити для вашого проєкту. (Так, я розумію, що це дуже важко зробити, особливо коли ти Manual QA, який загруз у регресії, але треба шукати вихід з матриці, бо без цього ви так і будете робити регресію, поки не настане вигорання).Зараз у вас немає автоматизації і менеджери не хочуть це робити? Робіть НА НИЧКУ. Не кажіть нікому, автоматизовуйте те, що можете, і вчіться. Запускайте ці тести й економте свій час на ручних тестах.Боїтесь робити автоматизацію на ничку? Робіть підготовку тестових даних для ручних тестів.Завжди можна знайти, де застосувати і закріпити отримані знання на роботі.
🤖Тестування ШІ vs Тестування з ШІ#testing #aiJeff Nyman випустив цикл статей AI and Testing для тих, кому цікаво саме тестувати ШІ моделі. А не просто користуватись інструментами. Пости великі та потребують часу для опрацювання, але це СКАРБ та MUST-READ. Статті дають доволі непогані знання про те, як працюють моделі та найголовніше - як їх тестувати. 📝Статті:• Ollama and Models• Local LLMs and LangChain• LangChain Templates• LangChain Messages• LangChain and Orchestration• A Testing Example• Refining Tests• Refactoring Tests• Scaling Tests❗️Крім того, Jeff поділився своїми думками про навички тестувальників - "AI and Testing: Personal Marketability" Цю статтю я теж дуже раджу почитати. 💡 Ділюся основними моментами:• Коли у вакансії бачите "потрібен досвід з ШІ" то, зазвичай, це вміння користуватись інструментами ШІ для тестування (автоматизації). Дуже рідко зе значить саме тестування ШІ. • Курси зараз в основному вчать першій категорії навичок. Але вивчаючи як тестувати ШІ ви так чи інакше вчитесь працювати з ШІ інструментами ефективніше. • Важливі обидві категорії навичок. ⭐️ Що значить хороший тест кейс для ШІ? • Тестування узгодженості в умовах суперечливої інформації• Тестування задовільного рівня невизначеності• Перевірка на дисперсія при однакових умовах• Перевірка межі між знанням та висновками (міркуваннями)🐙 Й головне: There’s understandable anxiety in the testing community about AI replacing testers. (Just as there is for developers.) But here’s what that concern misses: the skills that make you good at testing are exactly the skills that make you valuable in an AI-augmented world. That’s the case whether you’re using AI to assist your testing or testing AI systems themselves.
Quality and test specialists have always needed an eye for spotting ambiguity, inconsistency, and contradiction. You look at a requirements document and notice where two statements can’t both be true. You examine a user interface and spot where the behavior contradicts the stated intent. You read test results and detect where the data doesn’t align with expectations. This isn’t a skill AI replaces. It’s a skill AI desperately needs applied to it.
TEST DESIGN IN PRACTICE 👾БЛАГОДІЙНИЙ 7-ДЕННИЙ МАРАФОН ДЛЯ QA!7 днів - 7 завдань в форматі челенджу, де ти протестуєш свої навички, знайдеш прогалини та прокачаєш скіли.Кожного дня — нове завдання з покроковими інструкціями.Які теми розберемо?• Тест аналіз • Граничні значення • Тестування переходів станів • Еквівалентні класи • Таблиця рішень • Попарне тестування • Пріоритизація✅Як приєднатись?Донат від 500 грн для 225-го ОШП на ремонт авто.🔗Посилання на банкуhttps://send.monobank.ua/jar/2wh4dECprh💳Номер картки банки4874 1000 2458 7993Після поповнення банки ти отримаєш посилання на канал марафону.💡Чому саме за донат?Так ми зробимо добру справу й допоможемо нашим захисникам, а ще ти отримаєш змогу взяти участь в розіграші 1 місця на курсі CSA&API або Test Analysis & Test design + отримати інші приємні бонуси.📄 Стартуємо 1 лютого [цієї неділі]!А якщо для тебе це не актуально — буду рада, якщо просто підтримаєш збір й пошериш інформацію про марафон своїм друзям і знайомим🖤Чекаю всіх!
TPI Next for All!#process #improvementЩось ми так запрацювались, що навіть про дійсно важливе для себе забули написати.Ми з Льошею давно й успішно практикуємо консалтинг з покращення процесів тестування. Проводили відповідні аудити декілька разів вдвох (це завжди веселіше), ще по 3-5 разів кожен окремо. Для того щоб покращити процес, по суті потрібні три речі:1) знати його поточний стан2) знати його бажаний стан3) план дій для руху між поточним і бажаним станомДля всіх трьох пунктів потрібен інструмент власне вимірювання стану процесу. І оскільки такі процеси, як тестування - це досить складна абстракція сама по собі, то для опису їх стану використовуються моделі, які дозволяють спроектувати все різноманіття форм різних процесів в різних компаніях на уніфіковану площину координат.Найбільш вживані моделі для опису процесів тестування: TMAP, TMMI та TPI Next (а також різноманітні кастомізовані похідні від них).І от нам з Льошею найбільше до душі свого часу прийшлась саме TPI Next, якою ми довго й плідно користуємось.Якщо прибрати всі ці заумні пояснення, то модель процесу - це по суті великий (на 100+ пунктів) чекліст в ексельці.Тепер от власне і до суті дістались :)Екселька - це звісно найкращий інструмент всіх часів і народів, в якому можна зробити взагалі ВСЕ, але чомусь при будь якій найменшій нагоді люди не перестають придумувати спеціальні рішення для заміни ексельки :)От і Льоша теж не втримався і навайбкодив в минулому році сайтик, де на гарній вебці (а не в ексельці) можна оцінювати зрілість процесів тестування у вашій або будь якій іншій компанії використовуючи модель TPI Next.- без смс та реєстрації- ваші дані - тільки ваші, вони зберігаються лише у вашому браузері локально- з генерацією гарного PDF звіту й з вивантаженням raw data в csv- українською й англійською Користуйтесь наздоровʼя, ставте зірочки в гітхабі.Ласкаво просимо!https://qamania.github.io/TPI-Next/en/index.html
🤖 Automation Is Not Quality, And Never Was#testing #automationПриніс невеличкий, але вкрай важливий пост про автоматизацію тестування. Особливо в часи, коли всюди вакансії одних генералів в QA, яких оцінюють лише за вмінням писати тести на плейрайті на швидкість. Автоматизація тестування для багатьох команд та менеджерів прирівнюється до наявності якості. Якщо пайплайн зелений - всі в безпеці. Якщо всі тести автоматизовані, то усі ризики покриті. Але таке бачення ... це велика помилка. Чому автоматизації недостатньо?1. Автоматизація перевіряє тільки те, про що знає (те, що ви написали в коді, не більше). Зелений пайплайн не означає, що продукт працює. Це лише означає, що автотести успішно виконані. 2. Коли менеджмент хоче швидких результатів, то, часто, автоматизують не те, що важливо, а те, що найлегше автоматизувати. До того ж, інженери концентруються виключно на UI тестах - бо результат легше показати менеджерам (ніж якийсь код в консольці).3. Як тільки автотест написаний - люди вважають, що сценарій "покритий" повністю. Але якість залежить від того, яку нову інформацію віднайшли під час тестування. Навіть того кейс, який вже автоматизований.4. Менеджмент ганяється за метриками покриття - покриття коду, покриття вимог. Але забуває про те, що автоматизація - це не просто про покриття чи запуск тестів. Це - про відповідальність. 5. Коли на проєкті мало flaky тестів - на них "забивають". Коли їх стає занадто багато - ніхто не довіряє СІ. Команда звикає ігнорувати сигнали від таких тестів. Коли автоматизація підсилює мислення тестувальників - вона допомагає будувати впевненість. Якщо ж автоматизація замінює мислення тестувальника - то підсилюються тільки помилки.
Звичайно, у вас на проєкті все не так. У вас цінують тест інженерів. Прислухаються до них. Та не концентруються виключно на автоматизації. 😀
👋Відкриваю набір на березневий курс з "Автоматизації API від Postman до Playwright-test з TypeScript + основи performance тестування з K6"Будемо розбирати повний цикл автоматизації API тестів від А до ЯПочинаючи від автоматизації в Postman і до створення повноцінного фреймворку на основі playwright-test.Ми не будемо вчити "сферичний код у вакуумі". Ми візьмемо реальні API сервіси, побудуємо фреймворк, накрутимо звіти та запхаємо це все в CI/CD пайплайн.➿➿➿➿➿➿➿➿➿➿➿➿Для кого цей курс:QA інженери, які хочуть навчитись ефективно автоматизовувати API тести (рівень Middle, Senior)Курс добре підходить як точка входу в автоматизацію тестування, адже є трохи легшим ніж Е2Е автоматизація. ➿➿➿➿➿➿➿➿➿➿➿➿Програма: 1) JavaScript Core (Бонус): 6 лекцій у записі для тих, хто не кодив раніше.2) API Automation & Architecture: 17 живих зустрічей3) Performance Testing: Основи роботи з K6.Ми будемо писати багато коду. Дуже багато коду. 😅➿➿➿➿➿➿➿➿➿➿➿➿Старт курсу: 2.03.26 (2 березня) Коли: пн. ср. пт. о 19:00 Тривалість: ~ 2.5 місяціВартість: 15 000 грнПовна програма курсу: тиць 👉🏻 сюдиРеєстрація та деталі:📱 @qa_senpai_dojo
TGLIST.COM.UA
