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

Просто знайдіть кнопку "Manage subscriptions" в меню зліва.

🤖 Ефективна робота з ШІ із Sens-AI фреймворком

#testing #engineering #ai

📚Сьогодні я розповім про підхід до роботи з ШІ, який пропонує Andrew Stellman в книзі “Critical Thinking Habits for Coding with AI”.

👉 Andrew називає цей підхід - Sens-AI framework. Цей фреймворк дозволяє інженерам користуватись та вчитись з ШІ не маючи проблем із парадоксом когнітивного спрощення.

Фреймворк складається з:

1️⃣ Контекст. Переконайтеся, що ваші промпти дають найповніший контекст для ШІ.

2️⃣ Дослідження. Робіть додаткові самостійні дослідження, якщо перші відповіді від ШІ занадто поверхневі або ж ви стикнулись з циклом перефразування.

3️⃣ Формулювання проблеми. Переформулюйте проблему, коли відповідь від ШІ не відповідає меті або ж занадто заплутана.

4️⃣ Удосконалення. Покращуйте результати відповідей від ШІ ітеративно.

5️⃣ Критичне мислення. Регулярно ставьте під сумнів відповіді ШІ, наче це код від менш досвідченого інженера.

Фреймворк цікавий, але на мій погляд є доволі очевидним. А ви як думаєте?

📖 Taking Testing Seriously - Огляд 3

#testing #books #takingtestingseriously

Попередні огляди: 1, 2

Сьогодні поговоримо про цікаві моменти з книги Джеймса Баха та Майкла Болтона. А точніше - “Chapter 3 - How to Do a Test”.

🔬Суть тестування та міссія тестувальника

“... суть тестування в слові … наука. Наука це і є тестування. Як вчені вивчають фізичний світ та будують про нього теорії, так і тестувальники вивчають штучні світи та їх звʼязок із людьми …”

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

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

В контексті тестування, автори пропонують користуватись трохи іншими термінамиЖ простір оцінювання та простір продукту.

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

Міссія тестувальника полягає в тому, щоб перетворити наʼвні переконання (ті, з яких ми починаємо) на обгрунтовані доказами, точні та надійні переконання. Саме тому кожен тест, який ми виконуємо це … запитання. Запитання є головную мотивуючою силою як в тестуванні, так і в науці.

💡Що таке хороше тестування?

Джеймс та Майкл також розповідають про універсальний процес хорошого тестування:

1️⃣ Збирайте та досліджуйте докази поведінки та атрибутів продукту

2️⃣ Досліджуйте можливі пояснення цих доказів та те, як вони повʼязані з вашими існуючими переконаннями

3️⃣ Рухайтесь вперед та назад - розглядаючи пояснення на основі доказів або ж шукаючи докази вмотивовані вашими переконанннями

4️⃣ Зосередьтеся на ризиках цінності продуту, бо це є однією з цілей тестування

5️⃣ Розповідайте історію про продукт та тестування - собі, своїм клієнтам й отримуйте від них зворотній звʼязок

6️⃣ Вирішуйте чи завершили ви оцінку продукту на основі наявних доказів. Рішення спочатку приймає тестувальник. Але на вищих рівнях - тільки клієнти зможуть прийняти фінальне рішення.

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

Шо там по ЗП?

DOU проводить зимове зарплатне опитування. А работодавці в Україні доволі часто користуються зарплатними віджетами щоб зрозуміти актуальні гілки.

То ж пропоную заповнити форму опитування тут. Це допоможе усім зрозуміти поточний стан речей.

🔬Фантастичні “інженери якості” та де їх знайти

#testing

Спочатку були тестери, що із часом зросли в QA. Потім - автоматизатори тестування. Згодом вони трансформувались в СДЕТів (software developer in test). В межах України виникли окремі цікаві “мутації” - такі як General QA.

В західних спільнотах, таких як Ministry of Testing, ви не знайдете генералів. Але десь з 2024 - 2025 років почали згадуватись нові “фантастичні звірі” - Quality Engineer. Здається … “це ж було вже!” Люди почали писати цілі статті чи виступати з доповідями про те, хто такі ці інженери якості та як вони відрізняються від того, що ми мали. (Й міксувати все з ШІ, як же без цього).

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

Хто такі інженери якості?

Дехто вважає, що інженери якості виникли, коли тестери стали “погано продаватись”. Software Engineer звучить гордо, а tester … це взагалі прилад. То ж в деяких компаніях вирішили змінити назву на Quality Engineer.

Що самі тестувальники говорять?

👉 Komal Chowdhary вважає, що у тестера вузький фокус саме не тестуванні окремої фічі чи окремого продукту. Інженер з якості має ширший фокус на всьому процесі розробки й відповідальний за якість усієї системи: включно з процесами, стандартами та інструментами.
👉Cassandra H. Leung вважає, що тестер зосереджується на виявленні корисної інформації, коли інженер з якості не просто виявляє, й рухає інформацію нагору й використовує її для покращення.
👉Nick Baynham навпаки каже, що інженер з якості ніяк не відрізняється від тестера. Це просто назва позиції в конкретній компанії. Stefan Papusoi також згоден з ним та зазначає, що в деяких місцях інженер з якості - це просто автоматизатор.

Але усі погоджуються, що щоб бути хорошим інженером з якості, треба насамперед бути хорошим тестувальником.

Що ми маємо по факту?

Коли я почув про інженерів якості, то одразу згадав, що саме так називали людей із тайтлом Quality Assurance. Вони якраз були відповідальні не просто за тестування, а за щось глобальніше. Але QA стало немодно, то ж вигадали щось інше. Можливо саме через те, що software engineer - це “справжні” інженери, що приносять результат, а QA - не зрозуміло хто такі (для менеджменту). Можливо ще й тому, що забезпечення якості це вкрай великий пласт роботи - в більшості випадків на рівні QA Management та й вище.

Особисто мені, позиція Quality Engineer подобається більше ніж General QA. Бо інженер - це людина, яка робить свою роботу за допомогою цілого набору інструментів. Автоматизація - лише один з інструментів.

Але як із будь-яким тайтлом - кожна компанія має свої власні очікувані та бачення Quality Engineer. А інколи - немає ніяких очікувань …

Чи є серед вас люди із тайтлом “Quality Engineer”? Чим ви займаєтесь, крім тестування?

📚Що почитати з технічного (2025 edition)

#books #recomendacion

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

🧪 Тестування

📗Taking Testing Seriously: The Rapid Software Testing Approach - дідусі Бах та Болтон випустили свою довгоочікувану книгу по Rapid Software Testing. Купа цінної інформації. Лише деякі окремі розділи мені не сподобались. Але загалом 10 з 10.

📗Drawn to Testing та 📗 Writing Test Plans Made Easy - дві книги від Wayne M. Roseberry. Перша - набір корисних думок та досвіду у вигляді промовистих зображень від тест інженера з Microsoft. Друга - коротко та ясно описано як треба писати тестові плани.

📗 Contract Testing in Action Marie Cruz, Lewis Prescott розповідають покроково та з картинками про те, як треба робити контрактні тести для вебу, мобайлу та різних брокерів повідомлень. Дуже практична!

📗 Software Testing with Generative AI Mark Winteringham показує, як користуватись ШІ в тестуванні та автоматизації. В ШІ все змінюється кожен день, то ж можливо деякі речі вже будуть застарілими. Але основні ідеї хороші.

💻 Програмування

📗 Dead Simple Python: Idiomatic Python for the Impatient Programmer - книжка для тих, у кого є досвід в програмуванні, але вони переходять на Python й хочуть зрозуміти мову трохи глибше, ніж базовий синтаксис та find_element

📗 Learn Rust in a Month of Lunches - хороша книжка по базовим аспектам мови Rust. Якщо хочеться ще більше прикладного - дуже рекомедую 📗 Zero To Production In Rust: An introduction to backend development від Luca Palmieri. Тут ви поступово будете будувати повноцінний сервіс за допомогою усіх модних бібліотек з екосистеми Rust.

📡 Інженерія

📗 Your Code as a Crime Scene, Second Edition: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs - Adam Tornhill. Офігезна книжка, скоріш для архітекторів, або ж лідів яким нудно. Тут розповідається про те, як можна "ковиряти" вашу кодову базу та історію Git й отримувати цікаві інсайти про можливі проблемні місця в продукті.

Для тих, хто хоче хорошу та сучасну книжку про розподілені системи - можна подивитись в сторону 📗"Think Distributed Systems" від Dominik Tornow. Купа ілюстрацій. Книжка також підійде, якщо ви готуєтесь до system design інтервʼю.

🔬Навантаження

📗 Performance Testing: An ISTQB Certified Tester Foundation Level Specialist Certification Review - Keith Yorkston. Базовий мінімум того, що треба знати для тестування навантаження. Але все-таки вимагає деякого технічного бекграунду.

📗 Systems Performance: Enterprise and the Cloud - Brendan Gregg. Величезна! Такий собі довідник з інструментів та підходів до перфоманс тестування з акцентом на Linux / Unix системи. Буду до неї повертатись ще дуже довго. Але вона вартує кожного центу. (Але тільки, якщо ви дійсно займаєтесь таким видом тестування).

🔗 Блокчейн

📗 Blockchain, Crypto and DeFi: Bridging Finance and Technology від Marco Di Maggio. Сучасний погляд на блокчейн й все, що будується на його основі - включно з децентралізованими фінансами. Дуже докладно й наглядно. Якщо хочеться прочитати одну книжку й мати більше менш хороше розуміння індустрії.

📎 Менеджмент

📗 The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change від Camille Fournier та 📗 Engineering Management for the Rest of Us від Sarah Drasner. Обидві книжки хороші для лідів початківців. Друга напевне більш проста (й реально дешевше).

А які книжки ви можете порекомендувати?

Taking Testing Seriously - Чому важливо розповідати історії

#books #testing

Продовжую нотатки з книги Баха й Болтона. Інші записи за хеш-тегом #takingtestingseriously

Ціль тестувальника не просто пройти N тестів чи автоматизувати 100500 кукумбер сценаріїв. Ціль тестувальника це надати своїм клієнтам інформацію про продукту, тим самим перетворити припущення на факти. Але крім цього, клієнти повинні бути впевненими, що тестери роблять свою роботу ефективно.

Саме тому для тестувальника важливою навичкою є … РОЗПОВІДАТИ ІСТОРІЇ (або, іншими словами, тест / баг репортинг)

Як розповісти захопливу історію?

Джеймс та Майкл зазначають, що захоплива історія про тестування складається із відповідей на три важливі питання: Що трапилося? Хто це каже? Ну то й що?

👉 “Що трапилося?”. Це питання про особливі речі, що відмінні від звичайного перебігу подій (expected case). Саме ви робите вибір того, що є релевантним до ситуації, а що можна проігнорувати. Ви берете до уваги те, що ваша аудиторія вже знає, а що - потрібно більш чітко підкреслити. Не забувайте, що частину відомих фактів все ж таки прийдеться розповісти - щоб надати потрібний контекст перед тим, щоб говорити про баги.

👉 “Хто це каже?”. Або іншими словами - “чому хтось має в це вірити?”. Частково це питання довіри до вас або відділу тестування. Частково - питання наявності доказів. Докази можна надати. А от над довірою в команді та з різними менеджерами потрібно працювати завжди. Довіру вам, як тестувальникам, завжди тяжко будувати, але дуже легко знищити (якщо ви постійно будете репортити неперевірені факти). Як будувати? Прокачуйте свої навички, в тому числі технічні. Прокачуйте знання свого компоненту та частин навколо. Прокачуйте знання бізнес домену.

👉 “Ну то й що?”. Недостатньо просто надати достовірну інформацію обраній аудиторії. Ваша задача показати чому ця інформація є важливою. Чому аудиторія повинна зреагувати та прийняти рішення. То ж задумайтесь - як ваша історія (тест чи баг репорт) допоможе менеджменту прийняти більш зважене рішення про реліз? Це залежить насамперед від того, в який момент часу ви подаєте ваш звіт (розповідаєте історію). Памʼятайте про пріорітети. Можливо перед самим релізом не варто приходити із купою “косметичних” неважливих проблем, а варто зосередитись на тих, що мають найбільше користі.

🕶 Забутий крок, який зробить роботу з ШІ більш ефективною

#ai #llm #learning

Майже всі зараз так чи інакше користуються ШІ інструментами. Це може бути різні ШІ-агенти або ж розумна генерація тестів чи код ревʼю.

Ми набагато менше гуглимо, а Stack Overflow репортить рекордно низьку активність. Окреме питання, до чого це призведе. Бо ШІ для кодингу вчиться в тому числі на правильних відповідях зі SO. То ж якщо не буде звідки брати інформацію про нові фреймворки та рішення - з часом ефективність ШІ може впасти (особливо для кардинально нового). Але можемо посперечатись в коментарях.

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

🎓 Різниця між знанням та розумінням

Перед тим, як говорити про якість відповідей, треба визначити два важливих терміни: знання та розуміння.

👉 Знання це структуровані, доступні для пошуку представлення фактів, правил та описів світу. ШІ якраз може дати нам ці знання у вигляді фактів. (Але чи достовірні вони?). Знання відповідають на питання - що це, які правила, як працює цей процес.

👉 Розуміння - це те, наскільки ми здатні використовувати знання щоб моделювати й пояснювати реальність. Більше того, розуміння це наша здатність будувати причинно-наслідкові звʼязки та передбачати як система чи процес буде себе вести у випадку, коли умови зміняться. Розуміння - це не просто звалище випадкових фактів.

Коли ШІ дає нам знання - воно дає таку собі мапу. Але розуміння приходить тоді, коли ви самі пройшли за цією мапою.

💡Про легкість ШІ

До появи ШІ, коли людина щось не знала - це було очевидно. Але з ШІ можна побачити появу фальшивої компететності.

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

ШІ може “навалити” дуже багато фактів. Наприклад блокчейн можна бачити як: розподілену систему, консенсус, хешування, цифрові підписи, базу даних. Але тільки із розумінням людина може обʼєднати ці факти в одну ментальну модель.

🔬Протестуйте ваше розуміння

Як швидко визначити чи ви розумієте, чи просто бездумно користуєтесь фактами від ШІ

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

Якщо коротко - знання можна “скачати”. Розуміння здобувається із зусиллям.

❗️Один крок, щоб підвищити розуміння

Основна порада (особливо в навчанні) - не питайте ШІ просто “Поясни мені Х”.

Замість цього, формулюйте більш глибокі питання:
⭐️ Чому Х може впасти? У чому плюси й мінуси використання Х?
⭐️ Наведи приклад неправильного пояснення Х
⭐️ Що більшість людей неправильно розуміють про Х?

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

🐙 AI and Testing: Evaluating the Future

#testing #ai

Jeff Nyman у своїй статті ділиться думками, як же ж перейти від vibe testing до дійсно ефективного тестування з ШІ та тестування самого ШІ. Раджу почитати!

Сучасні компанії рідко вікористовують просто LLM - вони будують свої продукти, які включають в себе LLM функіональності. Наприклад - Retrieval-Augmented Generation (RAG), Agentic Workflows, Structured Output Pipelines. Тест інженери не завжди тестують модель, вони тестують усю систему.

В традиційному тестуванні очікувані результати детерміновані (постійні та передбачувані).

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

Різниця між потенціалом та реальністю

Потрібно розрізняти загальні можливості моделі та їх конкретне застосування.

👉 Потенціал моделі - це величезний резервуар статистичних ймовірностей. Коли ми тестуємо таку систему - ми перевіряємо, що вона може робити "у вакуумі".

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

🎓 Як оцінювати системи на основі ШІ?

Jeff пропонує оцінювати відповіді від систем з ШІ за наступними параметрами:

💡 Релевантність. Чи дійсно та відповідь це саме те, що хотів користувач чи це галюцинація правильної, але недоречної відповіді?
💡 Достовірність (обгрунтованість). Чи дійсно відповідь випливає з наданого контексту чи модель спирається на зовнішні (подекуди застарілі) дані?
💡 Контекстуальна точність. Наскільки добре система спочатку отримала правильну інформацію?

Для оцінки таких систем з ШІ Jeff наводить приклад інструментів - таких як DeepEval чи RAGAS.

⭐️ Ці інструменти використовують метакогнітивний підхід, який часто називають "LLM-as-a-judge". Тобто для оцінки одного ШІ додається вторинна, потужніша модель, що діє як обʼєктивний оцінювач. Ця модель розглядає докази та згенеровану відповідь й оцінює наскільки відповідь відповідає дійсності.

Ось воно яке - майбутнє тест інженерів

⭐️ The Next Two Years of Software Engineering

#engineering #career #ai

Addi Osmani, інженер з Google, зробив невеличкий огляд того, в якому стані зараз індустрія розробки та які варіанти її розвитку в найближчі пару років. У цій статті Addi наводить пʼять основих тез та на кожну з них - два можливі варіанти розвитку. Але автор не дає гарантії, куди індустрія може "звернути".

👶 1. Джуніори

Чим більше ШІ інструментів, тим менше компанії наймають джунів. Випускників топових вишів в США не хочуть брати на посади розробників. Бо сіньйор з ШІ подекуди може замінити роботу невеличкої команди. Але разом із тим, може статися так, що більше задач з розробки відриється в нових доменах. Особливо там, де треба автоматизація рутинних процесів. Там теж потрібні інженери.

Найголовніший ризик нікуди не дівся: сьогоднішні джуни - це майбутні сіньйори. Якщо джунів не буде сьогодні, через 5 - 10 років виникне жорстка нестача кадрів.

💡 Джуни: вчіться використовувати ШІ інструменти ефективно. Фокусуйтесь на навичках, які ШІ не замінить - комунікація, декомпозиція, доменні знання. Дивіться на навички в суміжних напрямах.

💡 Сіньйори: Автоматизуйте рутинні задачі з ШІ, менторьте людей. Говоріть менеджменту про ризик не-найму джунів.

✏️ 2. Навички

84% розробників користуються ШІ тулами кожного дня. Розробка перетворюється з вміння писати алгоритми на вміння писати промти. Новачки пропускають етап навчання та "написання коду самостійно", що в майбутньому може призвести до недостатніх навичок для вирішення реальних проблем на продакшені.

З іншого боку, дехто вважає, що ШІ забере 80% рутинної роботи, а розробникам треба буде концентруватись на 20% що залишилися. Це - архітектура, інтеграція, дизайн, перфоманс, безпека. Програмування зміниться: стане більше цінуватись вміння робити ревью.

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

💡 Джуни: Користуйтесь ШІ як інструментом навчання. Вчіться основам. Відключайте ШІ час від часу та пишіть самі. Тестуйте свої рішення.

💡 Сіньйори: Слідкуйте за якістю та складністю ваших рішень. Вчіть архітектуру, безпеку, доменні знання.

🎭 3. Роль розробника

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

💡 Джуни: мисліть за межами написання коду. Розвивайте системне мислення. Задавайте питання сіньйорам - "Чи я щось упустив в моєму рішенні?"

💡 Сіньйори: дивіться в сторону лідерських та архітектурних ролей. Розробляйте чек-лісти та стандарти. Беріть до уваги продуктову та бізнесову частину бізнесу.

🪜 4. Спеціаліст чи Генераліст

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

💡 Джуни: дивіться ширше та робіть задачі з інших напрямів. Розбирайтесь в нових інструментах.

💡 Сіньйори: оцініть, де ви знаєте глибоко, а де - "просідаєте". Закривайте пробіли маленькими проєктами. Шукайте паттерни та знання, які можна перевикористати між напрямами.

🎓 5. Освіта

З одного боку університети залишаться, але будуть ще більше відставати від індустрії. З іншого - освіта буде замінена буткампами та курсами від конкретних компаній.

💡 Джуни: не думайте, що університетські знання автоматично дорівнюють роботі. Будьте активними в комʼюніті. Шукайте менторів. Приймайте участь в хакатонах та стартапах.

💡 Сіньйори: кількість років досвіду нічого не значить. Цінуються тільки реальні вимірювані досягнення. Постійно навчайтесь. Менторьте інших новачків.

The 2025 Quality Engineering Index: 100 Insights

#testing #engineering

Jit Gosai поділився цілою сотнею інсайтів на тему Quality Engineering.

Які ж теми входять в ці інсайти?

• Визначте якість та відповідальність
• Прискорюйте зворотній звʼязок та testability
• Будуйте автоматизацію, яка окупиться
• Робіть кращі рішення в умовах невизначеності
• Вчіться на ваших інцидентах
• Створіть культуру якості
• Впливайте та комунікуйте про якість
• Користуйтеся метриками та сигналами, що дійсно працюють
• Використовуйте ШІ не втрачаючи судження
• Робіть покращення надовго через звички та практики

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

Але загалом, більшість з рекомендацій абсолютно не нова. Тема із Quality Engineering - це просто модна й сучасна обгортка над тим, що колись називали quality assurance. Єдине, що покращилось - це те, що тест інженери все-таки повинні бути більш технічними та вміти будувати інструменти тоді, коли цих інструментів не вистачає. А не мучитись роками зі старими тулами, які не працюють. Плюс - наявність цих технічних знань допоможе розмовляти з розробниками на одній мові та додавати ту саму якість ще на етапі розробки. (Причому не тільки на словах).

А ви як думаєте? Чули вже про Quality Engineering?

📡 Як веб сокети на бекенді можуть привести до мільйонних рахунків на AWS

#engineering #case

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

Код був правильний, тести - зелені. Просто ... не вистачало оптимізації.

🧪 В чому проблема?

А проблеми - не було. (На перший погляд)

Продукт recall.ai використовує CPU замість GPU для процессінгу відео. Для низько-рівневої взаємодії вони використовують веб сокети.

Виявилось, що найбільше CPU займають функції memcpy та memmove. Причому ці функції викликаються як на стороні кастомного Python клієнту (при обробці даних), та і на стороні Chromium (при відправці даних). Для масштабу - вони обробляли відео дані в середньому десь зі швидкістю 150 MB/s.

Здається, ну то й що? Якщо копнути глибше, то стандарт Web Socket, якого дотримується Chromium, вимагає, щоб дані були фрагментованими та замаскованими. Тобто треба витрачати додаткові ресурси на те, щоб розбити дані на частини розміром 131 Kb, а потім ще й закодувати кожен байт перед відправкою по мережі.

Як бачимо, купа додаткової обробки та складнощів.

⭐️ Що ж зробили розробники?

Спочатку вони думали пересилати дані у вигляді простих TCP/IP пакетів по мережі. Але знову ж таки - ці пакети дуже обмежені за розміром. Плюс - треба буде компіювати ці пакети з user-space в kernel-space (згідно з тим, як працює мережевий стек Linux). Так само, доречі, потрібно було б робити у випадку використання нативних доменних сокетів Unix.

Врешті-решт розробники знайшли вихід - використати Shared Memory - тобто памʼять, яка може використовуватись декількома процесами одночасно. Chromium записує туди блоки даних. а відео сервіс зчитає ці дані для подальшої обробки.

В Rust є імплементації для цього: circular-queue, ringbuf, ringbuffer, ring_queue, dasp_ring_buffer.

Але розробники recall.ai зробили свою кастомну версію алгоритму ring-buffer. Чому - бо їм треба було мінімізувати копіювання даних. Деталі - можна почитати в самій статті.

Таким чином, вони змогли зекономити близько мільйона доларів витрат на AWS на рік.

🤖 Automation Is Not Quality, And Never Was

#testing #automation

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

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

Чому автоматизації недостатньо?

1. Автоматизація перевіряє тільки те, про що знає (те, що ви написали в коді, не більше). Зелений пайплайн не означає, що продукт працює. Це лише означає, що автотести успішно виконані.

2. Коли менеджмент хоче швидких результатів, то, часто, автоматизують не те, що важливо, а те, що найлегше автоматизувати. До того ж, інженери концентруються виключно на UI тестах - бо результат легше показати менеджерам (ніж якийсь код в консольці).

3. Як тільки автотест написаний - люди вважають, що сценарій "покритий" повністю. Але якість залежить від того, яку нову інформацію віднайшли під час тестування. Навіть того кейс, який вже автоматизований.

4. Менеджмент ганяється за метриками покриття - покриття коду, покриття вимог. Але забуває про те, що автоматизація - це не просто про покриття чи запуск тестів. Це - про відповідальність.

5. Коли на проєкті мало flaky тестів - на них "забивають". Коли їх стає занадто багато - ніхто не довіряє СІ. Команда звикає ігнорувати сигнали від таких тестів.

Коли автоматизація підсилює мислення тестувальників - вона допомагає будувати впевненість. Якщо ж автоматизація замінює мислення тестувальника - то підсилюються тільки помилки.

Звичайно, у вас на проєкті все не так. У вас цінують тест інженерів. Прислухаються до них. Та не концентруються виключно на автоматизації. 😀