⚡️ Епізод 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. ✍️

Дві сторони тестування

#testing

В книзі "Explore It" Елізабет Хендріксон говорить про те, що тестова стратегія повинна відповідати на два питаня:

- чи веде себе софт так, як очікується в тих умовах, які прописані у вимогах?
- чи існують якісь додаткові ризики?

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

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

Але повне тестування якраз і складається:

Tested = Checked + Explored

Чи згодні ви з таким підходом? Чи може одних лише тестів буде достатньо?

Вчимо та тренуємося писати SQL запити

#testing #sql

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

Виникає питання - "Де потренуватись писати SQL запити?"

Маю відповідь - підбірка Websites for Practicing SQL

Тут зібрано дуже багато сайтів із завданнями різного рівня складності.

Подкаст Testing Minutes - потрібна ваша допомога!

#podcast

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

Ваші пропозиції допоможуть зробити подкаст ще цікавішим! Дякуємо за відповіді!

❓Як обрати, що вчити?

#learning

В Суворому QA комʼюніті завжди цікаві дискусії. Ось наприклад вчора було таке питання:

У кого яка поведінка в вивченні? Будете вчити те, де знаєте що кульгаєте? Або підете на ще один курс по темі, де ви норм розбираєтеся, але хочеться краще?

Тема навчання та розвитку дуже велика. Все як завжди залежить від того, чого ви хочете.

🔖Загальні відповіді

- Науково доведено, що людина скоріш буде практикуватись в тому, що вже й так знає та вміє. Бо це легко, це виходить. А якщо виходить - буде задоволення від виконаного завдання чи курсу.
- Щоб уникнути такої проблеми, треба памʼятати - ми вчимося тоді, коли нам складно. Так, у вас буде спокуса все кинути, бо складно. Але це - процес навчання. Тому краще обирати для навчання ті теми, в яких ви почуваєтесь найслабшими.
- Щоб зрозуміти, наскільки ви знаєте тему - спробуйте розповісти про неї комусь, навчити її, виступити на конференції. Або спробуйте сформулювати питання на високих рівнях таксономії Блума та відповісти на них (цікава техніка).
- Не всі знання однаково корисні. Треба розділяти концепції та процедури. Процедури - це будь-що, що ми робимо по визначеному алгоритму, наприклад налаштування серверу чи користувача або вирішення конкретної задачки на обраній мові програмування. Процедури запамʼятовуються ТІЛЬКИ ЧЕРЕЗ ПРАКТИКУ.

🤔Що роблю саме я

- Рефлексія. Відмічати, які робочі таски даються важче, ніж інші. Яких знань мені не вистачає. Це можуть бути знання програмування, технологій, продукту, домену.
- Візуалізація. Збираю усі ці замітки та формую карту того, що треба вчити взагалі для роботи.
- Пріоритети. Виділяю з усього списку найгарячіші теми та прокачую їх окремо. В мене працює фокус на 1-2 темах на виділений період часу - тиждень, два, або більше. Усю іншу інформацію - фільтрую та додаю в папку (коли-небудь потім)
- Відмічаю свій прогрес у вивченні. Записую, що тепер можу робити, коли розібрався у новому та закріпив то на практиці. "Тепер я можу налаштувати користувача", "Тепер я знаю, як подивитись логи в цьому сервісі та дослідити весь флоу"
- Роблю нотатки усього. Процедури, нова інформація чи концепції, мітинги.
- Закріплення. Досить недавно прийшов до того, що для кращого запамʼятовування та закріплення знань - треба робити собі власні тести знань. Можна для цього застосувати chatgpt, anki карти, що завгодно.

📰І ще одне!

А для тих, хто хоче навчитися чогось нового - можна піти на QA Magic Meetup 6.0, що відбудеться вже 26 жовтня, в Києві.

Очікуються цікаві доповіді від спікерів із практичним досвідом. Мені, наприклад, цікаво послухати доповіді про персональну ефективність та QA метрики.
Плюс, там буде нетворкінг й афтепаті. Для тих, хто поїхати не зможе - буде онлайн трансляція.

❓З чим я можу Вам допомогти?

Всім привіт.
Мене звати Олександр Романов. В ІТ я з 2011 року. За цей час писав на Java, C#, Scala, Python; автоматизував web, mobile, API, мікросервиси, блокчейн.

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

З чим я можу допомогти Вам

🔶 Тренувальні mock інтервʼю. Можливо, ви тільки закінчили курси, але ще не відчуваєте впевненості в собі для першої роботи. Можливо, ви не відчуваєте себе сіньйором в достатній мірі. А може ви задовго були на одному місці роботи та хочете бути морально готовим до нових співбесід. Якого б рівня ви не були, тренувальна співбесіда зі зворотнім звʼязком додає впевненості та допомагає зрозуміти пробіли у знаннях. Приклад інтервʼю можна подивитись тут.

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

🔶 Консультації з автоматизації тестування. Як краще писати тести? Чи правильний Ви обрали підхід? Які можуть бути "підводні" камені в автоматизації? Іноді проста розмова та погляд зі сторони допоможе прийняти необхідне рішення.

🔷 Індивідуальний менторинг. Разом із вами ми можемо створити план вашого карʼєрного розвитку. Я можу допомогти із тим, що краще вчити, як практикувати вивчене, а найголовніше - як це робити найбільш ефективно. (Щоб знання стали навичками, а не забулися через місяць-два).

З чим я допомагаю компаніям:

🔶 Технічні інтервʼю. Якщо у вас молода команда, але треба її швидко розширити, я можу допомогти зі співбесідами та оцінкою навичок кандидатів.

🔷 Консультації з автоматизації тестування. Від оцінки проєкту до побудови стратегії тестування й автоматизації. Або ж вирішення конкретних запитів.

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

“ISTQB Test Manager 3.0: управління тестуванням в умовах невизначеності”

🤓 Цьогоріч перше за 12 років вийшла оновлена версія силабусу до сертифікації ISTQB Advanced Test Manager.
Його вже дослідила і готова ділитися своїми враженнями Олександра Ковальова, ISTQB-тренерка з 8+ річним досвідом.

👉 що покриває нова версія Advanced Test Manager 3.0 і де вона стане у нагоді, а де ні;
👉 чи став іспит легшим в новій версії;
👉 скільки в новій версії agile і до чого тут Foundation Level 4.0;
👉 як впливає модель розробки на проєкті на планування тестування, і де тут невизначеність;
👉 навіщо тестувальникам рівня Middle та Senior розуміти роботу Test Lead;
👉 чи вплинули ці зміни на тестувальників, які складали попередні версії іспиту;
👉 яка різниця в ролях Тест Лід та Тест Менеджер в компаніях, і що про це каже ISTQB.

Коли?

⏰ Початок о 19:00, 8 жовтня
📋 Обов'язкова реєстрація для участі у трансляції та отримання запису.
🎯 Деталі та реєстрація: https://bit.ly/3XVdujo