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

Що таке Peel Testing?

#testing

Блукаючи мережею в пошуках цікавого контенту, я натрапив на коротеньке відео "What is peel testing".
Моє перше враження було - "Прикольно, новий вид тестування!".
А потім я подивився й зрозумів, що тестування - то не тільки програми, біти й байти ...

А ви знаєте, що таке peel testing?

📣 Embedded QA skill set: Are you all set? 📣

Це must-visit подія для QA-спеціалістів, які цікавляться напрямом Embedded, де команда SQUAD поділиться дослідженнями та аналізом актуальних навичок для Embedded QA.

Приєднуйтесь, щоб оцінити себе або команду відносно потреб ринку 🧐

У ПРОГРАМІ:

▪️Актуальні скіли для Embedded QA
▪️Статистика по топ навичкам для Embedded QA в Україні та США
▪️Опис скілів та їхнє оцінювання
▪️Визначення пріоритетних скілів кандидатів при наймі в команду
▪️Обґрунтоване формування цілей та трекінг прогресу розвитку колег
▪️Чому skill set матриця є одним з найзручніших інструментів візуалізації вмінь команди?

ДЕ і КОЛИ:

🗓️ 23 жовтня | 19:00-21:00
📍 Київ, облаштований та безпечний простір SQUAD
💻 Онлайн-трансляція для тих, хто не може долучитися фізично
🙌 Участь безкоштовна

Деталі та реєстрація — https://bit.ly/47X6o2A

Встигніть зареєструватися, кількість місць офлайн обмежена 😎

😱Покращуємо якість без тестувальників

#testing

Цими вихідними натрапив на цікаву статтю. В ній розробник розповідає, як вони покращили якість на проєкті.

🦶Покроковий алгоритм дій:

1. Звільніть усіх тестувальників!
2. Розкажіть розробникам, що вони тепер відповідальні за якість
3. Розробник, що робить код ревʼю - тестує фічу
4. Розробник, що зробив задачу - додає до пулл реквесту докази того, що фіча працює (скріншоти, відео, запити)
5. Проводьте нерегулярні bug bash активності - де тестувати будуть усі, включно з дизайнерами, менеджерами та аналітиками (бо знайти хорошого тестувальника складно)

Більше про результати можна почитати в статті.

❓Як думаєте, чи успішний був такий підхід?

Швидко малюємо діаграми в Excalidraw

#visual

Іноді простого опису текстом недостатньо, щоб зрозуміти якийсь процес чи структуру. Тоді на допомогу можуть прийти діаграми.

Краще, звичайно, малювати їх вручну самостійно. Але можна користуватись й інструментами - наприклад Obsidian Canvas, Miro, Excalidraw.

Якщо треба швидко зробити візуалізацію, то в Excalidraw є функція "Text to diagram".

Наприклад ось, що він зробив на такий текст:

  
Digital Signature Scheme

Two phases: sign and verify. 

At sign phase, Alice calculates hash (256 bit) from the document she wants to send Bob. Then Alice encrypts the hash with her secret key. 

At verify phase, Bob decrypts hash with Alice's public key, calculates hash from the document and then compare his hash and Alice's hash. If same - document is verified.

📝Кількість багів - як метрика якості 🐞

#testing #metrics

Коли стає питання, як виміряти ефективність тестувальників, перша думка, що виникає в голові менеджера - це кількість багів!

Але сама по собі, кількість багів це, скоріш, шкідлива метрика.

Чому шкідлива?

✍ Оцінювати ефективність роботи по кількості багів - це як оцінювати розробника по кількості строк коду чи книжку по кількості сторінок

✍ Кількість багів може бути різною, бо все залежить від специфіки продукту, процесів, людей

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

Що робити замість трекінгу кількості?

Збирайте та аналізуйте defect leakage - кількість багів, що "просочилася" на продакшн та була знайдена користувачами. На кожен з таких багів треба зрозуміти його причини та як команді не пропускати подібні баги у майбутньому.