Telegram statistics channel - @qamania

Модель якості для AI систем#ШтучкаІнтелект #ТестуюШтучкуЩо таке якість програмних продуктів знає не тільки лиш кожен тестувальник, але й не кожен, хто не знає, знає, що є спеціальне доповнення до стандарту ISO, яке фокусується на атрибутах якості саме AI продуктів.Це доповнення називається ISO/IEC 25059:2023 - Quality model for AI systems. Й по суті описує той факт, що AI система - це теж програмний продукт, для якого актуальні всі атрибути якості описані в добре відомому нам стандарті ISO/IEC 25010:2023 (ми про нього писали детально ось тут: ISO 25010:2023 vs 2011 - Якість стала якісніше?), але з деякими нюансами.Ці нюанси виглядають або як додаткові під-характеристики атрибутів якості, або як уточнені.Коротенько про ці нюансики:🤖 User controllability - по суті це про наявність рубильника, яким можна штучку відрубити якщо щось в фізичному світі пішло не так.🦎 Functional adaptability - про вміння ШІ підлаштовуватись під зміни навколо: підкинули нових даних, змінилося середовище - і воно вже "думає" трохи інакше. Також про те, що іноді ця «адаптивність» може випадково підхопити й підсилити не ті ідеї.🎯 Functional correctness - про недетермінованість ШІ, в якого завжди є певний шанс на промах, бо воно працює з ймовірностями. Тому важливо чітко міряти, наскільки воно влучає в ціль, і пам’ятати, що іноді заради швидкості чи стійкості доведеться трохи жертвувати точністю. 🛡 Robustness - про вміння ШІ тримати удар: працювати навіть якщо дані криві, чи хтось намагається його намахати своїми навмисно чи не навмисно дурними промптами. 🛑 Intervenability - ось з цим нюансом в мене особисто виникли проблеми розуміння, бо дуже схоже на "рубильник" (User controllability), можливо в трохи мʼякішому його розумінні - щось накшталт кнопка «стоп-паніка»: побачив, що ШІ робить дурниці - швидко перевів його з небезпечного режиму в безпечний. Дочекаюсь коли в мене зʼявиться повний текст стандарту - щоб краще розібратись чи є відмінність.🔍 Transparency - моє улюбдене :) про те, щоб у ШІ не було «чорних ящиків». Має бути зрозуміло, як і чому воно робить свої недетерміновану магію: що в нього під капотом, які дані він бачив і як все це зліпив у рішення. Це і довіру підвищує, і помилки легше ловити.В наступних дописах розберемо альтернативи цьому стандарту (так, такі є!)Також спробую підібрати практичні й не сильно задротські приклади тестів.А ви тим часом пишіть в коментах, чи вже доводилось зіштовхнутись в роботі з цими характеристиками якості AI.

💡 Дизайн-ідея для тестування з відеоПривіт, друзі! Вже майже минув рік, як я змінив свою роль з керівника на інженера, і не можу не помітити, що мій блогерський запал майже згас. Попри те, що я виконую багато цікавих інженерних задач, об’єктивно розумію: вони навряд чи зацікавлять широкий загал. Але кількома гідними ідеями все ж поділюся.Мав задачу покрити автотестами таку фічу: ПЗ отримує відео з камери, ШІ його аналізує і, якщо бачить певні об’єкти в кадрі, перемикає деякі фізичні перемикачі. Людина-оператор у режимі налаштування ПЗ має вручну підтвердити коректність перемикання.У тестовому режимі відео з камери — це просто зациклений відеофайл, а фізичні перемикачі замокані.Тобто в режимі автотесту всі події передбачувані. Але є проблема — доступу через код до моків перемикачів не передбачено, а автотесту потрібно точно знати, в який момент підтвердити перемикання.Як завжди, у такої задачі може бути кілька правильних рішень. Одне з них — попросити команду розробки додати інтерфейс до системи, щоб отримувати повідомлення про перемикання й використовувати його в тесті. Але беклог забитий, усі зайняті, а я — мамин інженер і можу придумати елегантний воркераунд 🤷‍♂️Тож що я зробив? Маючи доступ до відеопотоку камери ПЗ, я:➡️ Отримав список кадрів з відео, де з’являються об’єкти, у вигляді масивів байтів (оскільки відеофайл незмінний, то й масиви байтів повторюються кожного циклу)➡️ Обчислив хеш кожного масиву➡️ Додав хеші до очікуваних результатів тестівУ результаті:1️⃣ тест запускається2️⃣ чекає потрібного кадру3️⃣ коли кадр з’являється — натискає перемикачі4️⃣ ПЗ записує файл підтвердження5️⃣ тест перевіряє, чи збігаються дані у файлі, надані ШІ та операторомЗгодом, для відеопотоків з великою частотою кадрів, щоб не пропустити потрібний, я оптимізував код: зберігаю в черзі хеші всіх кадрів за останню секунду й перевіряю, чи є в цій черзі потрібний мені.У підсумку — маю працюючий тест: швидкий, оптимізований щодо пам’яті, легко підтримуваний. У разі зміни відео — можна швидко отримати нові хеші й продовжити тестування.Більше того — у наступну ітерацію я масштабував цей тест на всі версії ПЗ і зекономив купу часу на ручному тестуванні.А ви тестуєте щось, пов’язане з відео? Які у вас є хитрощі?

Map of GitHub#todayilearnedСьогодні слухав виступ Андрія з Карпат про те як змінюється software в наші розігнані часи.The hottest new programming language is English - оце от всьо.Й на самому початку своєї доповіді він показав візуалізовану мапу репозиторіїв з GitHub:https://anvaka.github.io/map-of-githubЦе прекрасно! На півгодини завтикав, й гвалтуючи скрол на миші заглиблювався в розглядання материків, архіпелагів, островів й окремих "країн" в цьому світі коду 😍Візуалізація зв'язків між репозиторіями реалізована шляхом аналізу спільних підписників (тих хто поставив зірочку).Окрім суто естетичної насолоди, така візуалізація дійсно може надавати високорівневе розуміння того, чим зараз захоплюється спільнота творців коду. А маючи доступ до історії версій - можна ще й прослідкувати як цей світ змінюється в динаміці, як рухаються умовні тектонічні плити технологічних вподобань. Наприклад, якщо порівняти мапу 2023-го року, з мапою 2025-го року (додам скріншоти в коментарі), то можна помітити, що на останній виросли не те що "країни", а цілі нові материки й архіпелаги, так чи інакше пов'язані з AI/ML, і зокрема - величезний кластер репозиторіїв в яких немає коду в класичному нашому розумінні, а самі лише промпти.Андрій з Карпат називає цей феномен "Software 3.0". Най буде.Вам же пропоную теж залипнути насолодитись цим чудовим світом software, споглядаючи на його мапу :) Гарної подорожі!ПС ось ще посилання на запис виступу Andrej Karpathy, теж дуже раджу до перегляду:https://youtu.be/LCEmiRjPEtQ?si=zsbHOKNSCrjBjncZПС2 пишіть в коментарях хто знайшов на мапі Playwright 🔎

🚀 Я з величезним захопленням оголошую відкриття реєстрації на мій стартап — CYBORG TESTS! 🤖Зустрічайте CyborgTests — революційну платформу, яка поєднує ручні, автоматизовані та AI-тести в єдиний та зручний процес!🔍 Чому саме CyborgTests?🧩 Усі тести в одному місці: Ручні, автоматизовані, AI та кіборг-тести пишуться прямо в коді, тож більше не потрібно окремих систем управління тестами (допобачення TestRail)!🛠️ Є тести, які неможливо повністю автоматизувати? Не біда! Тепер ти можеш автоматизувати все аж до моменту, де автоматизація неможлива (наприклад, перевірка якості відеодзвінків), повністю автоматизуючи всі прекондішини (логін, початок дзвінка тощо).⚙️ Playwright всередині: Використовуй можливості найсучаснішого фреймворку Playwright для надійних і потужних автоматизованих тестів!🤖 AI на повну: Використовуй силу штучного інтелекту, щоб вивести тестування на новий рівень і звільнити тестувальників для більш цікавих та складних сценаріїв!📊 Все в одному звіті: Отримуй єдині звіти, які містять результати всіх видів тестування (ручного, автоматичного, аі і кіборг-тестування), з підтримкою паралельного запуску та шардингу!CyborgTests допомагає QA-командам стати ефективнішими, прибирає зайву роботу та значно прискорює процес випуску релізів!🔗 Дізнавайся більше та реєструйся на ранній доступ тут: https://www.cyborgtests.com/

❤️ Люди дають натхненняПривіт всім! Я дуже мало пишу останнім часом. Льоша-менеджер писав набагато більше і різноманітніше, ніж Льоша-інженер. Я сам це розумію, але ніц не можу з цим зробити. Не тому, що "втомився" чи стало не цікаво. Просто стало менше тем, якими хотілося б поділитись. Зараз мій типовий робочий день - подивитись статус автотестів в пайплайні, проаналізувати баги, якщо вони є і далі - кодити нові автотести. Раніше я спілкувався з багатьма людьми: тестерами, розробниками, аналітиками, менеджерами і замовниками. Консультував і вирішував проблеми. Я не стверджую, що одна робота цікавіша за іншу, але я сумую за людьми! Спілкування дає натхнення!В мене вже разів з 10 було - придумав і запрограмував дуже крутий алгоритм, який не просто вирішує задачу, а ще й робить це ефективно по часу і ресурсам, і код красиво виглядає. А похвалитися нема кому - якщо в коді нема проблем, то мій Pool Request просто заапрувлять.Це я все до чого! Цінуйте ваших колег, корисні мітинги і можливість просто поточити ляси з колегами 🫰

Метатести для LLM або хто потестить тести#ai #bugseverywhere Всіх давно вже цікавить питання: коли ж AI замінить нас на роботі. І надто це питання цікавить розробників. Проте в конструктивному руслі: "коли AI почне фіксити нудні баги замість нас, а ми нарешті зможемо продовжувати їх створювати більше творити?".Для відповіді на це питання існують різні методології оцінювання ефективності LLM на реальних задачах, зокрема от й на задачах по багфіксу. Одна з найвідоміших - SWE-bench.Якщо коротко, то SWE-bench - це набір даних, який перевіряє здатність AI агентів автоматично виправляти реальні баги на GitHub. 2,294 GitHub issues з 12 популярних Python репозиторіїв та unit тести для перевірки багфіксів - дозволяють отримати конкретну числову оцінку для того чи іншого поєднання агента та LLM.Наприклад найспроможніший агент на даний момент на "Verified" наборі - AI Programming Agent від Weights & Biases, який спромігся пофіксити 64,6% багів.Але є одне але. А що там з тестами, тобто з багами?Іншими словами: а чи перевіряв хтось, крім авторів SWE-bench релевантність цього датасету, на якому оцінюють здатність LLM агентів фіксити реальні баги? Такі дослідники знайшлись. Й перевірили SWE-bench датасет на відповідність поставленій задачі.Жодним чином не піддаючи сумніву важливість цього бенчу і йому подібних - лише вказуючи й пропонуючи можливості покращення методології оцінки LLM агентів.TL;DRАвтори дослідження з'ясували що більшість "успішних" патчів для GitHub issues з SWE-bench набору - насправді сильно під питанням, бо третина з цих issues містила правильний фікс в коментарях до issue, ще третина мали трохи неадекватні тести для того щоб перевірити фікс, тобто тести зеленіли не тому що проблему було реально пофікшено, а тому що в пулреквесті містився код на якому тести зеленіють :) Таким чином дві третини "фіксів" від LLM coding assistants дуже під питанням.Потім автори дослідження ще упоролись й дослідили чи входять потенційно фікси від цих issue в дані, на яких міг навчатись LLM, переробили тестовий датасет таким чином щоб були тільки GitHub issues створені точно пізніше ніж зріз навчання LLM - і тоді ефективність фіксів дропнулась взагалі до лічених відсотків: у найкращої моделі на той момент, chatGPT 4o - з 18,8% на "Full" датасеті до 3,83%!Висновки:Забавно що тести це баги, але не дуже забавно те що тести з багами :)Або іншими словами: тестові дані - наше всьо, і від їх якості залежить якість результатів, які ми хочемо і можемо отримати від LLM. Щодо фіксу реальних багів - поки що "такоє"..Якщо когось прям от сильно зацікавило, то ось додаткові посилання:1) сама стаття: link2) відео на ютубчику з розбором статті: linkА у вас як? Що ви фіксите за допомогою LLM? Діліться в коментах! Всім справді цікаво!

🗣 Сороміцька співбесіда і пріоритетиПривіт друзі! Настав час розказати вам про співбесіду, за яку мені було реально соромно, але яка допомогла мені чіткіше визначити свої пріоритети пошуку роботи.У вільний час я іноді пишу код не тільки на Python, але й на JS/TS - чи то просто з цікавості, коли прочитав про якусь прикольну бібліотеку, чи, щоб PoC зробити для порівняння. Тож, коли я почав шукати роботу, я написав створив собі новий проєкт у VS Code і переписав свої автотести для домашнього проєкту з Python на TS. І оскільки було не складно, я вирішив розширити свій пошук не тільки тест менеджментом і автоматизацією на Python, а ще й на JS. І навіть отримав кілька запрошень на співбесіди! Одну навіть пройшов. Що ж могло піти не так?Запросили мене на співбесіду в одну велику компанію, на мітинг прийшло кілька хлопців, які знали, хто я, а я знав одного з них. Тож отримав до себе заздалегідь дуже гарне ставлення. Вони запропонували мені live-coding сессію, я почав писати код. І тільки тут я зрозумів, що я взагалі нічого не знаю про TS, а все, що було написано раніше - працює суто випадково 😄 Задачі, що хлопці питали - прості для них, виявились невирішуваними для мене. З підказками я зробив одну, скіпнув другу, але, оскільки ставлення до мене було дуже хороше, мене всіляко підбадьорювали ❤️ і пропонували написати ще кілька прикладів. І ось, зробивши третю задачу, запускаю код і він не працює через синтаксичну помилку. Але VS Code не може сказати, де саме вона, тому що рішення було написани в найкращих традиціях JS/TS і код закінчувався чимось типу )))})})}}))}}} Кілька разів безуспішно його зарефакторивши, ми всі разом вирішили, що простіше ресетнути задачу і написати її з нуля - тільки тоді вона запрацювала. Але саме в цей момент я усвідомив, що мені це не подобається і я точно не хочу наступний рік колупати дужки.Тож я зробив те єдине, що могло покращити цю співбесіду - попросив пробачення за витрачений час; подякував хлопцям за чудову співбесіду і нереальний рівень довіри та підтримки; і завершив її. Після чого відмінив всі подальші інтерв'ю по JS/TS і прибрав ці мови з пошукових фільтрів. Дуже вдячний, що в результаті я чітко зміг побачити для себе не просто те, що я хочу робити з задоволенням а й те, чого я точно робити не хочу:)А які у вас були фейли на співбесідах?

❗️ Збираю статистику по layoff’амПривіт друзі! Я почав активно готуватись до пітчингу доповіді до DOU DAY 2025, де планую, поміж іншим, розказати свою історію скорочення і пошуку роботи. Але одна моя історія — нудна і не показова (буде типова помилка того, хто вижив).Коротка версія:🟢мене скоротили влітку, я цього зовсім не очікував, але мав актуальне резюме і орієнтувався в ринку🟠Спланував пошук роботи, намагаючись спочатку отримати найцікавішу і найприбутковішу, надавши собі на це 3 місяці, після чого мав знизити планку🟢Активно розсилав СV через майданчики пошуку роботи, LinkedIn та напряму в компанії зі списку топ-50🟠До кожного інтерв’ю готувався, читаючи уважно вакансію і гуглячи всі невідомі слова (і вичитуючи власне резюме)🟢До інтерв’ю ставився як до рівнозначної бесіди — не тільки компанія обирає мене, але і я компанію. Як результат, деякі інтерв’ю завершував раніше, бо розумів, що я заслабкий і не пройду, чи компанія мені не підходить🟠Мав портфоліо на github + блог — докази моєї професійної діяльності🟢Знайшов роботу за 2 місяціТож я подумав, а що як дізнатись у вас — якщо вас скоротили, як це сталось і коли, де, як ви шукали нову роботу?Оскільки в Інтернеті я часто бачу, що люди шукають роботу — аналітика і best practices можуть стати дуже корисним підґрунтям для наших колег, хто шукає роботу просто зараз.Приділіть, будь ласка, 5 хв вашого часу і заповніть опитування. А якщо вам є що розказати про ваш лейофф і пошук роботи — діліться в коментарях. І перешліть опитування вашим друзям та знайомим, якщо їх теж скоротили.➡️➡️➡️ forms.gle/3v9jobgCix5Tw5LAA 👈👈👈

🙊 Про співбесідиПривіт друзі! Буквально минулого тижня провели співбесіду з Попелюхою і мені пригадалось, як я сам проходив співбесіди цього літа, коли шукав нову роботу. Хотів цікаві історії притримати до наступного випуску подкасту, але не зрозуміло, коли він буде, тож нема чого тягнути. Тим паче, що за пів року деякі деталі трохи забулись.Почну з технічної співбесіди в компанії nCube, з якою я наразі співпрацюю. Вона для мене - еталонний приклад важливості портфоліо. Оскільки шукали автоматизатора, то хотіли подивитись на мої навички написання коду. Тому я відкрив свій Github і ми передивились ті проєкти, якими я пишаюсь найбільше: код, документація, юніт тести. І цього виявилось більш ніж достатньо, щоб справити приємне враження.Коли я про це згадую в розмовах, мені дорікають - "гарно вам, автоматизаторам, а що робити простим мануальщикам?" Для вас маю 3 поради:1️⃣ Починайте вчити і використовувати в роботі, для рутинних задач, будь-яку скриптову мову: python, JS, bash. В 2025 - це must have.2️⃣ Заведіть портфоліо з прикладами результатів вашої роботи мануальним тестувальником - тест дизайни, тест плани, баги. Не скачані з інтернету і не згенеровані ШІ, а такі, як ви робите кожного дня (чи їх ідеальні версії у вакуумі)3️⃣ Пишіть - чи навіть блог заведіть, як маєте час і натхнення. Але почати можна хоча б з постів в LinkedIn або статті на DOU. "Був у мене такий цікавий кейс на роботі, ось так ми його вирішили" - це ж буквально case study вашої роботи + документування та аналіз результатів 😉Для прикладу надаю приклад портфоліо - ще колись давно в Інфопульсі попросили зробити приклад для замовника - https://github.com/infopulse/Test-Documentation-Examples❗️ Дякую, що дочитали! Наразі триває мій збір на РЕБ для 18 ОМБР - деталі в закріпленому пості. Дякую ❤️

Аналітика зарплат QA, зима 2025Привіт друзі! Якщо ви ще не бачили - на DOU вийшла свіжа аналітика доходів QAДуже дякую всім, хто заповнив своєчасно анкету і рекомендую ознайомитись з результатами самостійно.Що було цікаво мені?💰 Основна метрика - ЗП. Хотілось би, щоб було краще. Але радію, що поки не стає в рази гірше⏳ Я невпинно віддаляюсь від медіани віку тестувальників. Добре, що поміж нас з'являються молоді і скілові інженери, але не хочу усвідомлювати себе старим 😅📄 Краще мати ISTQB сертифікат, ніж не мати! Я пропонував це питання і тепер маю доказ, що ті, хто мають достатньо знань і навичок для отримання сертифікату і заробляють більше!📬 Postman'ом користується 17% тест інженерів. Я здивований, що так мало. Але це пояснює посередні роботи по API тестуванню в Postman на останньому Dev Challenge. Більшість банально його не використовує. Якщо ви теж не користуєтесь - чим ви тестуєте API і чи тестуєте взагалі? Це при тому, що 77% тестувальників, за статистикою займаються тестуванням web. Як так?updА ще пишуть, що 76% тестерів пишуть тест кейси. Мені здається, що це не правда. От ви - пишете?