🤖Тестування ШІ vs Тестування з ШІ

#testing #ai

Jeff Nyman випустив цикл статей AI and Testing для тих, кому цікаво саме тестувати ШІ моделі. А не просто користуватись інструментами. Пости великі та потребують часу для опрацювання, але це СКАРБ та MUST-READ. Статті дають доволі непогані знання про те, як працюють моделі та найголовніше - як їх тестувати.

📝Статті:

• Ollama and Models
• Local LLMs and LangChain
• LangChain Templates
• LangChain Messages
• LangChain and Orchestration
• A Testing Example
• Refining Tests
• Refactoring Tests
• Scaling Tests

❗️Крім того, Jeff поділився своїми думками про навички тестувальників - "AI and Testing: Personal Marketability" Цю статтю я теж дуже раджу почитати.

💡 Ділюся основними моментами:

• Коли у вакансії бачите "потрібен досвід з ШІ" то, зазвичай, це вміння користуватись інструментами ШІ для тестування (автоматизації). Дуже рідко зе значить саме тестування ШІ.
• Курси зараз в основному вчать першій категорії навичок. Але вивчаючи як тестувати ШІ ви так чи інакше вчитесь працювати з ШІ інструментами ефективніше.
• Важливі обидві категорії навичок.

⭐️ Що значить хороший тест кейс для ШІ?

• Тестування узгодженості в умовах суперечливої інформації
• Тестування задовільного рівня невизначеності
• Перевірка на дисперсія при однакових умовах
• Перевірка межі між знанням та висновками (міркуваннями)

🐙 Й головне:

There’s understandable anxiety in the testing community about AI replacing testers. (Just as there is for developers.) But here’s what that concern misses: the skills that make you good at testing are exactly the skills that make you valuable in an AI-augmented world. That’s the case whether you’re using AI to assist your testing or testing AI systems themselves.

Quality and test specialists have always needed an eye for spotting ambiguity, inconsistency, and contradiction. You look at a requirements document and notice where two statements can’t both be true. You examine a user interface and spot where the behavior contradicts the stated intent. You read test results and detect where the data doesn’t align with expectations. This isn’t a skill AI replaces. It’s a skill AI desperately needs applied to it.

“Page Object не врятує: архітектура фреймворку, яка реально масштабується”

«А сьогодні в завтрашній день не всі можуть дивитися. Точніше, дивитися можуть не тільки всі, мало хто може це робити.»

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

Коли: 18 лютого о 18:00 за Києвом
Формат: онлайн, лінка на ютуб трансляцію прилетить на пошту

До зустрічі!

💡 The Great Software Quality Collapse: How We Normalized Catastrophe

#engineering #testing

Denis Stetskov у своєму пості розповідає про проблеми з якістю, з якими індустрія стикнулася ще до ШІ. Та як ШІ ці проблеми прискорює та максимізує.

В якийсь момент усім стало важливіше додавати нові фічі, ніж слідкувати за якістю та ефективністю.

🔢 Просто цифри

Сучасним системам не вистачає оперативної памʼяті. Постійно:

• Apple Calculator - 32 Gb
• VS Code - 96 Gb
• Google Chrome - 16 Gb
• MS Teams - 32 Gb
• Discord - 32 Gb (за 60 секунд показу екрану)
• Spotify - 79 Gb

Це витоки памʼяті, які не поспішають фіксити. Взагалі, багато сучасного софту випускається за принципом: релізь зараз, фікси потім. Можливо, коли буде час чи пріорітет.

Приклад CrowdStrike памʼятають усі. В чому була проблема? Система впала, тому що в файлі конфігурації було 21 поле замість 20ти. Автотести цього не помітили.

🤖 А що з приходом ШІ?

ШІ зробила усі наявні проблеми тільки гіршими та швидшими. Й додало нових задачок.

Автор наводить такі приклади:

• ШІ код має 322% більше вразливостей безпеки
• 45% вразливостей в ШІ коді можна використати
• Джуніори з ШІ спричиняють в 4 рази більше проблем ніж без ШІ
• 70% менеджерів довіряють ШІ коду більше, ніж джуніорівському

We've created a perfect storm: tools that amplify incompetence, used by developers who can't evaluate the output, reviewed by managers who trust the machine more than their people.

❗️Чому ми маємо всі ці проблеми?

1. Абстракції (фреймворки) ховають складність та додаткові витрати ресурсів за "легкістю" використання. В реальності ми маємо втрати на кожному рівні з ланцюжку в простому калькуляторі: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways.

2. Софт пишуть так, наче витрати на електроенергію та hardware нескінченні.

3. Замість того, щоб виправляти проблеми в перфомансі, гіганти АйТі просто вкидують гроші в інфраструктуру. Auto-scaling - універсальна відповідь.

Але ніхто не задає важливі запитання. Чому для нас стало прийнятно, що калькулятору треба 32 Gb памʼяті? Що якщо ми не зможемо мати більше цієї памʼяті? Що тоді?

🤓 Додаткові проблеми з джуніорами

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

"Ми створюємо покоління розробників, які можуть написати промти, але не вміють дебажити; які можуть генерувати, але не можуть проектувати; які можуть доставляти продукти, але не можуть його підтримувати"

⭐️ Чи існує рішення?

Денис пропонує наступне:

• Прийняти, що якість важить більше ніж швидкість релізу.
• Міряти використання ресурсів, а не тільки кількіcть фічей.
• Відзначати інженерів, які зменшують використання ресурсів, а не збільшують.
• Обережно підходити до використання абстракцій (фреймворків)
• Вчити фундаментальні базові концепції з компʼютерних наук.

Рішення слушне. Але чи готова до цього індустрія? Я думаю, що ні.

Відкрита онлайн-зустріч для автоматизаторів “Page Object не врятує: архітектура фреймворку, яка реально масштабується”

🎥 Запис вебінару - “Page Object не врятує: архітектура фреймворку, яка реально масштабується”

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

🎁 Артур також лишив подарунок для тих, хто подивиться весь вебінар 🤓🤓🤓

❗️І ще одне. Не забудьте підписатись на канал Certified Unicorns - там завжди цікава інформація про ISTQB й не тільки.

⭐️ Що таке Ministry of Testing?

Привіт.

Цього року я став одним з амбасадорів Ministry of Testing. В цій спільноті я вже декілька років, то ж хочу розповісти й вам про неї. А головне - чому варто доєднатись.

Що таке Ministry of Testing? Це спільнота інженерів (та менеджерів) з якості. Людей, які раді ділитись своїми знаннями та робити світ більш якісним.

🎓 Але що конкретно можна знайти в Ministry of Testing?

👉 Статті, вебінари та доповіді на різні тестувальницькі теми. Від різних видів тестування та софт скілів, до автоматизації (й суміжних тем).

👉 Купу локальних подій в різних містах по всьому світу разом із головною конференцією року - Motacon

👉 Сертифікації по тестуванню, інженерії якості, а також - з автоматизації

👉 Місце, де можна почитати найновішу інформацію з блогів й поділитись нею з іншими

👉 Форум, де можна задати питання й отримати відповіді від дійсно глобальної спільноти

👉 Послухати інтервʼю з цікавими людьми з індустрії тестування - Into the Motaverse

👉 Спілкуватись з іншими тестувальниками на щотижневій онлайн зустрічі - "This Week in Quality" (Мене там теж можна почути час від часу) Можна почати навіть сьогодні, о 15й.

В Ministry of Testing дійсно тепла й затишна атмосфера. Але, спілкування тут англійською - то ж можна прокачати свій скілл сприйняття мови на слух. Доєднуйтесь - тут.

🤯 No-As-A-Service

#engineering

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

Просто відправте GET запит на https://naas.isalman.dev/no (або відкрийте в браузері)

Наприклад:

curl https://naas.isalman.dev/no

{"reason":"Thank you for thinking of me, but I'm going to decline hilariously."}

або

curl https://naas.isalman.dev/no

{"reason":"I made a deal with a demon to never say yes, and I hate to break a contract."}

або

curl https://naas.isalman.dev/no

{"reason":"How about I promise to think about it? (I won't, but it sounds polite.)"}

Сервіс можна запустити навіть локально

🧪Про тестування, яке запобігає помилкам

#testing

Цікаву думку висловлює Wayne Roseberry в своїй книзі "Drawn to Testing Again". Думка настільки проста й очевидна, наскільки можна.

🤯Тестування запобігає помилкам

Час від часу в тестерських спільнотах можна почути фразу

"тестування запобігає помилкам!"

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

Для того, щоб запобігти чомусь, запобігання повинно передувати існуванні самої речі. Тестування, як процес, виявляє помилки (баги) через спостереження. Цей процес описує те, що існувало до самого спостереження.

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

😏Тестування - причина виправлення баги

Гаразд, але ж можна сказати, що саме тестування стало причиною виправлення помилки!

Тут теж є про що подумати ...

Коли ми тестуємо, ми надаємо інформацію про стан продукту та повідомляємо людям про помилку.

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

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

Крім того:
- команда може вирішити не виправляти помилку взагалі та прийняти цей ризик
- девелопер, що фіксить багу, може зробити нову помилку

😤Тестування - необхідна умова для виправлення баги

Гаразд, але тестування ж є необхідною умовою для рішення й виправлення баги!

Але це - теж є хибним твердженням.

Девелопер може сам знайти та пофіксити багу. Девелопер можу пофіксити багу ... зовсім випадково. Бізнес вимоги можуть змінитись таким чином, що бага перестає бути проблемою.

Все це не означає, що тестування непотрібне. Але те, що тестування не запобігає помилкам - це точно.

А ви як думаєте?

🗓 5-денна QA конференція від Суворої QA Community! 🎤

Багато років тому, коли я працював вже тестувальником в зеленому банку, мене позвали на співбесіду в одну ІТ компанію. Я був дуже впевнений у собі, бо мав вже деякий досвід (й начитався пару книжок). Але, я ... провалився - бо не зміг відповісти на просте питання: "Які артефакти тестування ти знаєш?" (Роботу я все ж таки отримав, але трохи згодом 🤓).

То ж щоб не провалитись на інтервʼю - пропоную доєднатись до QA конференції й розібратись з питанням артефактів раз і назавжди 😏

Хто там буде?

10 топових спікерів з EPAM, Edge, Patrianna, Sitecore та інш

А в мене нема цілого дня на доповіді!

Зручні слоти доповідей - (10:00 та 19:00)

Так це ж просто відео!

5 днів достатньо, щоб не просто мовчати в чаті, а знайти корисні знайомства.

БІЛЬШЕ ДЕТАЛІВ!

📅 Коли: 9–13 березня
📍 Де: Online
🎯 Для кого: Від Junior до Senior (рівень контенту дозволяє кожному знайти свій профіт).

Квитки ОСЬ ТУТ

P.S. А за промокодом romanov можна отримати знижку в 20%!

👨‍🎓 Навчання та навички в епоху ШІ 👩‍🎓

#ai #learning #testing

Усі навкруги в ІТ використовують ШІ. Запускають агентів в паралелі. Генерують тести та тест плани. Пишуть автотести за два кліки.

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

😤 Чи мене замінить ШІ? Коли мене замінить ШІ?

Щоб зрозуміти, чи замінить вас ШІ, треба проаналізувати Вашу роботу та відповісти собі на декілька запитань.

👉 Технологічні обмеження. Чи моя робота зараз в безпеці тільки тому, що ШІ не може виконати її прямо зараз, чи взагалі? Є фундаментальні речі, які поточна архітектура ШІ не зможе вирішити найближчими роками.

👉 Складність. Наскільки складні та глибокі з точки зору контексту проблеми я вирішую? Наскільки багато ресурсів та прикладів є в наявності? Складні теми, які потребують глибокого аналізу поки віддаються людям, а не машинам.

👉 Ризики. Наскільки ризиковано для бізнесу довіряти ШІ, а не Вам, як експерту? Работодавці зараз починають вимірювати людей у порівнянні з ШІ. Якщо ШІ дає 5% ризику й бізнесу це ок - то нема сенсу залучати експерта. Але якщо експерт зменшить ризики ще на 3 - 4%, які будуть коштувати більше, ніж витрати на нього - бізнес додасть експерта разом з ШІ.

🤔 З ШІ стало ... складніше навчатись?

Професійні навички застарівають. Згідно з деякими джерелами, близько 25-30% навичок застаріють через 3 роки. Деякі експерти кажуть, що й до 70% навичок перестануть бути актуальними через 3 - 5 років!

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

Щоб збудувати навички, треба час. Бізнес з приходом ШІ очікує, що ви будете робити й вміти все більше й більше. Планка вимог підіймається швидше, ніж ми можемо ці навички здобути. Щоб бути зменшити ризик звільнення, треба бігти швидше, ніж збільшується розрив Вашими навичками та вимогами работодавця. Це - наша реальність.

😱 Що робити?

💡 Зрозумійте, що вміння ефективно вчитися - це теж навичка. Навичка, якої треба навчитись.

💡 Користуйтеся ШІ, як допоміжним засобом в навчанні. Наприклад, ChatGPT (Study Mode) або краще - NotebookLM. Але памʼятайте - ШІ не зможе вбудувати нові знання у вашу картину світу. Це не можна "віддати в аутсорс" машині.

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

💡 ШІ може допомогти із першими рівнями навчання за Блумом: знання, розуміння та застосування. Для здобування й закріплення навички треба ще й аналізувати, оцінювати та синтезувати нові знання.

Що запитати в архітектора, якщо ви тест інженер?

#testing #architecture

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

🤯 Отже, вас запросили на планування нової системи чи окремої функціональності. Що робити???

1️⃣ По-перше - подивіться на архітектурну діаграму компонентів. Зрозумійте як працює система. Не бійтеся задавати питання про частини, які ви не розумієте.

2️⃣ По-друге - ви можете задати наступні питання (як приклад):

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

Загальний підхід - обираєте компонент та обговорюєте його роботу в умовах повної або часткової недоступності.

Головні два питання, які треба задати:

💡 Як це може впасти й вплинути на роботу системи?
💡 Як ми це будемо тестувати?

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

🤔 Наскільки надійні ваші очікування?

#testing #criticalthinking

Отже, вам треба тестувати, а значить, треба порівняти очікуваний результат з поточним. Зазвичай очікуваний результат прописаний в самому тесті (чи в чеклисті). Але коли ми створюємо тести самостійно - треба визначити цей очікуваний результат. Але як? Допоможуть оракули.

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

Окей, я відкрию специфікацію та візьму очікуваний результат звідти!

Якби ж то було так просто!

Не такі прості, як здається

Дуже невелика кількість тестувальників сьогодні тестує прості й тривіальні проєкти на одну сторінку. Як правило, ми тестуємо великі й складні системи. Подекуди - розподілені.

В складних системах часто дуже складно однозначно визначити коректний очікуваний результат. Чому?

👉 Система може включати компоненти с AI / ML, які мають ймовірнісну природу (не дають одної правильної відповіді)

👉 Коректна відповідь може залежати від рішення більшості учасників, як-от в блокчейнах

👉 Система може мати остаточну узгодженість (eventual consistency) - тож зміни в базі даних можуть бути недоступні усім користувачам одразу (але, можливо, колись, у майбутньому будуть доступні).

Головна проблема оракулів - що не існує ідеального оракула. Треба їх комбінувати (разом із здоровим глуздом).

Що комбінувати?

Які бувають оракули?

🧪 Оракулів може й не бути. Тестування й розробка ведуться в стилі "виглядає нічо так, деплой!" Як результат - може бути купа схованих багів та проблем. А може й не бути.

🧪 Вимоги. Священна книга усіх тестувальників. Єдина й неповторна. Як там сказано - то є правда. Але справжні тестувальники знають, що вимоги можуть бути неповними, неправильними та й взагалі застарілими. В такому випадку не забуваємо задавати собі питання: "А ця специфікація взагалі коректна?"

🧪 Консистентність (узгодженість). Можна порівняти поточні результати із подібними в інших компонентах. Або ж замість вимог можна мати інваріанти - тобто опис властивостей системи, які повинні завжди виконуватися. Наприклад - "Баланс не може бути негативним" або "Користувач завжди має імʼя та прізвище".

🧪 Статистичні оракули. Базуються на статистиці вашого домену чи типу аплікації.

Окей, оракулів багато, вони ненадійні. Що робити?

Питання для підозрілого тестувальника

Коли ви визначаєте очікуваний результат, можна задати собі (й команді) наступні питання:

💡Що означає коректний результат в контексті вашої системи? Числовий, логічний, ймовірний?

💡На яких припущеннях побудований оракул? Наприклад - "за правильними даними йдіть у базу даних". Але якщо база даних - застаріла чи пошкоджена?

💡Які властивості системи чи атрибути якості непокриті оракулом? Може, ви забули про безпеку, перформанс, доступність?

💡Наскільки надійний сам оракул? Яка ймовірність? На чому будується ваша довіра?

Завжди памʼятайте: оракули ненадійні, ба більше - коректність оракулів може залежати від контексту.

Обґрунтовано сумніватися - це робота тестувальника.

😱 Як ми пропускаємо баги через наші припущення

#testing #criticalthinking

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

🤔 Що таке припущення та нащо їх аналізувати?

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

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

Припущення небезпечні, бо вони часто неявні, невидимі й перебувають поза зоною специфікацій. Ваше завдання при роботі із ними - перетворити твердження “Ця фіча працює” у щось, типу “Це працює тоді й тільки тоді, коли ось такі припущення виконуються”. У голові розробника, який пише код, вирує багато питань. Одне з них: “Ця функція повинна завжди повертати таке значення”. Тестувальник же повинен починати з питання: “А що, якщо … не завжди?”

📔 Які бувають припущення

• Припущення щодо даних. У роботі часто можна почути: “Вхідні дані завжди будуть типу Х чи формату У”. У реальності ж дані можуть бути порожніми (NULL, порожній масив) чи навіть неочікуваного типу.

• Припущення щодо середовища. Продукт не працює у вакуумі. Саме тому ніколи не можна сказати, що середовище буде “нормальним”. Мережа завжди може бути нестабільною; пакети та підключення можуть втрачатися; трапляються збої. Тож потрібно тестувати поведінку системи в таких умовах.

• Припущення щодо часу та порядку. “За івентом покупки завжди прилітає івент оплати”. В реальності події можуть приходити одночасно, або в зовсім іншому порядку. Системи працюють асинхронно. Деякі функції потребують часу для виконання. Що тестувати? Паралельні івенти, затримки у отриманні, повторні спроби обробки.

• Припущення щодо інших систем. Інші системи поза зоною нашого контролю. Вони можуть відповідати частково або ж зовсім не відповідати. Вони можуть змінювати формати та версії. Треба бути до цього готовими (та, можливо, додавати контрактні тести)

• Припущення щодо поведінки користувачів. Користувачі не завжди поводяться логічно. Користувачі можуть робити речі навмисно. Тож треба тестувати неочікувані сценарії та безпеку

• Припущення щодо масштабування. У реальності сплески в навантаженні можуть траплятися не лише на свята. Вихід нових фіч, голосування на Євробачення, збір лимонів - все це вимагає тестування перформансу вашого продукту.

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

🛠 Як працювати із припущеннями

Як тестувати припущення? Знайдіть припущення та сформулюйте його. Далі - спробуйте порушити припущення. Додайте тестів, які перевірять поведінку системи при такому порушенні.

Можна застосувати такі техніки:

• Storming. Що завжди має бути дійсним? Що ми усвідомлено НЕ перевіряємо? Що ми сприймаємо як належне?
• “What If”. (Що якщо). Що якщо цей компонент не буде доступний? Що якщо респонс прийде пустий? Що якщо база буде відповідати повільно?
• Замість “Як це працює” замисліться про те “Як це може зламатись”

💡 Завжди памʼятайте

• Всі системи можуть зламатись, коли припущення порушені
• Будь-який happy path сценарій - сповнений купи припущень. Вам тільки треба їх знайти
• Тестовання edge cases - це і є перевірка припущень

🤔 Чому тестувальнику не варто плутати причинність та кореляцію

#testing #criticalthinking

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

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

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

😱 Окей, цікаво - але нащо це в тестуванні?

Часто ми можемо зустріти таку помилку (у себе чи в команді): “Ми зробили деплой версії 1.0.1 на продакшн, система зламалася — значить, причина у версії 1.0.1!”. В цьому прикладі можна побачити кореляцію між двома подіями (деплоєм та поламаною системою), але не обовʼязково причинність.

Чому? Бо ми працюємо зі складними системами з великою кількістю компонентів. Компоненти працюють одночасно; між компонентами існують явні та неявні залежності.

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

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

🤯 Як дослідити причинність виникнення помилок (багів)

👉 Намагайтеся відділити спостереження від пояснення. Замість швидкого рішення “Деплой спричинив збій” можна сформулювати події по-іншому: “Помилка сталася після деплою”.

👉 Задайте собі та команді просте питання: “А що ще змінилося в процесі деплою?”. Можливо, стався сплеск навантаження, або хтось змінив базу.

👉 Спробуйте сформулювати кілька можливих гіпотез (пояснень) щодо причини помилки.

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

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

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

Досліджуйте баги, шукайте докази причин і наслідків. Слова архітекторів та девелоперів про “тут так точно не може бути” - це не доказ.

Як GIF-ка з Рейчел майже зламала Discourse

#bugs

В Discourse помітили, що розміри бекапів виросли до сотень гігабайт. Унікального контенту в даних було мало. Більшість з них ... просто копії.

Проблема

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

Найчастіше це GIF-ки та картинки. Користувачі надсилають їх один одному як в повідомленях так і в коментарях.

Як пофіксили

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

Як GIF-ка зламала фікс

В процесі створення hardlinks дуже швидко досягли ліміту - 65000 посилань на одну inode. Деякі файли мали аж по 246173 копії. Який це файл? Виявилося, що це ... GIF з Рейчел з серіалу Друзі - яку дуже часто додавали як реакцію.

Пофіксили фікс шляхом трекінгу ліміту посилань в файловій системі.

🎉 Про Software Quality Engineering Certificate (SQEC) від Ministry of Testing

#certificate

🤔 Що в цьому сертифікаті?

👉 Детальний розбір того, що ж таке Quality Engineering (QE) та чим відрізняється від звичайного QA та тестувальників
👉 Які навички потрібні для сучасного QE
👉 Інженерія якості в різних процесах та командах
👉 Які існують помилкові уявлення про QE та як їх подолати
👉 Принципи інженерії якості та як оцінити свої наявні процеси
👉 Як створювати культуру якості в компанії
👉 Що значить Continuous Quality та як цього досягти
👉 Чи є майбутнє у QE, особливо в світі ШІ

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

Якщо ISTQB FL - це більш формалізований "вхід" в індустрію, то MoT SQEC - більш людино-орієнтований, "теплий", створений спільнотою тестерів. Формальності тут набагато менше, але більше прикладів реальних людей.

Як працює JVM?

#howitworks #java

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

Наприклад, вони питають як працює Java Virtual Machine у Java автоматизатора.

Приніс вам картинку, яка це пояснює. Тепер ви будете готові до цих питань.

Що робить JVM коли запускає ваш Hello World:

1. javac компілює ваш код в платформо-залежний байткод
2. Classloader додає необхідні базові класи JDK
3. Перевіряється безпека байткоду
4. Ініціалізуються статичні дані
5. Heap / Method Area доступні між потоками. Для кожного потоку створюється JVM stack, PС регістр та стек нативних методів
6. Інтерпретатор байткоду запускає ваш код. JIT компілятор виділяє частини коду, щоб зберегти в кеші
7. Ваша програма запускається як такий собі мікс інтерпретованого та JIT компільованого коду

Окреме питання, чи потрібно таке запитувати на співбесіді? Особливо на тест інженера. Як думаєте?

📚Про AI-Driven Software Testing

#books

🌊 Прочитав Проплив крізь книжку AI-Driven Software Testing.

Книжка на 99% виглядає згенерованою за допомогою ШІ. В кожному розділі суцільні повторювання одного й того ж. Особливо бісили картинки, згенеровані ШІ - ще й з помилками в тексті.

🤔Корисного з книжки - наче той кіт наплакав. Автор захопливо розповідає про те, як ми працювали до ШІ, та як з ШІ все стає краще, швидше та ефективніше.

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

Але багато з того, що ШІ може робити - людина теж може робити.

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

😤Сумніваюся в цьому.

😏 The AI Quality Paradox

#ai #testing #engineering

Цікава стаття від David Stockton в якій автор розмірковує про те, як насправді ШІ покращує якість продукту та швидкість розробки.

Гіпотеза:

"якщо ви вже компетентний інженер та дисципліновано користуєтесь інструментами, то з ШІ ваш код вже буде трохи кращим, ніж був два роки тому"

💡ШІ тільки посилює той рівень навичок та процесів, який вже існує в команді. Хороші команди прогресують швидше. Погані команди деградують також швидше. ШІ в цьому випадку відіграє роль, що схожа на Git чи CI.

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

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

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

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

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

А ви як думаєте?

В тестових спільнотах тільки й розмов, що про ШІ...

Менеджери "пушать" користуватись ШІ якнайшвидше. Рекрутери та інтервʼюєри очікують знання та вміння роботи з ШІ інструментами (й не тільки в резюме).
Крім того - на ринку безліч ШІ інструментів. Чи існує один інструмент, на якому варто зупинитись?

Можна гуглити самостійно. Можна проходити курси від вендорів.

А можна ... отримати сертифікат ISTQB CT-GenAI та отримати структуровані знання.

@certifiQAte запускають курс підготовки до сертифікації ISTQB Testing with Generative AI.

😱Хто? Тренери курсу - @VolodymyrKurenkov та @KaterynaAbzyatova допоможуть вам підготуватись.

🤔Що буде? LLM, RAG, промпти, ризики та ефективне впровадження ШІ на проєкт.

🎯 Плюшки: Знижка -20% від вартості іспиту у провайдера iSQI для студентів курса, а також - бокс з друкованим сілабусом, глосарієм, трекером, вайтбордом і всім, що потрібно для підготовки.

📅 Коли: старт 9 травня, щосуботи, обідній час, тривалість 2–2.5 місяці

👉 Реєстрація за посиланням (до 15го травня)