Test Engineering Notes

⭐️ The Next Two Years of Software Engineering

#engineering #career #ai

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

👶 1. Джуніори

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

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

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

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

✏️ 2. Навички

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

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

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

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

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

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

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

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

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

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

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

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

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

🎓 5. Освіта

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

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

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

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

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

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

#ai #llm #learning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#books #testing

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

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

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

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

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

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

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

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

📚Що почитати з технічного (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. Обидві книжки хороші для лідів початківців. Друга напевне більш проста (й реально дешевше).

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

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

#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”? Чим ви займаєтесь, крім тестування?

Шановні, улюблені та найкращі підписники цього каналу! 🎼

Нарешті можу трішки відкрити інформації про нашу "Сувору QA Конференцію", яка відбудеться в березні наступного року!

🗓 Що по датах і формату?
🛑 9-13 березня 2026, онлайн. (ТАК, 5 ДНІВ!)
🛑 Тематика конференції: Артефакти тестувальника

Ми розробили конфу так, щоб ми змогли і послухати, і переварити, і поспілкуватися. Тому щодня у нас буде 2 блоки: ранковий о 10:00 та вечірній о 19:00.

🌟 Хто Буде Ділитися Знаннями?
Наш поточний спікер-лист:
- Олександра Ковальова, Senior QA Consultant
- Марина Дідковська, Senior Director QA Engineering @ EPAM
- Павло Сафонов, AQA Lead @ Sitecore
- Олена Тесленко, QA Team Lead @ Patrianna
- Інна Двойнікова, Senior QA Team Lead, Freelance
- Олексій Бакунін, QA Lead, Release Manager @ Edge

❗️Важливий момент:
Квитків по Early Bird ціні — всього 50 штук! (ЗАЛИШИЛОСЬ 25 24!)🏃‍♀️

Ми чесні: на сайті ми ще трохи допрацьовуємо деякі деталі (ну, ви ж знаєте, без багів нікуди 😅). Ваш фідбек — надзвичайно цінний. Якщо щось знайдете або маєте ідеї, пишіть мені сюди в канал! 🥰

👉 Вся інфа та квитки тут: https://conference.grygorenko.tech/

Зустрінемось 👻

Шо там по ЗП?

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

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

📖 Taking Testing Seriously - Огляд 3

#testing #books #takingtestingseriously

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#testing #engineering #ai

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

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

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

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

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

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

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

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

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

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

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

🧰 Проблеми з ШІ інструментами з точки зору інженера - Частина 2

#testing #engineering #ai

Продовжую роздуми про те, які є проблеми у використанні інструментів ШІ в роботі тест інженера.

🧱Проблеми вайб-кодингу

Минулого разу ми розібрали такі проблеми як галюцинації, надмірну впевненість та цикли перефразування.

Усі више перераховані проблеми в недосвідчених руках призводять до ще більшого технічного боргу. Бо коли раніше сіньйор додавав новий код, він спирався на розуміння архітектурних паттернів та наявність готових рішень в продукті. ШІ просто “підставляє” найбільш ймовірний шматок код для вирішення задачі тут, на місці.

Чому це погано?

👉 Новий код може бути дублікатом існуючого
👉 Новий код може додавати зайві рівні абстракції
👉 Новий код може погано інтегруватись з іншими наявними системами та API

Але крім цього є інша проблема …

🎓Парадокс когнітивного спрощення

Andrew Stellman розповідає про парадокс та наводить приклад того, як різні інженери застосовують ШІ.

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

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

Сінйьори за допомого ШІ:
- роблять швидкі прототипи
- генерують "фреймворки" для автоматизації
- досліджують та оцінюють різні варіанти імплементації алгоритмів
- автоматизують рутинні задачі

Разом із тим, інженери початківці (не усі!):
- комітять непрацюючий та нетестований код
- пропускають купу багів в безпеці та перфомансі (крім функціональних)
- швидко будують крихкі рішення, які не розуміють

👨‍🔬 Так що робити?

Парадокс когнітивного спрощення додає новий складнощів для тих, хто буде вчити й вчитися кодити в 2025му році. То ж навички критичного мислення при написанні коду будуть вкрай важливими.

Це все не означає, що не треба користуватись інструментами ШІ. Це також не означає, що треба вчитись як “діди” - без ШІ, без гугла - та писати код виключно на листочку.

Просто треба навчитись як користуватись ШІ без ризику втрати розуміння.

🕶 Framework vs. Solution

#testing #automation

Часто бачу у кандидатів в резюме та на співбесіді таку фразу - “я маю досвід побудови тестових фреймворків з нуля”. Інколи це правда. Але в багатьох випадках кандидат має на увазі трохи інше, а саме - test automation solution.

Але в чому різниця? Давайте похоліваримо (бо у кожного своє розуміння)!

📖Що нам говорить книга “Test Automation Fundamentals”?

A test automation solution (TAS) is a specific instance of a TAA* and consists of the test environment and its corresponding automated testware. The latter includes automated test cases (which may be grouped into test suites), test data, and specific configuration files. A TAS is therefore not a monolithic tool or framework, but rather a combination of tools, components, and testware brought together for the purpose of automating testing processes.

* TAA - test automation architecture

A test automation framework (TAF) can, however, be used to provide a test environment, tools, test libraries, or additional test frameworks that can then be reused for faster automated test creation and execution.

🌐 Що говорить Wiki?

A test automation framework provides a programming environment that integrates test logic, test data, and other resources. The framework provides the basis of test automation and simplifies the automation effort. Using a framework can lower the cost of test development and maintenance. If there is change to any test case then only the test case file needs to be updated and the driver script and startup script will remain the same.

❗️Окей, але що з того?

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

Наприклад тестові фреймворки JUnit, TestNG, pytest, Jest - можна використовувати для написання тестів для web, mobile, api та інших систем.

Приклади фреймворків в розробці: Spring, Hibernate в Java, Django, Flask, FastAPI в Python, React, Vue, Angular в JS.

Деякі великі компанії, яким треба автоматизовувати купу ідентичних проєктів, можуть розробляти свої фреймворки, заточені під потреби цих компаній. Або ж для уніфікації підходів, інструментів та знань.

💡Солюшен (рішення) - це застосування тестового фреймворку + купи додаткових утиліт, тестових даних, запуск на CICD чи в контейнерах на хмарах, репортинг. Та що найголовніше - набір тестових даних, клієнтів та тестів заточених під конкретний продукт.

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

В усіх інших ситуаціях, коли ви пишете кастомну автоматизацію під конкретний проєкт - ви не пишете фреймворк. Ви вирішуєте проблему. Ви з готових частин, наче конструктор Lego, складаєте солюшен та пишете автотести. Навіть - коли ви робите це "з нуля".

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

🎓Висновки

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

Але якщо ви написали аналог pytest чи JUnit - тут ви безперечне написали фреймворк.

Але памʼятайте - що автоматизація тестування повинна починатися з питання - а яку проблему ми вирішуємо за допомогою цього солюшену? (Привіт Артем!)

А ви пишете фреймворки чи солюшени?

🪲 Чому впав Cloudflare?

#bugs #sql #rust

Минулого тижня пів інтернету лежало через те, що сервіс Cloudflare впав та був недоступний якийсь час.

Але чому це сталося? Чи винні в цьому тестувальники? Чи справа в … коді на Rust?

Відповідь не така проста, як здається.

🎓 Як обробляються запити в Cloudflare

Усі запити на Cloudflare проходять через основний проксі сервер. На цьому сервері є багато модулів, що виконують перевірки безпеки для захисту від DDoS атак. Зокрема, такий модуль як Bot Management.

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

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

🏫 В чому виникла помилка?

За замовчуванням, фічі отримують розподіленим запитом у базу даних “default” у кластері ClickHouse. У користувача був доступ тільки до цієї бази.

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

Зміну в налаштуваннях зробили, але … не перевірили сам SQL запит.

SELECT
  name,
  type
FROM system.columns
WHERE
  table = 'http_requests_features'
order by name;

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

То ж файл з фічами для Bot Management мав купу зайвих дублікатів фічей.

🕶 Ну то й що?

Виявляється, що для обробки фічей попередньо резервується оперативна памʼять. Зазвичай, у файлі було десь 60 фічей при максимумі в 200.

Але коли сталася помилка - у файлі фічей було більше ніж 200!

То ж серверу не вистачало памʼяті, щоб обробити ці фічі. Окей, не вистачило памʼяті, це погано - але чому так довго шукали проблему?

А код на Rust, який обробляє ці фічі … не обробляв таку помилку - а просто кидав базовий Error за допомогою unwrap();

    pub fn fetch_features(&mut self, input: &dyn BotsInput, features: &mut Features) -> Result<(), (ErrorFlags, i32)> {
        features.checksum &= 0xFFF_FFF_000_000;
        features.checksum |= u64::from(self.config.checksum);
        let (feature_values, _) = features
            .append_with_names(&self.config.feature_names)
            .unwrap();
        //
    }

То ж код почав видавати дуже загальну помилку.

Плюс файл із фічами швидко розлетівся по серверам - й вони також збоїли по тій же самій причині.

💡 Що можна було б зробити?

👉Більш ретельно обробляти помилки. Rust як мова програмування в цьому випадку не винен.
👉Тестувати запити на тестових серверах (включно з лімітами по памʼяті). Можна було б досліджувати як система обробляє дані великих розмірів.

❗️Більш докладно про збій можна почитати в офіційному блозі компанії.

🧰Проблеми з ШІ інструментами з точки зору інженера - Частина 1

#testing #engineering #ai

ШІ повсюди. ШІ вже тут. Стережися ШІ!

Останній рік (чи може трохи більше) помічаю ажіотаж з використання ШІ.

⚡️ Лідери думок говорять на конференціях, що ШІ вже тут та забере наші робочі місця
⚡️ Менеджмент давить на лідів, щоб вони скоріш впроваджували ШІ де тільки можна
⚡️ Курси пропонують “чарівні” таблетки для тестувальників у вигляді підбірки промтів на всі випадки життя
⚡️ Деякі блогери пропагують вайб кодинг - як майбутнє програмування й тестування

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

🎓Чому мені то цікаво?

Мої колеги та знайомі користуються ШІ кожного дня. Я сам користуюся ChatGPT, Claude, Perplexity, Gemini, Cursor. Пробував також Github Copilot.

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

До того ж - треба вміти користуватися тими інструментами ефективно.

💡 Що таке вайб кодинг?

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

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

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

🕶Проблеми з вайб кодингом та сучасними ШІ (LLM-ками)

Але сила вайб кодингу приходить із відповідальність (а точніше із проблемами ШІ):

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

👉 Надмірна впевненість. Девелопер з часом сприймає будь-які результати ШІ як правильні. Цим грішать навіть досвідчені інженери.

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

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

Але це ще не всі проблеми. Бо є парадокс когнітивного спрощення. Що це таке - вже в наступному пості.

📖 Taking Testing Seriously - Огляд 2

#testing #books #takingtestingseriously

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

Продовжуємо огляд книги Джеймса Баха та Майкла Болтона. Сьогодні я коротко розповім про вам про розділ 2 під назвою "Foundation"

💡Що таке тестування (згідно з авторами книги)?

Тестування - процес оцінки продукту шляхом вивчення його через досвід, дослідження та експериментування з ним.

Ключове тут саме "оцінка .. через вивчення". Тестувальник збирає докази під час тестування, фільтрує їх та конструює історію про те, що сталося та що це означає.

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

В методології "Rapid Software Testing" існує різниця між тестуванням (testing) та перевіркою (checking). Тестування може зробити тільки досвідчена людина. Перевірку - може зробити машина. Можна провести паралель із програмуванням та компілюванням. Програмують люди, а машина потім компілює код.

Доречі - не існує ручного чи автоматизованого програмування. Є програмування (із застосуванням інструментів). Як тільки інструмент працює достатньо надійно - це не називають програмуванням. Називають компіляцією, статичним аналізатором коду, тощо.

Так само є тестування із застосуванням інструментів. А є - автоматизовані перевірки. Автори розділяють тестування та перевірку тому, що не існує "автоматизованого тестування".

Чи значить що з ШІ програмісти стануть не потрібні? Відповідь - ні, бо ШІ не несе відповідальності за код, який згенерувало. Це задача програміста інтегрувати та перевірити код, що написаний машиною.

🎭 Різниця між тестуванням та виконанням тесту

Автори відмічають, що

тест - це зустріч із продуктом, що становить тільки один з епізодів тестування.

А також:

Тест - це наче сценарій пʼєси, що написав драматург. Тестування - це те, що роблять актори на сцені.

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

На цьому все. До зустрічі в наступному пості.

📹 Як обрати собі школу тестування

#testing #video

🏫 Вчора, в огляді на книгу Баха й Болтона, я згадав такі штуки, як школи тестування.

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

❗️І так, ЦЕ НЕ ПРО КУРСИ 😀

Taking Testing Seriously - Огляд (1)

#testing #books #takingtestingseriously

На минулому тижні я прочитав нову книжку від Джеймса Баха та Майкла Болтона під назвою "Taking Testing Seriously".

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

🎓Про що ця книга?

Коротко - книга розповідає про методологію тестування, якої навчають автори книги. Методологія ця називається "Rapid Software Testing". Курси з неї Бах та Болтон ведуть вже більше двох десятків років - то ж щось в цьому мабуть є.

📖 Розділ 1 - Why Another Book About Testing?

У першому розділі автори розмірковують - нащо вони написали "ще одну" книжку з тестування.

Спочатку, автори знайомлять нас з різними школами тестування: factory, quality, agile, analytical, context-driven. (А ви чули про такі школи тестування? Якщо ні - можу більше про них розповісти)

💡Rapid Software Testing є методологією контекстно-орієнтованого тестування.

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

- Автори порівнюють тестування на проєкті із фарами автомобіля. Фари не сповільнюють рух авто, так само й тестування не сповільнює проєкти. Тестування, навпаки, дозволяє проєктам рухатися швидше.
- Щодо того, щоб запобігати багам, замість тестування - автори задають питання: а як ми зрозуміємо, що запобігли усім багам?
- Майкл та Джеймс також зазначають, що тестування - це пошук правди про продукт. Деякі люди не бажають знати правду - бо знання правди створює відповідальність. Тож деякі менеджери сподіваються, що тестери не знайдуть ніяких багів. Або ж звинувачують тестувальників в тому, що вони знайшли баги. Як результат - тестери починають репортити менше багів, щоб отримати менше звинувачень.

Також автори зазначають, що використання GenAI та підходів типу vibe coding додає ще більше роботи з тестування. Як розробникам, так і тестувальникам. (З цього приводу напишу окремий пост, бо якраз досліджую це питання).

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

Починаю читати свіжачок. Цікаво, що там діди (Michael Bolton & James Bach) написали.

P.S. Огляд та розбір буде згодом.

Чи потрібно отримувати сертифікат ISTQB?

Я й сам не знаю 😀!

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

📅 Коли: 25 жовтня
💻Де: онлайн
💡Скільки коштує: безкоштовно

Не забудьте зареєструватись 👉 https://certifiedunicorns.pro/hot-istqb-conference