Test Engineering Notes

Огляд - Wizard Zines

#engineering

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

Julia Evans зібрала свій практичний інженерний досвід з Linux, networking, command line, bash та ще багато чого у форматі ... коміксів.

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

Як ці комікси виглядають та які вони бувають - у пості.

P.S. Деякі комікси - безкоштовні. Можна почитати.

І ще одне! На платні комікси є знижка для українців.

Консультації, менторинг та підготовка до співбесід

#services

В ІТ я вже понад 14 років. Автоматизував різні проєкти - від вебу до мобільних застосунків, від ігор до блокчейну.
Зараз мій стек - Python / Rust. Також мав справу з Java, Scala та C#.
Крім того, час від часу я залучений як технічний інтервʼюер у різних компаніях.

Давайте розповім, із чим саме я можу вам допомогти.

Підготовка до співбесіди

Коли це може бути потрібно:

* ви не впевнені, які теми вчити перед співбесідою
* маєте страх технічних запитань чи live-coding задач
* вам складно презентувати свій досвід
* ви думаєте, що нічого не знаєте - спойлер: це зовсім не так!
* у вас були невдалі співбесіди, але незрозуміло, чому ви отримали відмову

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

Індивідуальний план розвитку карʼєри

Коли це може бути потрібно:

* незрозуміло, який у вас зараз рівень і що потрібно знати на позиціях Middle / Senior / Lead
* хочеться вивчити багато тем, але немає часу та системи
* складно пріоритезувати теми для навчання й тримати фокус
* незрозуміло, як практикувати отримані навички

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

Подальший шлях ви обираєте самі: самостійний розвиток або індивідуальний менторинг зі мною.

Консультації з автоматизації тестування та інших аспектів тестування

Коли це може бути потрібно:

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

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

Якщо маєте питання або хочете домовитися про дзвінок — пишіть у директ чи @al8xr. Завжди радий допомогти.

Огляд книги: "Full Stack Testing"

#books #testing

Приніс хорошу книжку по сучасне тестування.

Дуже багато корисних діаграм, схем процесів (коли які тести запускати).

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

Але загалом - непоганий огляд на сучасні підходи до різних видів тестування (+ тулзи). Тільки не треба очікувати аж надто великої "глибини".

Огляд книги: "Mastering Blockchain"

#books #blockchain #engineering

🙄 На полицях сотні книжок про блокчейн. Десятки з них технічні. Але з якої почати? Треба вчити одразу Bitcoin, Ethereum, Solana, Midnight, чи щось інше?

🕶️ Моя порада для будь-якого інженера, що стартує (чи думає працювати) в блокчейні - це розібратись з фундаментальними знаннями.

📚 Я можу порекомендувати 1 (одну!) книгу, яка покриває майже усі базові знання в блокчейні на досить хорошому технічному рівні. Тут і про хешування, і про консенсуси, і про Біток з Ефіром (а саме про їх архітектуру!), і про смарт контракти.

👉 Ця книга - це "Mastering Blockchain" за авторством Imran Bashir.

✍ Інсайти, плюси й мінуси книжки - у пості.

💰 The Hidden Cost of AI Coding That's Destroying Engineering Teams

#ai #engineering

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

🤔 Найважливіші інсайти:

💡Ми можемо зрозуміти коли створюємо технічний борг. Знаємо як із ним боротись. Але ШІ додає борг розуміння - різницю між тим, скільки коду у програмі та тим, скільки з цього коду розробник реально розуміє. З ШІ борг розуміння зростає непомітно. (Одна команда 3 місяці вайбкодила, а потім витратила ще 6 місяців, щоб розібратись в тому, як це згенероване працює)

💡Парадокс продуктивності. Джуніори з ШІ швидше генерують новий код. Сіньйори зменшують продуктивність на 19% через те, що їм доводиться ревьювати набагато більше коду. Сіньйори стають такими собі "збирачами сміття" замість того, щоб розвʼязувати важливіші проблеми.

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

💡Код - не головний артефкт роботи. Головний артефакт роботи - це грамотно сформулювана специфікація. На її основі ШІ зможе щось створити.

💡Зараз створюється ринок праці де вартість експертизи у верифікації зростає. А вартість написання коду - знижується.

Огляд на книгу: Software Testing Strategies

#books #testing

🙄 Коли деякий час працюєш в тестуванні, може виникнути спокуса сказати: «Я все знаю» або «Книга про стратегії тестування не може дати мені нічого нового».

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

✍ Ця книга називається «Software Testing Strategies: A Testing Guide for the 2020s» Метта Хойссера та Майкла Ларсена. Вона охоплює багато тем: від методів розробки тестів до підходів до автоматизації, від тест планів до філософії й етики тестування.

👉 Мої 5 інсайтів з книги - у блозі.

🛠 Your K6 Tests Are Lying to You (And It’s Not K6’s Fault)

#testing #performance

Невеличка стаття про те, що недостатньо просто користуватись інструментом для навантаження. Треба ще й ... продумувати реалістичні сценарії.

😱 Реалістичні сценарії не просто ганяють ваш скрипт із реквестами в нескінченному циклі в багато потоків.

Щоб покращити такі тести треба додавати таку штуку, як think time.

🤯 Think time - це додавання затримок між діями користувача. Реальні юзери не клацають на кнопки як навіжені із максимально можливою швидкістю. Юзери думають, приймають рішення, неспішно заповнюють форми, роблять помилки та виправляють.

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

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

❤️‍🩹 Прощання з Геннадієм Міщевським відбудеться у середу, 20 травня у Києві. Для родини дуже важливо щоб ті, хто знав його особисто, провели його в останню путь. Тож якщо ви зможете прийти, будемо дуже вдячні.

12:00 — відспівування у Михайлівському Золотоверхому монастирі.

12:50-13:00 – піша хода з Михайлівського Золотоверхого монастиря до Майдану Незалежності

13:50-14:00 – виїзд з Майдану Незалежності до кладовища, с. Крюківщина, вул. Каштанова 1. Орієнтовно поховання відбудеться 14.40-15.00

Після поховання відбудеться поминальний обід — якщо ви знали Гену особисто, його родина була б рада, щоб ви долучилися і поділилися спогадами про Героя. Будь ласка, напишіть Олександрі Ковальовій (@molly4air) в особисті, якщо плануєте залишитися на прощальний обід у кафе.

📚 Огляд на книгу: "Testing Web APIs"

#books

Чи знаєте ви як тестувати API? На перший погляд це дуже просто: відкрий Postman, створи колекцію та запускай!

Але як підходити до тестування API більш продумано? Чи варто планувати стратегію тестування?

Чи можна перевіряти API ще до того, як його написали? Чи потрібно додавати автоматизацію? А як щодо перфомансу чи безпеки?

Все це можна знайти у книзі "Testing Web APIs" від Mark Winteringham.

Усі пишуть про ШІ, усі пишуть з ШІ

#testing

На картинці можна побачити про що писали раніше й зараз.

З одного боку - ШІ з сьогодення, його вимагають на роботі та у вакансіях.

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

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

• "Зараз я розповім тобі про ... без води, тільки практика."
• "І проблема не тільки в ... Проблема в. ... Зараз поясню..."

Так, статті та дописи можна генерувати за секунди. Як результат - Linkedin та інші блогоплатформи завалені однаковими дописами.

Але, ці дописи можна було б і не писати. Можна просто задати цей промпт LLM-ці, отримати собі відповідь та йти далі.

Що більш цінне - це ваш особистий досвід роботи із чимось. Чи вивчення чогось.

Ваші особисті інсайти написані своїми словами.

На війні загинув QA-спеціаліст, переможець Премії DOU Геннадій Міщевський

https://dou.ua/goto/qViK

Геннадій багато років працював у QA, писав про тестування й автоматизацію, був одним із переможців першої Премії DOU. Після початку повномасштабного вторгнення долучився до проєкту SocialDroneUA, а потім — до лав Сил оборони. Редакція DOU висловлює співчуття рідним і близьким Геннадія.

📚Огляд на книгу "Contract Testing in Action: With Pact, PactFlow and GitHub Actions"

#books

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

Сьогодні - свіжа книжка про контрактне тестування з Pact, яку написали Marie Cruz та Lewis Prescott.

20 законів розробки софта

#engineering

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

💡 Gall's Law. Складна система, що працює завжди була побудована з більше простої систем, яка працювала

💡 KISS. Keep It Simple/ Спрощуйте там де можливо.

💡 Conway's Law. Організації створюю системи, що відображають їх організаційну структуру

💡 CAP Theorem. Розподілена система може гарантувати лише дві з трьох властивостей одночасно: узгодженість, доступність чи толерантність до розділення

💡 Hyrum's Law. Маючи достатню кількість користувачів, кожна поведінка вашого API стає чиєюсь залежністю.

💡 Zawlinski Law. Кожна програма розшируюється, поки не зможе читати пошту. Ті, хто не може читати - змінюються тими, хто може.

💡 Brook's Law. Додавання людей на піздньому етапі розробки ще більше віддаляє реліз.

💡 Ringelmann Effect. Індивідуальна продуктивність падає зі збільшенням розміру команди.

💡 Ефект Даннінга - Крюгера. Чим менше ви знаєте про щось, тим впевненіше ви з цієї теми.

💡 Hofstadter's Law. Це займе більше часу, ніж ви очікуєте.

💡 Price's Law. Половина роботи виконується квадратним коренем із кількості людей.

💡 Parkinson's Law. Робота розширюється, щоб заповнити весь відведений на неї час.

💡 Goodhart's Law. Коли метрика стає ціллю, вона перестає бути хорошою метрикою.

💡 Gilb's Law. Все, що потрібні виміряти кількісно, можна виміряти іншим чином, що буде краще, ніж кількісно.

💡 Knuth's Optimization Principle. Передчасна оптимізація - корінь усього зла.

💡 Amdahl's Law. Прискорення від паралелізму обмежене частиною, що працює послідовно.

💡 Murphy's Law. Все, що може піти не так, піде не так.

💡 Postel's Law. Будьте консервативними в тому, що надсилаєте, та ліберальними в тому, що приймаєте (наприклад для API).

💡 Sturgeon's Law. 90% усього - повна фігня.

💡 Cunningham's Law. Найшвидший спосіб отримати правильну відповідь онлайн - це опублікувати неправильну.

А ви які закони знаєте?

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

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

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

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

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

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

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

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

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

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

😏 The AI Quality Paradox

#ai #testing #engineering

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

Гіпотеза:

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

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

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

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

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

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

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

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

📚Про AI-Driven Software Testing

#books

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

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

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

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

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

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

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

Як працює 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 компільованого коду

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

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

#certificate

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

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

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

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

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

#bugs

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

Проблема

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

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

Як пофіксили

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

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

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

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

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

#testing #criticalthinking

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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