Test Engineering Notes – Telegram
Test Engineering Notes
3.8K subscribers
177 photos
2 videos
641 links
Україномовний канал про технічні аспекти тестування, розподілені системи, блокчейн та кібербезпеку.

Консультації з автоматизації, менторинг, проведення співбесід - @al8xr
Download Telegram
Forwarded from Testing Minutes (Oleksandr Romanov)
⚡️ Епізод 45: Оцінки задач в тестуванні та чому мало хто вміє їх робити

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

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

🔸 Youtube
🔹 Spotify
🔸 Apple

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

Дякуємо вам!

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

#testingminutes | @a_grygorenko | Test Engineering Notes
26👍4
Що таке Lean Test Canvas?

#testing

Lean Test Canvas - одна з форм організації тестової стратегії. Знайшов її в книзі Software Testing Strategies. Автори надихались відомим business model canvas.

Модель допомагає візуалізувати всі найголовніші складові тестової стратегії:

- customers: хто буде тестувати - внутрішня чи зовнішня команди

- value proposition: відповідь на питання "чому вам треба тестувати оце все"

- test and deploy pipeline: скільки часу треба на усі активності, щоб отримати нову версію на продакшн

- core scope of role: за які ризики відповідає команда

- impact: наскільки велика фіча та які підсистеми вона включає

- key resources and activities: хто та яким чином виконує тестування

- out of scope: які аспекти чи атрибути системи не покриваються тестуванням

- cost of structure: скільки ми платимо за тестування (чому так багато?)

- direction for improvements: як команда буде покращувати зібрані метрики

- key measures: які метрики команда буде використовувати
🔥22👍5
🪄Проблеми автоматизації: чарівність та швидкість автотестів

#testing #automation

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

Уявімо на секунду, що така кнопка існує. Девелопер закінчив написання коду, створив PR - тести автоматично запустилися на CI сервері, й БУМ - ви отримали результати!

🔮Більшість автоматизованих тестів створюють не для того, щоб тестувати. Їх створюють для швидкої ідентифікації змін (change detection). Робота розробників якраз і полягає в тому, щоб ці зміни створювати. То ж по хорошому, якщо тест на змінену фічу впав - то це саме те, задля чого він був створений (бо тепер є зміни в системі чи бізнес сценарії).

🎱Команди, що використовують автоматизацію тестування знають, що як тільки отримуєш результат - їх треба дослідити. Бо серед тестів можуть бути підступні false negatives (баги нема, а тест впав) та false positives (бага є, а тест - зелений). Після дослідження треба описати кроки для відтворення проблеми та обговорити чи потрібно взагалі робити фікс.
Далі - наступає очікування, поки розробник пофіксить проблему. Наступний крок - перезапускаємо тести на новому білді та сподіваємось, що цього разу вони будуть зеленими.

💫 Який із цього можна зробити висновок? Автоматизація тестування ніколи не є "безкоштовною" та "не працює миттєво". Деякі автори книжок навіть стверджують, що автоматизація тестування, в середньому, може прискорити процеси тестування менше ніж на 50%.

То ж не треба вважати автотести "срібною кулею". Навіть з AI! А якщо саме ви це знаєте - допоможіть це зрозуміти вашим менеджерам. 😎
24🔥16🥱1
🥊Чому автотести не замінять тестування (та при чому тут морський бій) ⛵️

#testing #automation

Давайте на хвилину перенесемось у дитинство та згадаємо гру "морський бій" (чи battleships). Малюємо своє поле й поле суперника, розташовуємо на полі кораблі й ведемо вогонь по кораблям вашого супротивника. Не знаю як ви, а я памʼятаю таку гру (в часи коли ще не було багато компʼютерів та консолей).

👨‍🔬Про експеримент

В книзі "Software Testing Strategies", автори розповідають про свій експеримент. Під час майстер класів з тестування, вони ділили учасників на дві групи та пропонували їм грати в морський бій. Умови були прості. Один з учасників гри повинен грати як завжди. Іншому є учаснику треба зазделегідь продумати план гри - стратегію розміщення та ураження кораблів (наприклад хрестом, зіркою, чи ще якось). До того ж - йому треба дотримуватись обраного плану протягом усієї гри.

Автори експерименту провели декілька сотень таких ігор. Вгадайте, скільки разів виграли люди, які чітко дотримувались плану гри? (декілька разів із сотень)

🤔 Але нащо тим нам про це розповідаєш? Де тут тестування?

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

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

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

💡 Висновки

- Автотести виконують тільки те, що ви запрограмували їх робити. Не більше, не менше.
- Тестування все-таки "... процес оцінки продукту шляхом його вивчення через досвід, експерименти та наявні знання" (М. Болтон).
- Тестування, окрім перевірки очікуваних результатів, завжди містить прихований очікуваний результат: "і нічого іншого дивного не сталося".
👍29🔥163🥱2
Чи потрібен ISTQB сертифікат

#testing

Сьогодні маю для вас дещо цікаве.

🕹По-перше, для тих, хто хоче потренуватись в CSS / XPath локаторах - маю невеличку тренувальну гру.

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

Олександра Ковальова, з якою ми якось спілкувались на подкасті, з 13го січня буде проводити марафон по ISTQB Foundation Level.
Для новачків буде вкрай цікаво - буде багато практичних прикладів. До того ж, вартість марафону - аж 0.

👉👉👉 Долучитись до марафону - ось тут!
👍193
Forwarded from Testing Minutes (Oleksandr Romanov)
⚡️ Episode 46: Software Testing in the Age of Generative AI with Mark Winteringham

AI is on hype. AI is everywhere. But how exactly do you use generative AI for software testing and automation? Is it just a fancy tool for generating test cases or ... something more? What are the challenges and problems in using modern LLM systems for daily work? To explain this topic, the hosts, Artem and Oleksandr, invited Mark Winteringham.

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

🔸 Youtube
🔹 Spotify
🔸 Apple

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

Також ви можете підтримати нас донатом на 🏦 База від Монобанку — це дійсно важливо для нас і є нашим рушієм.

Дякуємо вам!

#testingminutes | @a_grygorenko | Test Engineering Notes
7👍6
The Canva outage: another tale of saturation and resilience

#bugs

Починаємо робочий тиждень зі свіжої історії від Canva. Історії, де до падіння продакшена призвела не бага в продукті (функціонально все працювало, як треба), а проблема в складній інфраструктурі.
👍9
💼 Як змінився ринок праці

#testing #career

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

Disclaimer: це лише мої особисті думки!

🪤Ринок праці в pre-covid / covid еру

- Технічних спеціалістів було менше, ніж вакансій. Компанії конкурували за кандидатів, пропонували кращі умови та більшу ЗП
- Бюджети в COVID роздули, набрали вкрай багато людей (навіть занадто багато)
- “Увійти в АйТі” було цілком можливо, з деякими зусиллями - головне вивчити базу та зрозуміти логіку проходження співбесід
- Пофігу на освіту, вміння, знання - “вмієш писати тест кейси” або “наваяти базовий одностранічний сайт на чомусь модному типу React” - давай до нас, скоріш, скоріш - клієнт чекає!
- Бізнесмени побачили “золоту нішу” й організували десятки курсів “увійті в айті” за пару місяців. Такі курси розвʼязували проблеми компаній - нестачу спеціалістів на ринку праці. “Навчай базовим знанням, швидко, шоб пройти початкові фільтри!”

⚖️Ринок праці в post-covid еру

- Компанії, що набрали надто багато людей - скорочують персонал та оптимізують витрати. Ринок розвернувся діаметрально та став “ринком роботодавця”
- Купа людей в Україні втратила роботу та “спокусилася” яскравою рекламою курсів “заробляй тисячі баксів легко за місяць навчання”. Бізнеси курсів заточені на швидке й поверхневе навчання - все ще продають той самий товар, в більш яскравій обгортці
- Десятки тисяч людей, що закінчують такі курси - виходять на ринок з однаковим набором знань
- Вакансій стає все менше, конкуренція - все більше. Вимоги до кандидатів виросли. Зʼявилися чітки позиції трейні. Сотні людей претендують на одну вакансію
- Випускники курсів не можуть знайти першу роботу в АйТі. Чому? Бо курси запевнили їх в тому, що їх програми вистачить для отримання роботи. Після місяців пошуку - люди розчаровуються й шукають роботи в інших сферах
- В еру жорсткої конкуренції стає важливим не просто поверхневі, а глибокі знання. Важливе вміння вчитись та розбиратись в новому. А для швидкого навчання потрібні фундаментальні знання. Якщо їх немає - буде набагато складніше вчитися. (Не кажу, що то неможливо, але складніше)
- Курси все ще продовжують продавати ідею “швидкого навчання”, але відмовляються визнавати, що отримання знань для роботи - це справа в розрізі півроку - рік, а то й більше. (Деякі курси, можливо, вже змінюють програми навчання, але поки не бачив такої тенденції)
- Курси від АйТі компаній вирішують цю проблему проводячи вхідні співбесіди з високими вимогами вже на старті.

🕶Що робити? Про це - в іншому пості.
👍197
🎙Як компанії обрати кращого тест інженера

#testing #interview

Ben Fellows поділився цікавим підходом для оцінки рівня тест інженерів на співбесіді. Зазвичай, Ben шукає кандидатів рівня 3 або 4.

Питання:

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


1️⃣Рівень 1 - Реактивний та сфокусований на задачі.

Я почну з тестування логіну та покупки, тому що вони найголовніші.


2️⃣Рівень 2 - Баланс між технічними та бізнес потребами, але без структурованого підходу.

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


3️⃣Рівень 3 - Використання структурованих фреймворків, пріоритезація ризиків, вибір тестових активностей в залежності від бізнес задач.

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


4️⃣Рівень 4 - Застосування системного мислення, прогнозне моделювання та безперервне покращення

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


А ви як думаєте? Яка відповідь найкраща?
👍24🤡91
🍟 Сервіси для швидкого навчання

#learning #llm

Я багато читаю та дивлюся різні доповіді. Значна частина з того - дослідницькі роботи чи дійсно великі статті.
Але щоб прочитати статтю чи роботу на 10-20 сторінок треба багато часу.

То ж я спробував декілька сервісів, які обіцяють значно пришвидшити темпи читання матеріалів. А саме: NotebookLM (від Google - то ж на базі Gemini) та YouLearn

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

Мінуси
- NotebookLM ще не доступний в Україні (можна через VPN). YouLearn - вже можна використовувати
- Обидва сервіси працюють лише з текстом. Тож графіки вони не зрозуміють
- Треба ще більше вільного часу щоб ще й слухати статті у вигляді подкасту
- Сервіси "звільняють" нас від годин читання, але забирають отой А-ХА момент, коли ми саме навчаємось, звʼязуємо концепти між собою.

Висновок: цікаво спробувати, але користуватись кожного дня я скоріш не буду.
👍22🤔3
Forwarded from Testing Minutes (Oleksandr Romanov)
⚡️ Епізод 47: Евристики та мнемоніки в тестуванні

Евристики? Мнемоніки? Що це таке? Навіщо вони потрібні? Які мнемоніки існують? Та як можна користуватись ними на практиці? Про це сьогодні будуть говорити ведучі подкасту - Артем та Олександр.

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

🔸 Youtube
🔹 Spotify
🔸 Apple

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

Дякуємо вам!

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

#testingminutes | @a_grygorenko | Test Engineering Notes
1👍20🤡1
Робимо свою базу даних за допомогою інструментів Linux

#linux

Коротка, але дуже цікава стаття про те, як можна створити базу даних за допомогою нативних інструментів Linux - grep, cut, awk, sort, head, tail та join.
👍13😁21
The end of the "Self-Taught Programmer"

#video

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

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

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

Sad, but true.
👍13😁1
Forwarded from Testing Minutes (Artem Grygorenko)
⚡️ Епізод 48: Як тестувати перфоманс - з Антоном Серпутько

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

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

Послухати або подивитись епізод можна тут:
📹 YouTube
🎵 Spotify
🎵 Apple

Коменти та фідбеки обов'язкові 🔫
Підтримати подкаст можна через: 💳 База від Монобанку

#testingminutes | Нотатки Суворого QA | Test Engineering Notes
Please open Telegram to view this post
VIEW IN TELEGRAM
👍144🔥2
Це - геніальний хід (якщо правда). Браво, DeepSeek 😀
😁17🔥2
Обережно з coding інтервʼю

Тільки вчора говорили в Діскорді про задачі на інтервʼю, тестові завдання.

А тут виявляється, шо є варіант отримати собі під час співбесіди небезпечний код, який буде шукати гаманці та намагатись поцупити вашу крипту)
🤯31👍3
Partner Chains Development Lifecycle: Our CI Evolution

#testing #automation #blockchain

Колеги з команди поділились історією розвитку нашого CI.

Наша система залежить від довжини епохи основного блокчейну. На різних енвайроментах вона різна - від 24 годин до 5 днів!

Спочатку в нас була кастомна модифікація блокчейну з довжиною епохи в 2 години.

На наступному етапі ми працювали із Cardano Preview, де епоха становить 24 години. Підтримувати CI стало набагато простіше, але тестувати - ніт. Будь-які модифікації в нашій системі можна побачити ... через 48 годин. Більшість автотестів була - "почни тест, перевір що результати два дві тому були коректні, зроби нові зміни, зафіксуй їх в тестовій базі даних". Це ... працювало, але дуже довго.


Як покращення, ми взяли тестову версію головного блокчейну (як тільки-но зʼявилась), закинули усі компоненти в Docker та запускаємо їх docker-compose. Тепер результати автотестів не треба чекати 48 годин - а тільки 15 хвилин. Це суттєво краще та зручніше.
👍91
Forwarded from Testing Minutes (Oleksandr Romanov)
⚡️ Episode 49: Software testing and quality culture for airlines with Simon Prior

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

Тому в цьому епізоді подкасту ми розмовляємо з Simon Prior про тестування та культуру якості в ... авіакомпанії easyJet. Як там тестують? Як організують команди? В чому складності?

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

🔸 Youtube
🔹 Spotify
🔸 Apple

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

Дякуємо вам!

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

#testingminutes | @a_grygorenko | Test Engineering Notes
👍18
Пост для тих, хто хоче стати QA Lead

У мого колеги з подкасту Testing Minutes, Артема Григоренко, відкрито запис на лютневий потік "Шлях до QA Leader" - курс для тих, хто хоче вирости з інженера в гарного лідера QA команди.

Чому цей курс може бути цікавим? Там буде багато корисної інформації, практичної роботи, запрошених лекторів. Навіть тим, хто вже працює лідом курс зможе донести щось нове.

Програма курсу оновлюється та доповнюється постійно. Я це знаю, бо сам цей курс пройшов 😀

📅 Коли початок? 17 лютого

💎Бронь місця - $200 (Можна оплатити частинами або через компанію👌)

Залишились питання або готові почати? Пиши в Telegram: @artem_grygorenko або шукай на сайті: grygorenko.tech
🔥52😁1
Forwarded from Testing Minutes (Artem Grygorenko)
🎙 Testing Minutes: ваші запитання — наші відповіді! 🔥
Хотіли щось у нас спитати? Саме час! ;)

Ми готуємо новий епізод Testing Minutes і вирішили: а давайте відповімо на ваші запитання!

Можливо у вас було таке, що слухали наш подкаст і думали: “От би спитати їх про це…”? Або просто цікаво дізнатися щось про нас, нашу роботу, думки чи факапи?

Заповніть формочку нижче і чекайте на наступний епізод:
https://forms.gle/93VqjTCJK5cRGD7J6
Про інформацію й знання

Іноді ми використовуємо слова інформація та знання як одне й те ж, хоча це різні поняття.

Інформація - це "сирі" дані в поточному контексті. Для прикладу, факт того, що Microsoft купила якусь компанію з мільярд доларів - це лише інформація. Інформації в сучасному світі вдосталь.

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

Питання інформації й знань також дотичне до вибору будь-яких тренінгів й курсів:

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

Хороший курс може суттєво пришвидшити ваше навчання й бути наче тим підвісним містком між незрозумілими концепціями та усвідомленим застосуванням.
1👍174