| Mother of QA |

Всіх вітаю з пʼятничкою! Я вже по троху наздоганяю всі заплановані події! І сьогодні мала змогу переглянути вівторковий вебінар з «Суворої QA комʼюніті» і слухали ми доповідь від iOS розробника з United Tech про колаборацію між Dev та QA! 👩🏼‍💻 Олександр Березовський: «Mission Possible: How to improve collaboration between Dev & QA»1.0. QA очима розробників. 💡 Розробники теж повинні розуміти різницю між QA -> QC -> Testing. ❌ Міф про тестувальників - «Тестувальник - це особистий помічник деяких ролей на проєкті». 💅🏼 Якщо DEV побачив можливість поліплшення якості продукту - він здатен самостійно завести задачу. Він не чекає QA! ⚠️ QA не має адмініструвати технічні рішення, інакше він перетворюється на операційного асистента. ❗️ Відкладене «потім заведу» = процесна втрата, адже ми не працюємо з превентивною якістю.🫶🏼 Коли розробник знайшов баг раніше тестувальника, то він заводить тікет і фіксить. Це має бути про кожного поважаючого себе розробника! 🪥 Dev відповідає за технічну гігієну: • Логування. • Рефакторинг. • Юніт тести. • Зменшення legacy. • Cleanup. • Стабільність білду. ❤️ Сильна команда працює так: • QA заводить тікети на функціональні дефекти, UX проблеми і тд. • Dev заводить тікети на технічний борг, архітектурні покращення, стабілізаційні задачі, інструментарії для тестування. ❗️ Обоє мають думати про якість, але на різних рівнях.QA на рівні якості продукту.Dev на рівні якості коду.2.0. Тестування в продукті / аутсорсі. ❗️Продукт - це не завжди хороші процеси та тестування. Продуктова модель не гарантує якість. Аутсорс не означає слабку якість. ⚠️ Вирішальне - це не модель компанії, а: • Чи залучений QA з самого початку? • Чи є спільна відповідальність?• Чи є DoD?• Чи проводяться ретроспективи?• Чи є культура «виправити причину, а не симптоми»?💡 Якість визначає те, як побудований процес і розповідна відповідальність QA & Dev. 3.0 Долучення QA до команди розробки. 🫶🏼 QA не просто тестує «після», а й впливає на структуру задачі. ❗️ Тестування перед релізом - повинне стати НЕ єдиною точкою контролю, бо якість фічі має готуватись з самого початку. 💡 Важливо після релізу не «хто пропустив», а «що потрібно покращити в процесі». 4.0. Що Dev винен QA. • CI/CD інтеграція. • Контроль зміни Feature Flags. • Логування (REST, Sockets, Internal errors, etc.). • Reset / Clear state. • Token injection. • Інтеграція сервісів за запитом QA. Хороший дебаг тулінг економить дуже багато часу тестерів та команди в цілому.5.0. Ідеальний тікет. 🫶🏼 Хороший баг - це вже половина фікса.💡 Dev повинен зрозуміти: • Що сталось? • Де сталось? • Як повторити?• Що очікувати?😍 Ідеальний тікет очима розробника: • Чіткий заголовок • Середовище • Кроки відтворення • Очікуваний результат з пруфами• Фактичний результат • Докази • Додатковий контекст (чи є workaround, чи впливає на інших користувачів, чи це регресія, чи стабільно відтворюється) • Бонус (креди, токени юзерів і тд.)❔А яка у Вас взаємодія з розробниками? 😍 - дуже класна та ефективна. ❤️ - нормальна, але хотілось би краще. 😭 - дуже важко з ними співпрацювати. 🤯 - гриземось як кішка з собакою.

Всім привіт колеги! По троху намагаюсь повертатись в ритм, звикаючи до роботи і всіх інших справ 😄Пройшло декілька днів після DOU, я змогла порефлексувати і перетравити все, що там відбувалось! І сьогодні, як і обіцяла, хочу з Вами поділитись відгуком про DOU Day 2026! ⏱️ Тривалість: 2 дні + 1 день різноманітних івентів. 🎙️ Стейджі: Core, Engine, Growth, Future, Business, Podcast.📚 Більше 50 різних доповідей та дискусій. 🫱🏻‍🫲🏼 З точки зору нетворкінгу: це найкраще місце! Тут Ви знайдете багато компаній, багато цікавих людей, зможете розвіртуалізуватись з багатьма знайомими і тд. ☕️ З точки зору корисної та прикладної інформації: цьогоріч я не знайшла для себе нічого. І мабуть в цілому, знайти щось буде важко. Бо конференція загальноайтішна і зрозуміло, що доповіді будуть загальні, щоб охопити якомога більшу аудиторію. 👂Я прослухала десь 8-10 доповідей повністю і ще бігала між сценами, щоб почути про те, що там розповідають. І чесно кажучи в більшості доповідей я була розчарована( Ніякої прикладної користі, багато води, загальні поняття і занадто багато АІ.Я відчувала дуже великий геп між тим де я і що роблю і тим, що доносили на сценах. Складалось враження, що тут говорять про високі матерії, які простим «робочим коникам» ще не доступні)Цьогорічне DOU дуже нагадало мені IT Arena, яка теж, з моєї точки зору, корисна лише для партнерств, компаній, пошуку роботи, контактів, колег і тд.👩🏼‍💻 Якщо підсумувати, то конференцією я задоволена, бо їхала я туди, перш за все за нетворкінгом. Але якби їхала за знаннями, новою інформацією, унікальним досвідом спікерів - я б дуже розчарувалась….💻 Це вже третя конференція від DOU і я була на всіх з них! То ж, порівнюючи, можу сказати, що перша конференція, по наповненню інформацією та переліку тем, мені сподобалась найбільше! Дуже бракувало вузьконаправлених стейджів, таких як Testing, Development або принаймні Technical. Але, що можу сказати точно - це те, що організація, масштаби, координація, безпека та інші нюанси ВРАЖАЮТЬ! DOU вміє дослухатись до людей, до їхніх відгуків та робити висновки / покращення! Я дуже пишаюсь, що в Україні є конференція такого масштабу! І сподіваюсь, що наступні будуть кращі, цікавіші та досконаліші за своїм наповненням! ❤️❔А тепер діліться своїми враженнями після конференції - як Вам?

🏆 Досвід здачі ISTQB Advanced Level Test Management 3.0 🥇Обіцяла написати трішки більше деталей, то ж поїхали! ℹ️ General info: • Іспит здала з першого разу. • Іспит тривав ~ 2,5 години (я закінчила за 2). • Питання на іспиті сильно важчі, ніж на тренувальних мок тестах. 📖 Long story: Я готувалась до іспиту на курсі і підготовка зайняла ~ 3,5 місяці. Протягом курсу я отримала всі матеріали, інформацію та поради щодо здачі. Після закінчення курсу я на місяць забула про іспит, бо як раз втратила роботу і активно її шукала. Потім у мене були проблеми з купівлею і на їх вирішення пішло десь два тижні. ⚡️ Спойлер: проблема не вирішилась, але знайшовся воркераунд. І от - місяць після курсу я пішла здавати іспит не повторюючи абсолютно нічого, і вирішивши, що я мушу здати з того, що я дійсно вивчила… ну, а якщо вже не здам, то піду повторювати…⚙️ System check я пройшла без проблем і далі все як в тумані…З першими двома іспитами, я заходила -> бачила перше питання -> розуміла що все ок -> і на цьому офігенному настрої фігачила іспит! 🌚 Тут я зайшла на перше питання -> офігіла -> скіпнула -> пішла на друге -> офігіла -> пішла на 50 і почала проходити іспит знизу, бо втратила надію на «почати з меншого». ℹ️ Проте я всерівно якось підсвідомо починала з маленьких питань - читати страшні таблички мені було дуже важко, бо першу частину іспиту я розкачувалась! 📖 Коли прийшов час передивлятися питання я зрозуміла, що в жодному я не впевнена і в частині з них для мене мінімум 2 правильні відповіді! То ж, як і перші два іспити я нічого не перевіряла і не міняла - бо з мого досвіду, це призводить тільки до гіршого. ✔️ Якщо здаючи FL та ATA я була впевнена що мінімум наберу, то з TM я до кінця не знала чи складу взагалі. 🥳 Але склала, то ж оновлюю Вам свої лайфхаки по підготовці до іспиту! 1️⃣ Спочатку читаємо питання - тоді вже умову задачі і тд. 2️⃣ Починайте з візуально менших запитань (з мого досвіду так психологічно легше). 3️⃣ Перечитуйте питання перед вибором правильної відповіді (частки NOT, MOST important і тд. часто забуваються після прочитання всіх варіантів відповідей). 4️⃣ Не виправляйте після вибору відповіді (патерн: перша відповідь - правильна, дійсно працює)! 5️⃣ В задачах звертайте увагу на слова significant, important, crucial, critical і тд. (саме такими словами вони дають Вам підказку - що це дуже пріоритетно і відповідь потрібно шукати відштовхуючись, перш за все, від цієї інформації). 6️⃣ Якщо довго не можете обрати відповідь - позначайте питання і йдіть далі! Це дійсно дуже допоможе! 7️⃣ Не повторюйте нічого в день екзамену! Ви тільки забʼєте голову ще більше і вся інформація перетвориться в кашу. Пригадати щось буде в рази важче. 8️⃣ Обовʼязково беріть водичку з собою на стіл (від хвилювання Вам може пересохнути у горлі + водичка допомагає віднайти рівновагу). 9️⃣ Якщо відчуваєте, що важко сконцентруватися - помасажуйте пучки пальців, потріть руки, пощіпайте мочки вух, вдихніть та видихніть, закрийте очі на декілька секунд. Всі ці дії стимулюють Ваші нервові закінчення та допоможуть сконцентруватися. 1️⃣0️⃣ І останнє, але не менш важливе - підготуйте все заздалегідь. Облаштуйте місце здачі всім необхідним, створіть воркераунди для непередбачуваних ситуацій (зникнення інтернету, зарядка ноута і тд.). Ну і якщо потрібна підтримка та настанови - пишіть мені, мамка допоможе 😁🫶🏼 Доречі, раніше я писала таку статтю для підготовки до FL, багато порад там працюють і з іншими іспитами - то ж, залітайте читати ⬇️Лінк на статтю тутЯ сподіваюсь Вам було корисно, то ж чекаю на Ваші лайки, коментарі та поширення! 🫶🏼п.с. про DOU Day розкажу згодом!

Доброго ранку друзі! ✨Випала з каналу через дуже інтенсивний і цікавий онбординг у компанії! (але про це згодом 🤫). Але повертаюсь до Вас із витримкою із вівторкової доповіді у «Суворій QA комʼюніті»! 👩🏼‍💻 Катерина Мараховська: «Мобільні Flutter додатки: типові баги, їх пошук та інструменти тестування»🕊️ Flutter - це кросплатформений фреймворк від Google, що використовує мову Dart. Дозволяє з єдиної кодової бази розробляти додатки для iOS, Android, Web, Desktop.➕ Переваги: • Міжплатформена розробка. • Власний рушій рендиренгу. • Все є віджетом. • Доступ до нативних функцій. • Висока продуктивність. • Мова Dart. • Hot Reload. ➖ Мінуси: • Великий розмір додатка. • Нативні АРІ іноді потрібні. • Менша кількість mature бібліотек. • Нативний UI не завжди точний. • Продуктивність у складних сценаріях. • Залежність від Goggle. 🪲 Типові баги: 📍 Keyboard overlap ❔Як виявити? • Фокус на нижні поля. • Зміна мови клавіатури. • Landscape mode. 📍 Overflow error ❔Як виявити? • Малий екран. • Font Scaling. 📍 Помилка контексту ❔Як виявити? • Тестування на слабкому інтернеті. • Monkey Testing. 📍 Junk & Stuttering animations ❔Як виявити? • Тестувати одразу після встановлення. • Скрол важких списків. 📍 State Loss ❔Як виявити? • Tab switching. • Backgrounding. 📍 Infinity scroll ❔Як виявити? • Stress scroll. • Empty & large data. 📍 Platform channel exception ❔Як виявити? • System permissions. • Hardware state. • Тестування на реальних девайсах. 📍 Platform UI mismatch ❔Як виявити? • Навігація та екрани. • Діалоги та вибір. • Елементи керування. 💡Обовʼязково тестуємо на Samsung. ❔Що обовʼязково тестувати? • UI та UX. • Інтеграції. • Авторизація та доступи. • Системна поведінка. 💡 Після оновлення версії Flutter необхідно робити повні регресії. Бо бібліотеки можуть імпактити все.🪛 Інструменти, що допомагають шукати баги: Flutter DevTools: • Flutter Inspector • Logging view • Network view• Performance view • Memory view • CPU Profiler View❤️ У Flutter також є свій фреймворк для автоматизованого тестування! Під час доповіді у нас було невеличке демо інструментів і дійсно, Flutter має багато крутих можливостей! 🔥❔ А Ви тестували (тестуєте) Flutter додатки? 🔥 - тестую зараз. ❤️ - тестував (-ла) раніше. 🌚 - ніколи не працював (-ла) з ними.

Сьогодні була на вебінарі у Суворій QA спільноті і говорили ми про координування процесів у великих командах ✨ 👩🏼‍💻 Оксана Троян, «Управління ентропією: Як координувати QA-процеси в командах на 30+ інженерів».❔Чому масштабування ламає процеси? • Те, що працювало для 5 людей, не працює для 10+. • Втрата контексту. • Час на мітинги росте. • Розмиття фокусу. • Рішення замикаються на одній людині. ❗️Масштабування без зміни архітектури процесів - це саморуйнування системи. 💡Принцип «Якщо це не в Jira, то це НЕ існує». ✨ Налаштування Jira для великих QA департаментів: • Візуалізація впливів та залежностей. • Уніфікація воркфлоу (прозорість, впровадження єдиних типів задач і статусів). • Кастомні дешборди (для інженерів, лідів, стейкхолдерів). • Впровадження WIP лімітів (обмеження кількості задач в «Testing”, DoD, заборона розпилення фокусу). 💡Лід це навігатор, а не водій кожного авто. Треба менторити людей - це основна опція для того, щоб зробити процеси кращими і не бути тим, на кому завʼязано все.📍Структура менторингу: • Peer to peer review. • Knowledge base. • Матриця компетенцій. • 1:1. 🫶🏼 Формування внутрішньої QA спільноти: • Внутрішні демо дні. • QA гільдії. • Knowledge sharing. • Ритуали «Slack Time». • Data- driven підхід. 💡 Хочеш йти швидко - йди один. Хочеш йти далеко - йдіть разом.❔А у якій QA команді працюєте Ви зараз? 🥲 - я один (-на). ❤️ - до 10 людей. 🤩 - 10-50 людей. 😱 - 50-100 людей. 🤯 - більше 100.

Вівторкового вечора друзі ✨Наразі я на 3-ьому тижні онбордингу і так багато інформації потрібно абсорбувати, що до каналу та інших навчань зовсім не доходять руки 😅Але я по троху повертаюсь і даю Вам вижимку з минуло-тижневого вебінару у Суворій спільноті! Гайда дивитись! 👩🏼‍💻 Ірина Джунь, «АІ: як стати непотрібним в 10 разів швидше»1️⃣ Роби АІ- first стратегію, бо це модно. ❌ Грішать цим: СЕО, СОО, СDO, CTO і тд. 2️⃣ Роби roadmap через АІ та ігноруй реальність. ❌ Грішать цим: C- level, Product management, Delivery Management.3️⃣ Роби АІ своїм головним радником. ❌ Грішать цим: C- level, Delivery management, Product management, Operation management.4️⃣ Роби більше артефактів через АІ, вони ж безкоштовні. ❌ Грішать цим: Delivery management, BA/BA lead, QA lead, Product management.5️⃣ Зроби ще один мітинг, бо АІ асистерт не зрозумів контексту. ❌ Грішать цим: Delivery management, Engineering management, Product management. 6️⃣ Роби ще більше метрик, щоб нічого не зрозуміти. ❌ Грішать цим: Delivery management, Engineering management.7️⃣ Роби так, щоб кожна технічна практика жила у своєму АІ мікровсесвіті❌ Грішать цим: всі ліди. 8️⃣ Роби ще більше алертів, щоб їх всі ігнорили. ❌ Грішать цим: Dev, QA, DevOps. 9️⃣ Роби АІ генеровані естіммейти і вір у них більше, ніж у реальність. ❌ Грішать цим: всі.1️⃣0️⃣ Будь швидким, АІ дженерейтед, і безтолковим.❌ Грішать цим: всі. 1️⃣1️⃣ Навали в артефакти стільки води, щоб ніхто нічого не розумів . ❌ Грішать цим: BA, QA, Dev, Product Management, Delivery Management.1️⃣2️⃣ Втрати здатність пояснювати як це працює ❌ Грішать цим: BA, QA, Dev, Product Management, Delivery Management.Протягом цієї доповіді кожен пункт супроводжувався реальною історією з життя якогось ІТ-вця, бо саме для цього Ірина їх опитувала! І це було надзвичайно динамічно, цікаво і місцями страшно від того, як зараз намагаються впихнути АІ всюди без очевидної доцільності! ❔А як часто у Вас «пхають» АІ просто «аби був, бо модно»?😭 - постійно. 💔 - часто. ❤️‍🔥 - дуже рідко, у нас свідоме використання АІ. 🏆 - ніколи.

⚠️⚠️⚠️Друзі, принесла дуже класний анонс! Раджу не пропустити і завітати! Тим більше за донат!!! 30 квітня стартує традиційний QA-марафон від QARMA про АРІ тестування 🔥❔Що буде на марафоні цього разу? День 1. Логін. Що всередині токена? — декодуємо JWT руками і дивимось, що сервер про нас розповідає. Знайомимось з DevTools Network.День 2. Статус «200». А що в body? — розбираємо, як сервер бреше: 200 з помилкою в body, з порожньою відповіддю, з чужими даними. Підключаємо Postman.День 3. Форма відправлена. Що прийняв backend? — фронт-валідація ≠ захист. Обходимо її напряму через Postman і дивимось, що бекенд приймає насправдіДень 4. ID у URL. А якщо змінити цифру? — IDOR, один з найдорожчих класів багів у проді. Розбираємо на Restful Booker і вчимось ловити auth ≠ authz.День 5. Покупка товару. А на межі — що? — бізнес-логіка, edge cases, абсурдні дати, rate-limit. Там, де формат ідеальний, а сенс зламаний — і бізнес втрачає гроші.День 6. Swagger обіцяв одне, реальність — інше — контрактні баги. Читаємо OpenAPI, звіряємо з реальною поведінкою API і шукаємо розбіжності.День 7. Баг знайдений. Що далі? — упаковуємо знахідки в професійний bug-report (Impact, Severity, Steps). Перетворюємо марафон на портфоліо. Марафон підійте тим, хто трохи знає API, але відчуває, що є куди рости 😊🎁 А для тих, хто здасть всі домашки до 9 травня включно і опублікує пост з інсайтами в LinkedIn — розіграш безкоштовного місця на курсі CSA & API та інші бонуси на навчання.📅 Дати: 30 квітня — 6 травня💸 Участь: донат на ЗСУ від 500 грн💳 Банка: 4874 1000 2721 2383🔗 Посилання: https://send.monobank.ua/jar/9WENAQ3JxDЩоб приєднатись — закидайте донат від 500 грн на банку і переходьте по посиланню, яке з'явиться як нагорода в моно. Або пишіть в телеграм @innaosinna

Всім робочого вівторка! ✨Повертаємось в ритм! Сьогодні був той рідкісний випадок, коли я була на Суворому вебінарі в лайві і поки Q&A/ афтерпаті і тд. ще триває - Ви вже можете зазирнути про що ми говорили сьогодні! Летс гоу ✈️ 👩🏼‍💻 Юлія Гончар, «Сильна команда: що насправді об’єднує людей»🫱🏻‍🫲🏼 Команда - група людей обʼєднаних спільною метою які несуть спільну відповідальність за результат.❗️Команда != сімʼя.✨ Атрибути ефективної команди: • Розділені ролі. • Сформульовані цілі. • Виставлені пріоритети. • Є авторитетність. • Конфлікти вирішуються відкрито. • Є чіткі правила, які виконуються. • Достатньо зворотнього звʼязку. • Команда знає критерії успіху.🧗🏼‍♀️Етапи розвитку команди за Такманом: • Forming - тут важливо визначити і чітко проговорити цілі та визначити і оголосити правила. • Storming - тут важливо бути уважним до знаків (проблеми, образи, звинувачення). • Norming - тут важливо виділяти продуктивні дії і продовжувати їх робити. • Performing - слідкуйте за ситуацією, вимірюйте основні показники та нагороджуйте/ заохочуйте. • Adjourning.📚 Книги: • 5 вад у роботі команди, Патрік Ленсіоні. • Ідеальний командний гравець, Патрік Ленсіоні.💗 Люди люблять свою роботу бо: • розуміють конкретно, що означає «добре зроблена робота». • розуміють велику ціль та взаємозвʼязок з конкретними діями. • відчуття персонального піклування.❗️Прості тімбілдінги чи активності самі по собі не працюють, бо активність без мети = розвага без змін.❔А через що Ви найбільше любите свої компанії? (Гарна компенсація, бенефіти, атмосфера, команда і тд.) Пишіть у коментарі! 💗

Христос Воскрес! Повертаюсь до Вас із невеличкого відпочинку! Цього разу пропустила аж 2 вебінари у Суворій Комʼюніті через свята і от наздоганяю! На першому вебінарі ми говорили про АІ ✨ Гайда дивитись! 🧑🏻‍💻 Михайло Боднарчук, «Self-Driven AI Testing Agent — що може тестувати веб сайти за вас»Протягом вебінару ми дивились на live трансляцію агентів, які використовуються в роботі. Вижимку цьому дати важко, але ось декілька думок: ⚖️ Агенти можуть бути розподілені, у кожного агента може бути своя функція. Ми розглядали на прикладі Михайла і у них було 3 агенти: planning, testing, pilot.⚒️ Open Router - сайт де зібрані всі АІ провайдери і моделі.Наступний вебінар був про РМ, про типові помилки та чому їх припускаються, про хаос, менеджмент і все інше… 👩🏼‍💻 Каріна Алєксєєнко, «Чого РМ вам ніколи не розповість»💨 Хаос виникає від бюджетів, графіків, формату роботи, навантаження, виду компанії, процесів, типу контрактів, ринку і тд.✨ Менеджери - зазвичай світчери і часто стають в ІТ ними випадково - і з цим є проблема. Бо менеджмент є інтуїтивним.🥲 Менеджер може слідувати якомусь процесу де почув чи бачив - і ось хаос. Бо ніколи не вгадаєш. Бо спочатку маєш знати еталон -> тоді розібратись у купі доменів -> а тоді побудувати процес, який спрацює.⚒️ 3 стадії обізнаності керівництва: 🔥 Виживання - все горить. ❔Що робити? • дисциплінувати себе. • фокусуватись на беклозі. • створити мінімальний горизонт планування. • створити мінімальну документацію. • налаштувати дисципліну. ⚖️ Стабільність - є якась документація, звіти, церемонії, але все ще важко. ❔Що робити? • фреймворки. • стандарти та автоматизація. • робота з командою. • звітність та метрики. • бюджет. • якість. 🧗‍♀️Розвиток - на проєкті порядок, всі задоволені, чітке та стабільне делівері. ❔Що робити? • делегування. • менторство. • робота з клієнтом. • управління ризиками. • нетворкінг. • планування карʼєри. ❗️Будь яка автоматизація має право на існування, коли налаштований процес і всі учасники підтвердили, що він класний.✨ Менеджер має бути креативним, бунтарним - бо він будує процеси і шукає шляхи для покращень.❗️Періодично моніторте, хто стільки заробляє у вашому сегменті. Аналізуйте ринок. Це потрібно робити проактивно.💰 Витрати на комунікацію неочевидні, але вони великі.Більша команда не зробить продукт швидше.✨Потрібно вчитись працювати в time blocking.❗️Кількість важливих і термінових задач має бути маленька - бо це форс мажори. Якщо по іншому - це погані процеси.Такі от вебінари! Побачимось 🫱🏻‍🫲🏼

⚒️ Технічні співбесіди…. Ох пройшла я їх багацько за ці тижні пошуків.І обіцяла поділитись спостереженнями щодо цього! ✨ Інсайт який вчергове прийшов у мою голову: «Проводити співбесіди гарно - це справжнє мистецтво». На більшості співбесід (на Senior позиції, важливо розуміти❗️) чомусь я почула сухі теоретичні питання. І з того, що я чую і запитую потім про проєкт - я розумію, що те, що мене щойно запитали - ніяк не дотичне до того, що я буду робити. І от знайшла 100% метч-картинку - те що питають на співбесіді не співпадає з тим, що насправді людина робитиме на роботі. З моєї точки зору, це жахливо. Як на мене - запитувати потрібно про те, що буде безпосередньо стосуватись роботи, на яку Ви шукаєте кандидата. І важливо, формувати кейсові питання, ситуативні питання, питання з практики і тд. і тд. - теоретичні питання не здатні показати реальні знання людини. Це ж не екзамен з ISTQB Foundation, врешті решт 🥲Скажу відверто, що протягом часу пошуків у мене було НЕ більше 5 співбесід, які мені дійсно сподобались. • Питали виключно те, що буде стосуватись моєї майбутньої роботи та обовʼязків. • Питали про досвід. • Питали кейси, ситуації, практичні питання. І це найкраще що може бути! Дякую таким компаніям та інтервʼюерам!!!Це вселяє надію, що ще не все втрачено 😅🫶🏼❔А що Ви думаєте з цього приводу? Як часто Вас питають суху теорію на співбесідах? 🥲 - часто. 😍 - дуже рідко, у мене були лише гарні співбесіди. 🫱🏻‍🫲🏼 - 50/50.