Test Engineering Notes

Vibe coding та реальність

#engineering #llm

Починаємо тиждень з трендів. Останнім часом чув багато хайпу щодо такого поняття як vibe coding. Це коли люди пропагують забити на складне навчання, а всю роботу віддати LLM. Штучний інтелект сам все зробить, а людині треба буде тільки "якось інтегрувати чи просто запустити згенероване".

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

P.S. Наші досвід та вміння ШІ поки не замінить. Поки ...

Тестування - дуже легко, що там вчити взагалі ...

#testing #roadmap

З одного боку наче в теорії тестування небагато всього. Процеси, техніки тест дизайну, інструменти.

А з іншого - тестувальнику можна (й треба) розширяти свій світогляд.

То ж дозвольте поділитись з вами класною схемою тем, дотичних до тестування, які можна вчити. (Не тільки автоматизація)

Посилання на постер в гарній якості - тут.

Why do we fail at interviews?

#testing #interview

Невелика стаття, де я розповідаю, чому нам зазвичай складно проходити співбесіди.
А як ви проходите інтервʼю? Чи вам легко відповідати на усі питання?

Integrated Tests Are Scam

#testing #engineering #automation

Хороша доповідь про те, чому писати end-to-end UI та інтеграційні тести - це шлях у нікуди (за думкою доповідача).

По факту, він розповідає, що юніт + контрактні тести зможуть майже на 100% замінити оці нестабільні високорівневі перевірки.

Про контрактні тести говорили ще 9 років тому!

Чи помирає BDD?

#testing

Знайшов доволі цікаву статтю про те, що ж таке то BDD, як воно виникло та чому воно помирає. Та чи зникне цей підхід взагалі?
Автор наводить приклади, куди можливо буде розвиватись BDD далі - це behavior development. Так, без ШІ не обійшлося.

Testing & Evaluating Large Language Models(LLMs)

#testing #ai #llm

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

- Part 1
- Part 2
- Part 3

Дуже цікаво подивитись на різні метрики для таких систем.

Пошук роботи в 2021 та 2025

#video

Начебто розважальне відео, але ...

Чи правда шаурма стає гіршою чим ближче до станції метро ...

#engineering #python

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

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

What would happen if we didn't use TCP or UDP?

#engineering #rust

Невеличкий експеримент щодо використання кастомних протоколів (відмінних від TCP та UDP).

Чи будуть такий протокол обробляти провайдери - такі як Digital Ocean чи AWS?

Що ж робити в такому випадку? 🕶

Треба прийняти декілька важливих умов:

1. Проходити співбесіди непросто - ринок жорсткий й вимоги високі
2. Бути хорошим спеціалістом не дорівнює легко пройти співбесіду
3. Мати десятки років досвіду не означає, що ви відповісте на будь-які питання інтервʼюєра
4. Підтримка навичок в актуальному стані - процес постійний. Бо від звільнень не застрахований ніхто.

👉 Загальні поради:

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

Це - непросто, навіть для сіньйорів.
З мок інтервʼю та підготовкою я можу допомогти. Пишіть в ДМ або в коментарі.

Про вміння працювати та проходити співбесіди

#interview

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

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

Знання для проходження співбесід - це окремий великий пласт знань. Який не завжди пересікається з вашим набором знань.

У кожного технічного інтервʼюєра свій власний багаж знань. Плюс - вимоги конкретної компанії до конкретної позиції.

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

А ще - знання та вимоги у кожного інтервʼюєра - різні.

Шо робити? 🔽

⚡️ Епізод 50: Відповідаємо на питання підписників

Чи потрібен Гітхаб для тестувальника? Які найголовніші навички QA, що приносять більше грошей? Чи переходити в розробку (бо там більше платять)? Коли AI замінить усіх? В цьому епізоді подкасту, Артем та Олександр відповідають на питання від підписників.

Дивитись та слухати:

🔸 Youtube
🔹 Spotify
🔸 Apple

Ваша підтримка важлива!
Ми постійно розвиваємося і рухаємося вперед, але це неможливо без вашої підтримки. Тому будемо вдячні за лайки, коментарі та будь-яку іншу форму підтримки. Це допоможе нам просувати наші подкасти в рекомендаціях. Також ви можете підтримати нас донатом — це дійсно важливо для нас і є нашим рушієм.

Дякуємо вам!

Підтримати подкаст можна через: 🏦 База від Монобанку

#testingminutes | @a_grygorenko | Test Engineering Notes

AI tools and how they kill learning

#ai #tools #learning

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

А як ви думаєте - чи легше стало дійсно навчитись новому з ШІ - чи складніше?

Кожен може розробити калькулятор! (та де калькулятор краще - Android чи IOS)

#engineering

Цікавезна історія, в якій Hans-J. Boehm, що працював над власними версіями garbage collector та деякими частинами стандарту С++, отримав задачу написати ... калькулятор.
Здається, задача вкрай проста. Але це не так.

P.S. Hans навіть написав дослідницьку роботу про цей досвід - Towards an API for the Real Numbers

Як пишуть код в NASA

#engineering

Знайшов коротенький документ, що описує вимоги до написання коду в NASA. Тобто це "код для rocket science 🚀".

10 правил для safety-critical коду (на мові С):

1. Користуйтеся тільки простими конструкціями управління
2. Усі цикли повинні мати фіксований ліміт
3. Не користуйтесь динамічною памʼяттю після ініціалізації (привіт, Javascript!)
4. Функції не повинні перевищувати 60 строк (як максимум)
5. Не більше двох ассертів на функцію
6. Обʼєкти даних повинні створюватись на мінімально можливому рівні видимості
7. Результат non-void функцій перевіряє фукнція, що їх викликає; валідність вхідних параметрів перевіряється всередині кожної функції
8. Користування пре-процессорами та макросами повинно бути вкрай обмеженим
9. Посилання (pointers) повинні бути обмежені також
10. Весь код повинен бути компільованим, з першого дня розробки з усіма можливими перевірками на рівні компілятора. Усі помилки компіляції (навіть типу "warning") повинні бути виправлені одразу. Код повинен бути протестований як мінімум раз на день (більше - краще) з усіми можливими аналізаторами та із нульовою кількістю помилок.

Automated Accessibility Testing at Slack

#testing #automation

Якщо комусь не вистачає матеріалів з accessibility тестування - маю вкрай цікаву статтю. В ній розповідають як такий вид тестування виконують в Slack.
Цікаво, як завжди.

Замість пірамід та трикутників ... Наглядний приклад, що пояснює різницю між рівнями тестування (від Wayne Roseberry)

Сьогодні просто цікава ілюстрація важливих навичок тест інженера. Тобто це не тільки інструменти та автоматизація ... (З матеріалів Satisfice.com)

Модель отримання навичок братів Дрейфус

#thinking #learning

Коли ми навчаємось чи навчаємо когось (як ментор чи на курсах), треба розуміти як люди взагалі отримують нові навички. Одна з моделей, яка може розповісти про це - це модель Стюарта та Губерта Дрейфусів. Згідно з цією моделлю, кожен студент проходить крізь пʼять різних етапів: новачок, просунутий початківець, компетентний спеціаліст, досвідчений спеціаліст та експерт.

Етап 1 - Новачок

У новачків немає або дуже мало досвіду. Новачки навіть не стільки вчаться, скільки хочуть виконати конкретну задачу в моменті часу. Новачкам потрібні рецепти (покрокові інструкції).
Проблема з рецептами в тому, що вони позбавлені контексту. То ж неможливо зробити "універсальні рецепти на усі випадки".

Етап 2 - Просунутий початківець

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

Етап 3 - Компетентний спеціаліст

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

Етап 4 - Досвідчений спеціаліст

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

Етап 5 - Експерт

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

Гаразд, але що з того?

- Більшість людей знаходяться на рівні просунутий новачок
- Новачкам потрібні люди, які б їх направляли та давали зворотній звʼязок
- Продуктивність експертів падає, якщо підходи й правила єдині для всіх рівнів
- Користуйтесь правила та гайдами для новачків, залиште інтуїцію для експертів
- Експерти не завжди найкращі вчителі, бо вони мислять паттернами, які подекуди не можуть пояснити іншим
- Кожна наша окрема навичка рухається згідно моделі Дрейфусів. То ж можна "прокачувати" навички наче окремі гілки героя в RPG
- Не достатньо просто практикуватись 10000 годин. Треба розбивати практику на конкретні задачі потрібної складності, мати постійний зворотній звʼязок щоб виправляти помилки одразу
- Для швидкого прогресу потрібно оточувати себе більш експертними людьми в команді
- Ми вчимося краще коли спостерігаємо та імітуємо. То ж сесії парного тестування чи програмування можуть стати у нагоді

В FAANG (Big Tech) компаніях немає тестувальників

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

Але ось знайшов лінку, де можна подивитись інформацію про вакансії тестувальників в Apple, Amazon, Nvidia.
Так, це вакансії з Долини. Але можна подивитись на вимоги та бажані навички.

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