Test Engineering Notes

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

#rust #blockchain

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

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

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

🔖 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% людей все ще не бачать, як ШІ може допомогти їм у роботі
👉 Проблеми із застосуванням інструментів ШІ: безпека даних, відсутність експертизи в команді та складність інтеграції
👉 Розвиток ШІ в тестуванні незмінний: люди все ще думають, що ШІ чарівним чином буде фіксити автотести та писати код за них. (Та чи так це насправді?)

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

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

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

#howitworks

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

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

There is no single winner: Selenium AND Playwright

#testing #automation

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

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

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

This is how you make a $100 billion AI worm

#security #ai

Всім привіт.

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

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

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

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

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

SMURF: Beyond the Test Pyramid

#automation #testing

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

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

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

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

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

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

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

Таємниче життя вашого 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 відповіді від серверу показані саме так, як вони реально зберігаються в системі.

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% з активним моніторингом

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

#testing #random

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

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

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

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

#testing

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

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

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

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

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

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

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

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

#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, порівнювали декілька рішень, дізнавались супутні знання - перед тим як прийти до того чи іншого рішення. Зараз ми просто отримуємо ЄДИНУ ШВИДКУ ВІДПОВІДЬ НА СВОЄ ПИТАННЯ.

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

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

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

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

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. А ви? Яка ваша улюблена гра з серії?

Як вчитись ефективно, та що взагалі вибрати для себе!
Як людина яка цікавиться дуже різносторонніми штуками мені прям дуже складно зрозуміти, що вчити в поточний момент, якщо ви такі самі, то рекомендую сходити на лекцію від Олександра! 😍

📌 Олександр Романов. Як зберігати фокус, коли навкруги стільки всього цікавого

📅 Вівторок, 22 квітня о 19:00 за Києвом
🧑‍🏫 Формат заходу: лекція

🔎Про що поговоримо?
Чи бувало у вас так, що ви починаєте новий курс, але дуже швидко "забиваєте" й кидаєте його вже через пару днів? Або читаєте книгу, яку усі дуже рекомендують, але також швидко переключаєтеся на ще більш нову й цікаву? Чи стикалися ви з проблемою, коли хочеться вчити усе й одразу, але немає розуміння, з чого почати?
У мене були ті самі проблеми. Кількість інтересів та матеріалів зростала, фокус втрачався, хотілося вчити все та навіть більше. З часом я зрозумів, що потрібна організація цього процесу — інакше буде суцільний хаос. У своїй доповіді розповім про свій тернистий шлях з пошуку інструментів, які дійсно працюють.

Ця доповідь для тих, хто:
- хоче зрозуміти, ЩО треба вчити та як створити собі персональний план розвитку;
- хоче відрізнити ХОЧЕТЬСЯ вчити від ТРЕБА;
- прагне вчитися довго й не загубити мотивації дорогою;
- бажає нарешті знайти той час на навчання.

🎙 Олександр про себе
Мене звати Олександр Романов. В ІТ я з 2011 року. За цей час писав на Java, C#, Scala, Python; автоматизував web, mobile, API, мікросервиси, блокчейн.

Автор каналу Test Engineering Notes та дайджестів на DOU, ведучий подкасту Testing Minutes.

🔎 Де знайти Олександра?
Linktree

🎟 Як взяти участь?
- Придбати квиток/запис (200 грн із квитка йде на ЗСУ)
- безкоштовно: для учасників спільноти

🔹 Хочеш приєднатися до спільноти?
📌 Дізнайся більше тут → @suvoriy_qa_bot

📅 Календар з усіма подіями: Переглянути

До зустрічі на заході ☺️

Любі друзі, тестувальники — далі інформація для вас!

У квітні проведу Інтенсив - "Естімація задач по тестуванню"

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

А тепер пройдемось по деталях.

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

Що буде?
📌 Техніки та інструменти оцінювання
📌 Як робити точніші естімейти та обґрунтовувати їх
📌 Основні помилки в оцінках і як їх не припускатися
📌 Кейси та практика на реальних прикладах
📌 Купа додаткових матеріалів по темі

📢 Реєстрація тут і зараз
Запитання можна писати мені сюди 👉 @artem_grygorenko

Характеристики якості програмного забезпечення

#testing

Якщо ви думаєте, що на функціональному тестуванні якість закінчується, то ось ще невеличкий список можливих характеритики якості (як зовнішніх та і внутрішніх).
Так, це ті самі *-ility та набагато більше.
Цей список стане хорошим джерелом ідей, куди розвивати тестування й інструменти на проєкті.

Сіньйор пробує vibe coding (з ШІ)

Сьогодні хочу поділитись відео про те, як сіньйори в реальності користуються ШІ.
Це ж насправді так, Артуре?

Що краще: enumerate чи range для циклів

#python

Уявімо, що треба пройти по усім елементам циклу.

Це можна зробити дуже просто

fruits = ["apple", "banana", "cherry"]
for fruit in fruits:
    print(fruit)

Якщо ж треба мати доступ до елементу разом із його індексом, є такі варіанти

# range
fruits = ["apple", "banana", "cherry"]
for index in range(len(fruits)):
    print(index, fruits[index])

# enumerate
fruits = ["apple", "banana", "cherry"]
for index, fruit in enumerate(fruits):
    print(index, fruit)

Що краще обрати - enumerate чи range?

1. enumerate більш чисто виглядає та ще й оптимізована на рівні інтерпертатора
2. enumerate не має потенційних проблем з доступом по неіснуючому індексу
3. enumerate дозволяє задати початковий індекс для ітерації

for index, fruit in enumerate(fruits, start=1):
    print(index, fruit)

Окей, а коли ж краще користуватись range?

- коли колекція елементів точно індексована
- коли не треба мати доступ до конкретного елементу за поточним індексом

for i in range(10):
    print(i**2)