How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2

#bugs #games

Починаємо робочий тиждень з цікавої статті про баги.
Цього разу - розповідь про те, як свіжий апдейт для Windows 11 "видалив" з GTA San Andreas одну з моделей літаків (Skimmer).

В ході розслідування виявилось, шо розробники з Rockstar Games додали обʼєкт із назвою Skimmer ще в часи GTA Vice City. Але тоді то був ... човен. В San Andreas він став літаком, але йому не додали деяких обовʼязкових параметрів. Воно якось працювало вже 20 років, але тут Microsoft вирішили трохи пофіксити роботу стеку в Windows 11 24H2. Як результат - баг з літаком опинився на поверхні.

Я свого часу багато грав в GTA San Andreas. А ви? Яка ваша улюблена гра з серії?

Куди нас тягне штучний інтелект

#ai #llm #testing

Останнім часом я постійно натрапляю на дописи й статті, що мають спільну проблематику - як інструменти ШІ (Chat GPT, Claude, Cursor, etc.) впливають на інженерів.

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

AI isn’t leveling the playing field, it’s amplifying existing gaps. And without real mentorship, we’re setting up a generation of devs who can prompt, but can’t debug.

Інший девелопер висловлює схожу думку. Сучасні джуніор інженери можуть швидко отримувати результат з ШІ, але потребують глибших фундаментальних знань.

We’re trading deep understanding for quick fixes, and while it feels great in the moment, we’re going to pay for this later.

Коли раніше ми шукали відповідь, то поринали в багато різних джерел, дивились безліч відповідей на StackOverflow, порівнювали декілька рішень, дізнавались супутні знання - перед тим як прийти до того чи іншого рішення. Зараз ми просто отримуємо ЄДИНУ ШВИДКУ ВІДПОВІДЬ НА СВОЄ ПИТАННЯ.

Схожу думку висловлює автор цього посту. Делегуючи пошук відповіді штучному інтелекту - ми втрачаємо те саме навчання. Натомість ми отримуємо "рафіновані шматки коду", які начебто вирішують проблему. Мозок тим самим стає більш ледачим - треба лише закинути запит в ШІ та й по всьому. Якщо не напрягати мозок - то він припинить взагалі рости й розвиватись.

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

Про щось подібне я писав у своєму блозі. Бездумно користуючись ШІ ми втрачаємо той самий А-ХА момент, коли ми дійшли до рішення самостійно, коли ми НАВЧИЛИСЬ. Бо якщо ми навчились - ці знання залишаться з нами довше, ніж швидкий копіпаст.

То ж користуйтеся ШІ з розумом.

🚃 Проблема вагонетки (для тестувальників)

#testing

🛤 Що таке проблема вагонетки?

Це уявний експеримент в етиці, коли в людини є вибір, або залишити вагонетку на колії та зашкодити 5ти людям, або перевести вагонетку на іншу колію та зашкодити тільки одній людині.

🚉 Вагонетка в тестуванні

Dan Caseley в одному з чатів запропонував адаптацію цієї проблеми для тестувальників.

В спрінті заплановано 5 фічей. Незаплановані мітинги та продакшн індиденти, що трапляються протягом спрінта - зменшують час на розробку сами фічей. Якщо ви дотримуєтесь плану - то можете випустити усі 5 фічей, але з ризиком гіршої якості. Альтернативно - ви можете перепланувати спринт, викинути одну фічу повністю, але зменшити ризики для втрати якості для інших чотирьох.

Здається, вибір очевидний. Але то для тестувальників, які мають своє бачення.
Для бізнесу - вибір може бути зовсім інший ...

❓А що б обрали ви?

Доказова випадковість або як тестувати генератори випадкових чисел

#testing #random

Час від часу в роботі тест інженера ми можемо користуватись генераторами випадкових чисел чи тексту (Math.random() в Java / JS чи random в Python).

Але деякі системи (наприклад блокчейн) залежать від якості генерації таких випадкових значень. Тоді постає питання - як жеж протестувати той чи інший алгоритм?

Сьогодні пропоную поглянути на різні підходи до аналізу якості таких алгоритмів, включно з офіційними тестами від NIST (Національного Інституту Стандартів та Технологій США).

Android тестування в Netflix, Dropbox, Spotify

#testing #automation #mobile

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

Netflix (~50 інженерів)

- Прийшли від окремої команди SDET інженерів, до автоматизації в кожній окремій фіча команді. QA тестують мануально тільки фінальний smoke test.
- Піраміда виглядає як unit => screenshot => end-to-end => smoke
- Юніт тести за допомогою Strikt, Turbine, Mockito, Hilt, Roboelectric; Screenshot рівень автоматизується з Paparazzi / Espresso accesibility testing.
- UI автоматизація виконується з Espresso / UIAutomator + усілякі фреймворки для створення моків на бекенді
- Тести автоматично промоутяться до стабільних після визначеної кількості успішних запусків
- Unit + smoke тести на кожен PR. Окремі набори тестів - кожного дня чи тижня

Dropbox (~30 інженерів)

- Спочатку мали багато Е2E тестів, але з часом перейшли на рівні нижче
- Покриття юніт тестами стоїть на рівні 80% та виконується Roboelectric
- Девелоперів вчать проектувати тести: E2E тести включені в definition of done кожної задачі
- Screenshot тестування також з бібліотекою Paparazzi
- Мануальне тестування деяких кейсів все ще присутнє; тести трекаються в самописній TMS

Spotify

- Мають окрему релізну команду, що будує інструменти для полегшення релізів
- Тижневі релізні цикли - починають у пʼятницю (версія X.Y.Z)
- На окремому дашборді агрегуються усі баги конкретного релізу
- Наступна пʼятниця - релізний бранч для X.Y.Z
- Наступний тиждень - тестування версії X.Y.Z (включно з автотестами), підготовка та відправка в Store / Market
- Поступовий реліз на користувачів - починаючи з 1% та до 100% з активним моніторингом

Таємниче життя вашого API

#testing #api

З чого все почалося

Цього тижня я проводив експерименти з тим, як працює наша система з блоками різної довжини. Для цього я знайшов вбудований інструмент (Glutton pallet), який дозволяє заповнювати обрати наскільки заповнювати блоки "сміттєвою" інформацією. Конкретно - блоки заповнюються масивами 8-бітних чисел.

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

Але для перевірки, я вирішив зробити простий JSON-RPC запит окремого випадкового блоку через Postman. Ось тут почалася магія.

Postman показав мені відповідь від серверу, але розмір body був не 2 Mb, а ...4 Mb. Я спробував декілька інших блоків, але з тим самим результатом.
Я встановив розмір блоку в 1 Mb - response в Postman був розміру 2 Mb. Але ... чому?

Відповідь

Інструмент для замірів працював корректно. Але виявилось, що кожного разу коли ми робимо запит на JSON-RPC то під капотом результат автоматично кодується за допомогою SCALE кодека. Кожен байт в бінарному форматі кодується як два HEX символи. Тобто масив з 1024 байтів на виході буде мати аж 2048 символів. Причому кодування виконується "під капотом" самого вузла.

Висновок

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

SMURF: Beyond the Test Pyramid

#automation #testing

Цікава ідея: розширений погляд на тестову піраміду від Google.

Автор пропонує виходити за рамки піраміди та оцінювати ваші тести за наступними параметрами:

- Швидкість. Чим швидше зворотній звʼязок тим краще.

- Складність у підтримці. Чим більший рівень тестів - тим більше "під капотом" усього відбувається. Й тим більше часу треба на підтримку.

- Використання ресурсів. Чим менше ресурсів використує тест, тим швидше він виконується.

- Надійність. Надійний тест падає тоді й тільки тоді, коли є проблема.

- Реалістичність. Реалістичні тести перевіряють систему в умовах максимально наближених до реальних.

This is how you make a $100 billion AI worm

#security #ai

Всім привіт.

Знайшов вкрай цікаве відео про те, як зловмисники вже зараз відносно легко можуть створювати майже автоматичні скрипти (Python) зі зламу та розповсюдження шкідливого ПЗ (у вигляді хробаків)

Як? За допомогою ... Штучного Інтелекту!

Але ж ШІ має блок на "шкідливі" відповіді? Це можна обійти, шляхом тренування моделі.
Але ж треба знайти вразливості системи? Так, ШІ сканує бази даних усіх останніх вразливостей автоматично.
Але ж системі треба знайти як використати ту чи іншу вразливість? Так, але її можна натренувати на купі вже готових гайдів.

Тобто ШІ вже зараз дозволяє навіть людям з мінімальними технічними навичками створювати доволі серйозні загрози.

Дуже раджу до перегляду.
P.S. ось тут можна почитати, якщо нема часу на відео.

There is no single winner: Selenium AND Playwright

#testing #automation

Сьогодні говоримо про UI тести.

Marcus Merrell порівнює можливості Selenium та Playwright.

А ще - автор росказує в чому, на його думку, є реальна проблема масової міграції проектів на стильний й модний Playwright.

X як сервіс ... В чому різниця?

#howitworks

Знайшов хорошу візуалізацію різних хмарних продуктів категорії "as a service".

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

Vibe coding ... ти не пройдеш!

#python #bugs

🗺 Ситуація

Ви тест інженер та працюєте в команді з розробниками.
До команди приєднується новий девелопер. Він ... дуже полюбляє vibe coding, але не любить vibe debugging.

Через деякий час, ви бачите від нього PR на задачу обробки дорослих юзерів та фільтрації тих, у кого є валідна електрона адреса.

def process_user_data(users, min_age=18):
    results = []
    for user in users:
        name = user['name']
        age = user['age']
        email = user['email']
        if age >= min_age:
            if '@' in email:
                user['status'] = 'processed'
                results.append(user)

    average_age = sum(user['age'] for user in results) / len(results)
    print(f"Average age of processed users: {average_age}")

    return results

❔Питання: чи все ок з цим кодом? Відповіді пишемо в коментарях.

🔖 Software Testing and Quality Report - 4th Edition

#testing

Тут Test Rail випустив чергове дослідження щодо поточного стану та трендів розвитку тестування. В опитуванні прийняли участь 2500+ спеціалістів, більшість з яких - саме тест інженери. Респонденти були з різних компаній за масштабом та процесами.

Головні інсайти:

👉 Метрики. Найбільше трекають test pass / fail rate (70%) та кількість багів у продакшені (60%). Але більш складні метрики мало використовуються
👉 35% команд зосереджені на збільшенні тестового покриття та автоматизації. Лише 20% працюють над зменшенням багів на проді (Автоматизація, тільки автоматизація!)
👉 33% страждають від надмірної складності UI тестів та рішень з автоматизації
👉 Чим більше у команд автоматизації та інтеграції в CICD процеси, тим швидше релізні цикли та ... менше дефектів опиняється на стороні клієнта. (Хм, неочікувано ...)
👉 Багато команд все ще мають обмежені бюджети на QA, а разом із тим - відсутність часу на тестування
👉 Незважаючи на малі бюджети, менеджери скаржаться на те, що QA мають недостатню експертизу в автоматизації, AI, CI/CD. (Тобто вимоги підвищуються, а зп знижується)
👉 Більшість команд користується стандартами ISO 9001 (27%) та ISO / IEC 27001 (18%)
👉 Selenium (39%) все ще розповсюджений серед тестерів. Playwright - на другому місці (19%), Cypress - на третьому (16%) (А як же Playwright is the king?)
👉 Jenkins в топі серед CI/CD інструментів - 45%
👉 41% респондентів запускає до 100 автотестів на день. 33% оперує вже більшими обʼємами (до 1000 тестів)
👉 Найчастіші проблеми з автотестами - нестабільність тестів через часті зміни в UI, погані тестові дані, відсутність знань та вмінь в інженерів (Може краще рухатись на нижчі, більш стабільні рівні?)
👉 Більшість інженерів користується Chat GPT / Github Copilot. Але 36% людей все ще не бачать, як ШІ може допомогти їм у роботі
👉 Проблеми із застосуванням інструментів ШІ: безпека даних, відсутність експертизи в команді та складність інтеграції
👉 Розвиток ШІ в тестуванні незмінний: люди все ще думають, що ШІ чарівним чином буде фіксити автотести та писати код за них. (Та чи так це насправді?)

Rust - це не завжди швидко й ефективно

#rust #blockchain

Виявилося, що обробка транзакцій в блокчейні Solana була не те, щоб дуже ефективною. Приніс вам історію про те, як можна зменшити використання оперативної памʼяті з 2.6 Gb до 124 Mb.

В багатопотоковому світ структури типу Cow (Clone on Write) чи Arc не завжди підходять.

Є ще Bytes crate - який дозволяє ефективно клонувати не сам масив, а лишень покажчик (pointer) на нього.

Вплив Chat GPT на критичне мислення

#ai

Вчені з MIT провели дослідження того, як ШІ (Chat GPT) може вплинути на мислення й навчання людей. А саме - написання ессе.
В досліді взяли участь 54 людини у віці від 18 до 39 років.

Людей поділили на три групи:
- ті, що писали ессе за допомогою Chat GPT
- ті, що користувалися Google пошуком
- ті, що не користувались нічим

Які результати?

- Вчені зробили ЕЕГ активності мозку та виявили, що користувачі Chat GPT показали найнижчий результат на нейронному, лінгвістичному й поведінковому рівнях.
- Мало того, з часом, ці користувачі ставали все лінивіші - й все більше банально копіювали результат ШІ без будь-якої перевірки.
- Група, що користувалася ШІ, написала дуже схожі ессе, яким бракувало оригінальних думок.
- Група, яка не користувалась ніякими додатковими інструментами - показала найвищі результати, кращі ідеї, залученість та допитливість
- Група, яка користувалася Google, також показала непогану активність мозку та залученість

Люди, які користувались Chat GPT потім не змогли переписати свої ессе "з голови", без ШІ. А ось ті, які писали самі, змогли написати ессе за допомогою ШІ навіть краще.

Висновки

Сліпе й постійне користування ШІ так чи інакше робить нас лінивішими (перевірено на собі). Та не розвиває мозок взагалі.
То ж треба знайти потрібний баланс у застосуванні нових технологій.
Інакше - людство піде шляхом "Ідіократії", або ж "Матриці" (де правили машини)

Дякую Артему за цю статтю.

🔮10 ресурсів щоб тренувати знання SQL

#sql

Вчити чи не вчити SQL (та наскільки глибоко) - холіварне питання. 😱 Але якщо все-таки треба опанувати цю навичку - краще робити це цікаво.

Пропоную декілька цікавих ресурсів:

👉 SQL Noir - можна стати детективом та розслідувати справи за допомогою SQL (всього 6)
👉 SQL Murder Mystery - дослідіть базу даних та знайдіть того, хто скоїв вбивство (більш складна)
👉 SQL PD - станьте співробітником департаменту поліції та застосуйте свої знання SQL
👉 SQL Island - хороший ресурс для новачків
👉 SQL Zoo - доволі відомий сайт для тренування базових навичок
👉 HackerRank SQL - крім задачок на алгоритми, на сайті є задачі на бази даних
👉 SQL Game by DataLemur - "Гра в кальмара", але з SQL
👉 SQL Interview Questions - найбільш реалістичні питання, які можуть бути на співбесідах
👉 Advent of SQL - відкривайте нові задачі кожного дня, як адвент календар
👉 SQL (Leetcode) - підбірка питань з SQL (для більш підготовлених)

⚡️А які ресурси для тренування знаєте ви?

☀️ Літній анонс, бо немає сечі терпіти ці пекельні борошна з естімейтами!

У липні збираю нову групу на дводенний інтенсив - "Естімація задач по тестуванню"

📅 Дати: 12 та 19 липня
💡 Формат: Онлайн (2 заняття по 2-3 години)
🏷 Вартість: 2500 грн

📝 Що в середині?
Насичені 2 вебінари великою кількістю інформації про те, що таке естімейт, чому естімейти не працюють, та що спільного між Story Points та Оцінкою в годинах, якщо ви це робите під час planning poker.

🙋 Для кого буде корисний інтенсив?
👉 Якщо ти хоч раз давав естімейт, який "трохи не вгадав" – цей інтенсив для тебе.
👉 Якщо хочеш чітко аргументувати свої оцінки перед командою та менеджерами – приходь.
👉 Якщо твій естімейт постійно змінюється через "а ще ось це додайте" – будемо розбирати, як уникати таких ситуацій.

Що буде?
🔹 Техніки та інструменти для кращої оцінки;
🔹 Як аргументувати естімейти перед командою та менеджментом;
🔹 Типові помилки та як їх уникати;
🔹 Практика на реальних прикладах;
🔹 Домашня робота;
🔹 Купа корисних додаткових матеріалів.

💬 «Інтенсив навчив мене точніше робити оцінки й нормально ставитись до помилок у них!» (Маргарита)

📢 Кількість місць обмежена, реєструйтесь:
https://secure.wayforpay.com/payment/se9786bd1dd94

Запитання можна писати мені сюди 👉 @artem_grygorenko

Найшвидший спосіб знайти голосні в реченні

#python

Задача: написати функцію, яку перевіряє чи є голосні в рядку.

def has_vowels(s: str) -> bool:
    ...

Можна це зробити багатьма способами.

Спосіб 1

def loop_in(s):
    for c in s:
        if c in "aeiouAEIOU":
            return True 
    return False 

Спосіб 2

def set_intersection(s):
    return set(s) & set("aeiouAEIOU")

Спосіб 3

def map_lambda(s):
    return any(map(lambda x: x in "aeiouAEIOU", s))

Але виявляється, що найшвидший спосіб це - регулярні вирази!

import re
def regex(s):
    return bool(re.search(r'[aeiouAEIOU]', s))

Чому? Бо механізм регулярних виразів в Python дуже оптимізований. Більше можна почитати в оригінальній статті.

🚀Хто такі Expert Generalists та чому варто ставити такими?

#engineering #career

Як завжди, Мартін Фаулер задає тренди (як було з мікросервісами) та пише цікаві речі. В свіжій статті він пише про те, куди буде розвиватися інженерна індустрія.

🕶Хто такі Експерти Універсали?

Колись було правильно розвиватись виключно в одній спеціалізації та домені. Потім - виникли T-shape спеціалісти, які знали одну річ глибоко, а інші - поверхнево.

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

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

💫Характеристики експертів-універсалів

👉 ФУНДАМЕНТАЛЬНІ ЗНАННЯ. Самі ці знання допомагають швидше переходити між доменами, швидше розбиратись в технологіях. Самі ці знання старішають повільніше.

👉 Допитливість. Базова реакція на новий інструмент та технологію в такого інженера - розібратися ЯК ВОНО ПРАЦЮЄ та як цим користуватись ефективно.

👉 Вміння працювати в команді. Вміння вчитися в інших експертів; задавати правильні питання; не боятися визнати, що ти чогось не знаєш

👉 Скромність. Вміння прийняти той факт, що кожен новий домен має відмінності та свої "цікавинки". Та те, що контекст має значення.

👉 Фокус на користувачеві. Кожен новий домен чи технологія оцінюються через призму користі для продукту та користувача. А для цього - треба вивчати своїх користувачів

👉 Вміння дивитись за межі своєї спеціалізації. Працювати над різними задачами, а не тільки тестування, чи бекенд, чи фронтенд.

💼 Для менеджерів

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

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

🪄Висновок

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

Але думка в цілому мені подобається. Вона до того ж переклікається з підходом Modern Testing від Alan Page.

А що думаєте ви? Чи варто ставати експертом - універсалом? Чи, може, треба розслабитись - бо нас усіх захопить ШІ?

🎱Швидкість навчання vs. Новизна інформації

#learning

Розгляньмо графік. Червоним кольором показано швидкість навчання, а синім - кількість нової для нас інформації.

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

З часом ми набираємось досвіду- то ж швидкість навчання тепер зростає. Разом із тим зменшується фільтр нової інформації. Ми відкриваємо курс чи книгу й розуміємо, що на 300 сторінок маємо тільки 10-20 сторінок з дійсно свіжою або цікавою для нас інформацією. Решту - можна спокійно пропустити.

🪄Абсолютно нормально вчитися повільніше на початку. Та ще більше нормально - читати й вчити тільки те, що для вас нове.Й пропускати решту. Бо це - про ефективність та розумне використання часу.

P.S. А ще з досвідом треба більше часу витрачати на пошук звʼязків між тим, що ти вже знаєш та дрібками нового.

Важлива навичка при використанні ШІ

#ai #books

Сьогодні я хочу розповісти про "нову" навичку, яка стає вкрай важливою в сучасному світі. А саме - про вміння ставити запитання.

Виявляється, навичка не така вже й нова. Письменники-фантасти задавалися цим питанням ще ... 69 років тому назад! Наведу приклад - оповідання "Дотепник", Айзек Азімов, 1956 рік.

Для контексту: в далекому майбутньому винайшли Мультивак - такий собі суперкомпʼютер з ШІ. Він, звичайно, продукував результат на перфокартах - то ж для розшифрування результатів потрібні були аналітики. Але окремо стояли Гроссмейстери - люди, які могли ставити правильні запитання цьому ШІ. Таких людей було дуже й дуже мало.

Ось цитата з твору:

"На зорі історії Мультиваку з'ясувалося, що найвідповідальніша ділянка – це постановка питань. Мультивак вирішує проблеми для людства, він може вирішити всі проблеми, якщо... якщо йому ставлять осмислені питання. Але в міру накопичення знань, що відбувалося все інтенсивніше, ставити осмислені питання ставало дедалі важчим.

Одного розуму тут мало. Потрібна рідкісна інтуїція; той самий талант (тільки куди яскравіше виражений), яким наділений шаховий гросмейстер. Потрібен розум, який здатний з квадрильйонів шахових ходів відібрати найкращий, причому зробити це за кілька хвилин."

Як думаєте, чи зріс попит на вміння ставити питання з появою усіх цих Chat GPT / Claude / etc ?