🐙 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 тестів - на них "забивають". Коли їх стає занадто багато - ніхто не довіряє СІ. Команда звикає ігнорувати сигнали від таких тестів.

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

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

✍️ Підбірка цікавого про Modern Testing

#testing #leading

Про modern testing я писав декілька років тому. А ще - розповідав в доповіді про школи тестування.

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

• Quality Culture Transition Guide - цікава модель, що допоможе оцінити рівень культури тестування у вас в команді чи організації. Є у вигляді таблиці чи шаблону в Miro.
• Team's Quality Culture Model - шаблон для оцінки культури на рівні конкретної команди. Приклад застосування є в окремій статті.
• Modern Testing Mind Map - мапа для тих, хто хоче копнути глибше в сучасне тестування

А ви знаєте про modern testing? 🤓

RIMGEN - фреймворк, що допоможе краще репортити баги

#testing

Буває так, що баги повертають назад з міткою "Unable to reproduce" чи "Not a Bug".

Для того, щоб таких ситуацій було менше, Cem Kaner пропонує фреймворк RIMGEN.

• R - Replicate. Перевірте, що помилка відтворюється згідно кроків у баг репорті.

• I - Isolate. Знайдіть найкоротший шлях відтворення багу. Які критичні умови для відтворення?

• M - Maximize. Знайдіть більш серйозну проблему, про яку свідчить баг.

• G - Generalize. Подумайте, чи не впливає проблема іншими способами (різні шляхи відтворення)

• E - Externalize. Підкресліть, на кого та як вплине помилка (зручність, критичність, втрата цінності)

• N - Neutral Tone. Пишіть баг репорт в нейтральному тоні та так, щоб його було легко читати.

🤖 Чи зникнуть розробники та при чому тут Сімпсони

#engineering #ai

Приніс вам обнадійливу статтю про те, як змінюється розробка прямо зараз. Її автор - Mike Arnaldi, СЕО, але який пише код.

❓Яка модель краща?

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

З того, що відомо на загал це Ralph Wiggum (герой мультсеріалу Сімпсони) процес, що нещодавно завірусився в X.

💡Що таке Ralph Wiggum процес?

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

1. Напишіть Bash скрипт, що буде виконуватись в циклі - визначену кількість разів.

2. На кожній ітерації агент працює над реалізацією однієї задачі.

3. Після виконання - перевірте, чи задовільняє реалізація поставленій умові. Це може бути умови у вигляді текстового опису, TODO листа, або навіть PRD документ (у вигляді JSON файлу з конкретними вимогами).

4. Після виконання задачі, агент повинен закомітити роботу та додати опис виконання в local_progress.txt. Цей файл використовується як вхідний параметр в наступній ітерації.

5. Додатково - поставьте агенту умову тримати CI зеленим - шоб усі тести проходили, як і раніше.

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

⭐️ Так чи зникнуть розробники?

Mike наводить декілька прикладів. В одному він самостійно будує аналог терміналу для аналізу фінансових операцій, вартістю десь 30K$ на місяць. В іншому прикладі - його знайомий юрист, без знання програмування - написав програму для перевірки полісі на відповідність GDPR.

Автор приходить до думки, що software development до якого ми усі звикли - майже зникне. А от software engineering - навпаки.

Задача інженера буде дизайнити системи на рівні архітектури та продуктових вимог. Паттерни та підходи до розробки в такому випадку звичайно еволюціонують. Як один з прикладів - системи будуть описуватись на таких мовах як Lean чи TLA+. А агенти вже будуть писати код.

А ви як думаєте? Чи правий автор? Які ваші підходи до використання агентів?

🤖Тестування ШІ 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 - це і є перевірка припущень