Карʼєрні супер здібності, що допоможуть у важкі часи

#testing #career

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

- Шо я роблю не так?
- Чому я не можу знайти роботу?
- Чи цінні мої навички?

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

Вміння навчатися

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

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

Вміння адаптуватись

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

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

Не думайте, що навички, які ви здобули 5-10-20 років тому так само потрібні зараз.
Більшість з них потребують постійної практики, а може - й заміни.

АйТі постійно змінюється. То ж нам треба змінюватись разом із ним.

Готові стати QA Leader? 💡
Запрошую на четвертий потік с̶у̶в̶о̶р̶о̶г̶о̶ групового менторства QA-Lead, де ви дізнаєтеся все про цю посаду та отримаєте інструменти для успішного вирішення завдань після підвищення.

Що у програмі?
- Допрацьована програма після трьох потоків, відшліфована і покриває все, про що ви писали у відгуках 🔥
- Практика на реальних кейсах
- Інтенсивні домашні завдання: підготуйтеся витратити від 10 годин на тиждень
- Запрошені експерти: майстри з надання фідбеку, ораторського мистецтва та найму
- Щотижнева рефлексія, групові мастермайнди та індивідуальні сесії

Які новинки підготував для вас цього разу:
- додатковий формат, що дозволить самостійно навчатися (пожиттєвий доступ і коштує дешевше, що приємно 😉)
- з'явилися туторіали по інструментах
- деталізована програма
- гнучка оплата частинами від 4-х банків
- а ще такі топові сертифікати для випускників, які неможливо ховати у шухляді
- залишилися питання? Пишіть одразу мені @artem_grygorenko

📅 Старт: 16 вересня

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

P.S. Ціна раннього бронювання діє тільки до кінця серпня! 👀

⚡️ Епізод 36: Де тестувальник шукає баги в мисленні

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

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

⚡️ Епізод 37: Де тестувальник пробує менторити

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

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Чотири стадії компетенції

#learning

Коли ми вчимося новому, ми так чи інакше проходимо через чотири стадії компетенції.

Стадія 1 - Несвідома Некомпетентність

Ви не знаєте того, що не знаєте. Ви тільки почали вивчати тему.

Щоб прогресувати, треба запитати себе - "Чого саме мені потрібно навчитися?". Зробити дослідження теми, спробувати знайти вже готові роадмапи навчання чи програми з потрібного предмету в університетах.

Стадія 2 - Свідома Некомпетентність

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

Як рухатись вперед? Встановіть конкретні цілі навчання, дивіться на проєкти в якості прикладів, шукайте ментора всередині компанії чи деінде.

Стадія 3 - Свідома Компетентність

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

Для розвитку - задайте собі питання - "Як я можу застосувати навички в інших, більш складних ситуаціях?"

Стадія 4 - Несвідома Компетентність

Рівень експерта, коли ви виконуєте роботу та застосовуєте навички автоматично. Як-от їзда на велосипеді чи швидкий набір тексту на клавіатурі.

Щоб прогресувати, на цій стадії треба постійне навчання та практика.

І ще одне!

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

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

P.S. Це придумав не я, це вже відомо із середини минулого століття.

Топ 10 вразливостей LLM систем

#security #ai #llm

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

Можна навіть скачати в PDF.

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

Behavior Driven Chaos with AWS Fault Injection Simulator

#testing #python #chaos

Якщо ваша інфраструктура на AWS та маєте бажання перевірити стійкість системи - можна застосувати підхід хаос інжинірингу.
Більше про підхід можна почитати тут.

Amazon випустив окремий інструмент для таких цілей - AWS Fault Injection Simulator.

Подивитись приклад на Python (та навіть з BDD!!!):

git clone https://github.com/aws-samples/aws-fis-behaviour-driven-chaos.git

⚡️ Епізод 38: Де тестувальник розбирається з метриками

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

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

🔸 Youtube
🔹 Spotify
🔸 Apple

❗️❗️❗️Для тих, хто хоче підтримати наш подкаст, крім Buy Me a Coffee, зʼявилася нова нова можливість - зробити підписку через Mono!

За різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Проблема ораклів або чому тестувальника не просто замінити

#testing

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

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

Як вам такий формат?

💼 Чим відрізняються джуніори від сіньйорів?

#career

Натрапив на таке порівняння в книзі "Coding Career Handbook".

👨‍💻Кодинг

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

👩‍🎓Навчання

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

🖖Поведінка

- Джуніори шукають найкращі підходи. Сіньйори люблять достатньо хороші підходи
- Джуніори повинні часто говорити "Так". Сіньйори повинні більше говорити "Ні"
- Джуніори жаліються на open-source. Сіньйори знають, що open-source працює завдяки тим, хто пише код, а не жаліється
- Джуніори вирішують проблеми. Сіньйори вивляють проблеми, ще до того, як вони стануть проблемами
- Джуніори знають як створювати. Сіньйори знають, коли треба купувати
- Джуніори порівнюють досвід розробника. Сіньйори шукають приховані витрати
- Джуніори залишають коментарі. Сіньйори надають контекст

🤲 Команда

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

Як Uber тестує платежі в продакшені, що значить бути контекстно-орієнтованим тестувальником, проблеми безпеки LLM-систем та автоматизація з Playwright — це та багато іншого читайте у новому QA-дайджесті 👉 https://dou.ua/goto/fqtI

#Digest

📚Книжкове літо 2024

#books #testing #learning

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

Тестування

📕Advanced Testing of Systems-of-Systems - Volume 1: Theoretical Aspects та Volume 2: Practical Aspects - цікаві книги про те, як підходити до тестування складних систем (що складаються з інших складних систем). Багато практичних прикладів, але друга частина мені здалася навіть більш теоретичною ніж перша. Корисне є, але якщо ви читали багато тест менеджерської літератури та здавали екзамен ISTQB Test Manager - нового буде мало.

📔Artificial Intelligence and Software Testing: Building systems you can trust - невеличка, але вкрай корисна книга про те, як тестувати недетерміновані системи - на прикладі AI та ML. Можна провести деякі паралелі із блокчейном. Книжка тільки розкриває цю тему та дає базові знання - то ж не треба очікувати якихось чарівних "таблеток".

Навчання

📘Make It Stick: The Science of Successful Learning - книжка про те, що сучасне навчання не є ефективним, а існують кращі науково доведені способи як це робити. Книга хороша, але остання третина - чергове повторення попереднього матеріалу та інтервʼю з тими, хто користувався способами, що пропонують автори.

📗Ultralearning - книжка від Scott H. Young, що пройшов 4-річну програму MIT з computer science - за 1 рік! В книзі автор розповідає про свій метод (по факту набір з відомих методів). 20% книги трохи водянисті, але решта - мені сподобалась.

📙Building a Second Brain - так як веду нотатки, користуюся Obsidian та методом PARA - цю книжку рано чи пізно треба було почитати. Книга за авторством Tiago Forte, який метод PARA й створив. В ній автор більш глибоко розкриває метод, наводить безліч прикладів та й взагалі багато пише про те, чому нотатки в сучасному світі вкрай необхідні.

А що ви прочитали цього літа?

⚡️ Епізод 39: Де тестувальник розбирається з токсіками разом з Інною Осінною

Що таке токсична поведінка? Як боротися із токсичними колегами на роботі? Як самому не стати токсичним? Усі ці питання Артем та Олександр обговорюють разом із гостею - Інною Осінною.

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

📹 Youtube
🎧 Spotify
🎧 Apple

Ваша підтримка важлива!

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

Дякуємо вам!

Підтримати подкаст можна через:
👍 База від Монобанку
☕️ Buy Me a Coffee

#testingminutes | @a_grygorenko | Test Engineering Notes

📖 День, з якого все почалось

#testing

В далекому 1947 році компʼютери були великими - то ж тільки невелике коло вчених мали доступ до тих велетнів.

Того року, а саме 9 вересня (як кажуть джерела), інженери з Гарвардського університету працювали над компʼютером Mark II та знайшли ... міль, що застрягла в одному з компонентів.

Логування в ті часи було паперовим - тож інженери прикріпили комаху в свій журнал та підписали це як "first actual case of bug being found."

Цей випадок дав початок термінам "bug" та "debug". Зараз - ці слова мають в своєму лексіконі майже всі, хто дотичний до розробки софту.

А 9 вересня з тих пір стало професійним святом усіх борців за якість та мисливців за комахами в софті.

❗️Вітаю усіх тестувальників зі святом! 🎉

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

🪲🆚 🦾 Чи повинен тестувальник вміти автоматизувати?

#testing #automation

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

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

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

Я наведу лише один думку, яку прочитав сьогодні.

Багато хто з нас (я в тому числі), працює в тій чи іншій Agile методології, то ж ми можемо назвати себе Agile тестерами. В ISTQB не так давно зʼявилась окрема сертифікація - "CTFL - Agile Tester".

Для підготовки до сертифікації рекомендують прочитати книгу - Agile Testing Foundations. В цій книжці розповідають багато чого цікавого про agile процеси та роль тестувальника в них. Зокрема - про необхідні навички тест інженера в Agile.

Наведу обрані цитати з книги - про знання автоматизації.

A tester needs to be more efficient in their testing efforts by implementing automated testing to cover regression testing risk

Для регресії, без автотестів в agile буде складно.

To be technical does not mean that the tester is inevitably a developer, it means that the tester must understand what is going on in the team and also understand development concepts.

Це про технічні знання. Може, перетворення в розробника можливе тільки, якщо тебе вкусять?

Про знання мов програмування:

At a minimum, testers should have noscripting skills to be able to noscript test cases that are included in an automated test framework. Testers need to be able to switch from one tool or language to another, depending on the technology used on the project.

А ось - про знання CICD та внутрішньої роботи системи:

Testers also need to understand the way CI or deployment works, how a software component is built, and how software configuration management works and so on, in order to be a contributor to these tasks

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

⚡️ Episode 40: The one where the test engineer explores rapid software testing with Michael Bolton

Завершуємо четвертий сезон подкасту Testing Minutes розмовою про rapid software testing (та й про тестування загалом) з тим, хто цей підхід й винайшов - Майклом Болтоном.

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

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Модель тестування: imagination / implementation

#testing

Минулого тижня побачив одну цікаву модель того, що таке тестування. ЇЇ автор - James Lyndsay.

Вона складається з двох кіл.

Ліве коло - то уява (imagination) - або те, що ми ХОЧЕМО мати в продукті. Сюди відносяться вимоги, бажання, дискусії та негласні домовленості.

Праве коло - то виконання (implementation) - або те, що ми МАЄМО в продукті. Тобто код, дані, інфраструктура.

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

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

Вгадайте, де на цій діаграмі можна позначити автоматизоване тестування?

🤖 Imagination / Implementation - де тут автотести?

#testing

Продовжуючи минулий пост про модель тестування.

Ось, який варіант моделі тестування пропонує Mark Winteringham в книзі "Testing Web APIs". Тут автоматизаовані тести знаходяться якраз на перетині між тим "як воно повинно працювати" та "як воно реально працює".

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

Shifting E2E Testing Left at Uber

#testing #automation

Сьогодні пропоную почитати про те, як Uber користується BITS (backend integration testing strategy). Окремо, дуже цікаво подивитись, як Uber вирішує питання підтримки тестів, їхньої стабільності та швидкості.

📹Співбесіда на Junior QA

#testing #interview

Вчора, на запрошення Олекси з каналу QA Україна, я проводив публічну тренувальну співбесіду для кандидата на рівень Junior Manual QA.

Для чого проходити такі тренувальні співбесіди?

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

❗️Я проводжу подібні співбесіди (не публічні), разом із розгорнутим зворотнім звʼязком, разом із ревʼю резюме.

Якщо у вас є бажання пройти подібну співбесіду - пишіть мені в DM. ✍️