Дякую за подкаст! Дуже весело було чути думки на рахунок тестового завдання, одразу відмітив, що, мабуть, спікери давно інтервю не проходили) В Німеччині активно шукаю роботу вже, десь більше півроку. Тестові дають КОЖНИЙ раз! Це на позицію сіньор та після проходження технічної співбесіди. Маю досвід 11+ років QA , 8 з яких Automation ( Java, Kotlin, Python Typescript, Swift ), остання позиція QA Lead. Завдання рідко бували не менш ніж на тиждень. Нещодавно й на проді давали селеніум автотести написати) Нещодавно співбесідувався в українські компанії - така шара порівняно з Німеччиною! Дуже приємно, коли вірять на слово. Але, нажаль, й проекти не такі цікаві та й дуже позицій мало стало(((
Посилання ютуб не пропустить, але можете подивитись наступні випуски: ✅ Питання якості #12. Частина про продуктовий/аутсорсний майндсет ✅ Питання якості #11. Частина про Хто відповідає за якість ПЗ ✅ Питання якості #10. Про стартапи
Випускникам курсів додатково пропонують послугу вирішення/перевірки тестових завдань. Саме тому реально не бачу сенсу в тому, коли тестове просто надсилають і хтозна - будуть перевіряти, чи ні, може поки ти його робиш - взагалі закриють вакансію. Декілька разів я особисто стикнулась із тим, що жодного фідбеку після тестового взагалі не було, наче в пустоту відправила) Та вважаю, що тестове має бути обов*язково саме частиною технічної співбесіди. Не варто довго розповідати теорію (тимпаче все легко загуглити в ході інтерв*ю) - варто просто лише на прикладі озвучити хід думок для вирішення того чи іншого практичного питання. Одразу буде видно, чи взагалі людина щось розуміє і знає. А якщо не знає - як буде здобувати інформацію.
😂😂🎉🎉ЗАЛИШАЙТЕ НЕГАТИВНІ КОМЕНТИ ПРО КОМПАНІЮ НА ДОУ!!!!!! І всі мудаки одразу почнуть попускатися! І не бійтеся що про вас подумають плохо і мабуть десь вас ще не візьмуть за це. З Повагою до початківців, власник ІТ компанії ;) ПС. Якщо знаєте англійську то в загалі можете подаватися одразу за межи України. Але це зараз я вже накличу на себе плач інших менеджерів і власників 😂😂😂😂 Але тут богато плюсів теж..
@@carloniaso Ваша правда про відгуки. Я не соромилась в тактичному описанні плюсів і мінусів) Та помітила сумну тенденцію, що негативні відгуки не наважуються написати відсотків 90 з тих, хто не задоволений чимось (факт того, що треба висвітити свою особу мабуть тут грає не на користь). І потім маємо: компанія майже шахрай, а відгуки класні... Сподіватимемось, коли вирівняється ситуація на ринку на користь працівника, а не роботодавця - все прийде в норму
@@oltrastar Приведу приклад, Я даю задачі людині яка відповідає за цей напрямок давати обов’язково фідбек, так як це теж лице компанії, але людина по різним причинам цього не робить. Я фізично відстежити в загальному це не встигаю і не можу. Але всі коменти о компанії контролюю і потім роблю розбір ситуацій. Тобто в загальному коменти о компанії грають велику роль і за них майже всі трясуться !!!
Як свічер, попервах дивувалась, чого такий холівар в ІТ щодо тестових. В багатьох галузях взагалі є пробні 2-3 дні - НЕОПЛОЧУВАНІ - подивитись чи орієнтується і чи потягне людина. І, як вірно Ольга озвучила, коли треба шось їсти, то і тестове зробиш ))) Доводилось робити тестові при пошуку першої роботи. Але символічного характеру: якась бажна веб-сторінка (видно що спецом для тестів і зроблена), якийсь калькулятор. Пару годин на виконання і корона не впала. А якщо вже попадається комусь неадекватне тестове - це червоний прапорець на адресу контори. Зараз в пошуках мідл позиції, і можу відзначити, що на мідлів вакансій з тестовими не бачила (можливо тому, що шукаю мануал, можливо автомейшенам щось таке й пропонують). І після ваших жахастиків про "зашорених девелоперів, що живуть у своїй мушельці" стає трохи стрьомно 😅 Бо своїх колег по минулих проектах можу тільки хвалити і ставити за приклад і в професійності, і по софтскілах.
Я не зовсім розумію концепцію прихованих метрик. Якщо у компанії є цінність, яка відображається певною метрикою, то чому б не сказати про неї працівникам, щоб вони могли докладати зусилля саме в напрямку примноження цієї цінності? А якщо залишається місце для зловживань, то, на мою думку, це погана метрика, вигадана для галочки, за нею реальної цінності для компанії не стоїть і на неї витрачати ресурс недоцільно.
Складне питання. Будь-яка метрика недосконала, це лише відмітка, а цінності більші. І є ризик зміщення мети саме на метрики. Класичний приклад - людина починає їздити не велосипеді, щоб покращити свій стан, ставить одометр, щоб вимірювати подолану відстань, а потім перестає їздити коли прилад ламається. Їздити ж, наче, нема сенсу - кілометри не буде пораховано. Перша мета вже забувається. Це одне з наших когнітивних викривлень, мозок полюбляє спрощення.
@@MrYaroslavMudrij а потім приймаються якісь рішення які ніхто не розуміє, тому що збирали метрику про яку ніхто не знав. Та ще й дані для метрики збирались некоректно і тд. до того ж, процеси часто можуть змінюватись і метрика стає не актуальною, якщо за цим не слідкують (а часто так і є) то знову таки маємо не коректні дані. Йди потім пояснюй чому графік показує не те що він показує.
у мене на технічному було питання, через яке я не пройшла на позицію Qa engineer, мені написали у фідбек, що не змогла до кінця пояснити як вирішити проблему "qa bottlenecking" в моделі скрам. Шановні QA експерти, як би ви відповіли на це питання.
це питання таке "qa bottlenecking в моделі скрам?" порада на всі випадки життя - не розумієте питання, не соромтесь перепитати, уточнити чи попросити навести приклад. Бо інтерпретацій може бути багато, і ви все одно відповісте неправильно. Ось наприклад: ✅ це питання - пастка, бо в скрамі нема ролі QA. А нема QA - нема проблеми ботлнеку ✅ це питання - не пастка. Тоді треба визначити причини ботлнека: ➡ неправильна оцінка ➡ неправильне планування ➡ мало тестерів ➡ запізнення строків розробки ➡ неправильні вхідні умови тестування ➡ неправильні вихідні умови тестуванн ➡ неправильні очікування від тестування ...
@@ypurek дякую за відповідь ❤️. Так, я говорила, що відповідальність за якість продукту лежить на всіх членах команди, що краще попередити баг ніж фіксити, що потрібно починати тестування від специфікаціі вимог, проводити планування, коректну естимацію для задач тестування, робити приоритизацію тестів, розробляти тестові дані, брати до уваги піраміду тестування (повна автоматизація юніт тестів розробниками і потім рухаємося через інтегральні догори до системних і приймальних автоматизованих і UI е2е мануальних яких менше всього мусить бути порівняно з іншими типами тестів). Але все рівно цього було недостатньо, коли я попросила пояснити, як вони бачать вирішення цієї проблеми (qa bottlenecking), то вони просто перейшли до наступного питання. Тому мене це і турбує. До речі, це була компанія The Workshop.
Швидше за все мається на увазі що тікети надходить пачкою в кінці спринта, що викликає ботелнек для тестування. Вирішенням цієї проблеми є тестування завдань по мірі готовності. Для цього потрібно рухатися в сторону CI/CD та створити можливість деплоїти завдання на індивідуальні тестові прев'ю середовища.
Як людина не з ІТ , для мене дуже дивно чути що хтось не хоче проходити тестове завдання на рівні джун - мідл-. Інша справа що завдання повинно бути таке яке відкриває всі необхідні знання для даної компанії та до прикладуть 1день в офісі компанії на виконання цього завдання. Для мідл+, сіньйор це вже дивно томущо інтервюєр спеціаліст і без тестового зрозуміє рівень кандидата
але це ж не правда, що в американських компаніях нема QA. По-перше, я знаю компанії, де є. По-друге, можна відкрити LinkedIn чи Glassdoor і подивитись - вакансії теж є По-третє, якщо команда розробки не має QA в штаті, то тестування віддали на аутсорс
Думаю, вона часто говорить з точки зору людини з особистим і конкретним досвідом. Мені навпаки дуже багато її слів і моїх сумнівів про деякі речі відгукнулося. Наприклад про тест результати та метрики. Якщо є людина, яка в контексті, і яка може регулювати та перевіряти адекватність тої статистики, що команда подає, то тільки тоді це має місце. Інакше, цифра у 900 пройдених успішно автотестів це просто цифра, особливо коли вона не покриває смоук тест, або покриває його не повністю. Зате 900 тестів.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
А які тестові завдання виконували ви під час пошуку роботи?
Поки ніяких, я тільки на процесі (навчання) проходження марафону і після нього буде курс
Дякую за подкаст! Дуже весело було чути думки на рахунок тестового завдання, одразу відмітив, що, мабуть, спікери давно інтервю не проходили)
В Німеччині активно шукаю роботу вже, десь більше півроку. Тестові дають КОЖНИЙ раз! Це на позицію сіньор та після проходження технічної співбесіди. Маю досвід 11+ років QA , 8 з яких Automation ( Java, Kotlin, Python Typescript, Swift ), остання позиція QA Lead. Завдання рідко бували не менш ніж на тиждень.
Нещодавно й на проді давали селеніум автотести написати)
Нещодавно співбесідувався в українські компанії - така шара порівняно з Німеччиною! Дуже приємно, коли вірять на слово. Але, нажаль, й проекти не такі цікаві та й дуже позицій мало стало(((
1:00:19 Якби мене судили за пропущені баги, в адвокати я б собі покликав Олексія 💪 На таких людях тримається наша професія 💫
Доброго вечора, а де знайти блог QAmania?
супер
вкотре вдячний що знаходите час
завжди цікаво слухати
Дуже цікаво, дякую! Ви пригадали про те, що тест менеджер створює процес. А можете поділитися посиланням, де ви це обговорюєте, будь ласка?
Посилання ютуб не пропустить, але можете подивитись наступні випуски:
✅ Питання якості #12. Частина про продуктовий/аутсорсний майндсет
✅ Питання якості #11. Частина про Хто відповідає за якість ПЗ
✅ Питання якості #10. Про стартапи
дякую за випуск 🇺🇦
Якщо метрики не ефективні, як вимірювати перформенс команди, яку можна використовувати на перформенс ревю і для підвищення зарплатні.
Випускникам курсів додатково пропонують послугу вирішення/перевірки тестових завдань. Саме тому реально не бачу сенсу в тому, коли тестове просто надсилають і хтозна - будуть перевіряти, чи ні, може поки ти його робиш - взагалі закриють вакансію. Декілька разів я особисто стикнулась із тим, що жодного фідбеку після тестового взагалі не було, наче в пустоту відправила)
Та вважаю, що тестове має бути обов*язково саме частиною технічної співбесіди. Не варто довго розповідати теорію (тимпаче все легко загуглити в ході інтерв*ю) - варто просто лише на прикладі озвучити хід думок для вирішення того чи іншого практичного питання.
Одразу буде видно, чи взагалі людина щось розуміє і знає. А якщо не знає - як буде здобувати інформацію.
ого. і таке є? О___о
От такий підхід до співбесід/тестових, як на мене - 🔥🔥🔥
😂😂🎉🎉ЗАЛИШАЙТЕ НЕГАТИВНІ КОМЕНТИ ПРО КОМПАНІЮ НА ДОУ!!!!!! І всі мудаки одразу почнуть попускатися! І не бійтеся що про вас подумають плохо і мабуть десь вас ще не візьмуть за це.
З Повагою до початківців, власник ІТ компанії ;)
ПС. Якщо знаєте англійську то в загалі можете подаватися одразу за межи України. Але це зараз я вже накличу на себе плач інших менеджерів і власників 😂😂😂😂 Але тут богато плюсів теж..
@@carloniaso Ваша правда про відгуки. Я не соромилась в тактичному описанні плюсів і мінусів) Та помітила сумну тенденцію, що негативні відгуки не наважуються написати відсотків 90 з тих, хто не задоволений чимось (факт того, що треба висвітити свою особу мабуть тут грає не на користь). І потім маємо: компанія майже шахрай, а відгуки класні...
Сподіватимемось, коли вирівняється ситуація на ринку на користь працівника, а не роботодавця - все прийде в норму
@@oltrastar Приведу приклад,
Я даю задачі людині яка відповідає за цей напрямок давати обов’язково фідбек, так як це теж лице компанії, але людина по різним причинам цього не робить. Я фізично відстежити в загальному це не встигаю і не можу. Але всі коменти о компанії контролюю і потім роблю розбір ситуацій.
Тобто в загальному коменти о компанії грають велику роль і за них майже всі трясуться !!!
Як свічер, попервах дивувалась, чого такий холівар в ІТ щодо тестових. В багатьох галузях взагалі є пробні 2-3 дні - НЕОПЛОЧУВАНІ - подивитись чи орієнтується і чи потягне людина. І, як вірно Ольга озвучила, коли треба шось їсти, то і тестове зробиш ))) Доводилось робити тестові при пошуку першої роботи. Але символічного характеру: якась бажна веб-сторінка (видно що спецом для тестів і зроблена), якийсь калькулятор. Пару годин на виконання і корона не впала. А якщо вже попадається комусь неадекватне тестове - це червоний прапорець на адресу контори.
Зараз в пошуках мідл позиції, і можу відзначити, що на мідлів вакансій з тестовими не бачила (можливо тому, що шукаю мануал, можливо автомейшенам щось таке й пропонують). І після ваших жахастиків про "зашорених девелоперів, що живуть у своїй мушельці" стає трохи стрьомно 😅 Бо своїх колег по минулих проектах можу тільки хвалити і ставити за приклад і в професійності, і по софтскілах.
Я не зовсім розумію концепцію прихованих метрик. Якщо у компанії є цінність, яка відображається певною метрикою, то чому б не сказати про неї працівникам, щоб вони могли докладати зусилля саме в напрямку примноження цієї цінності? А якщо залишається місце для зловживань, то, на мою думку, це погана метрика, вигадана для галочки, за нею реальної цінності для компанії не стоїть і на неї витрачати ресурс недоцільно.
Складне питання. Будь-яка метрика недосконала, це лише відмітка, а цінності більші. І є ризик зміщення мети саме на метрики. Класичний приклад - людина починає їздити не велосипеді, щоб покращити свій стан, ставить одометр, щоб вимірювати подолану відстань, а потім перестає їздити коли прилад ламається. Їздити ж, наче, нема сенсу - кілометри не буде пораховано. Перша мета вже забувається. Це одне з наших когнітивних викривлень, мозок полюбляє спрощення.
@@MrYaroslavMudrij а потім приймаються якісь рішення які ніхто не розуміє, тому що збирали метрику про яку ніхто не знав. Та ще й дані для метрики збирались некоректно і тд. до того ж, процеси часто можуть змінюватись і метрика стає не актуальною, якщо за цим не слідкують (а часто так і є) то знову таки маємо не коректні дані. Йди потім пояснюй чому графік показує не те що він показує.
у мене на технічному було питання, через яке я не пройшла на позицію Qa engineer, мені написали у фідбек, що не змогла до кінця пояснити як вирішити проблему "qa bottlenecking" в моделі скрам. Шановні QA експерти, як би ви відповіли на це питання.
це питання таке "qa bottlenecking в моделі скрам?"
порада на всі випадки життя - не розумієте питання, не соромтесь перепитати, уточнити чи попросити навести приклад. Бо інтерпретацій може бути багато, і ви все одно відповісте неправильно. Ось наприклад:
✅ це питання - пастка, бо в скрамі нема ролі QA. А нема QA - нема проблеми ботлнеку
✅ це питання - не пастка. Тоді треба визначити причини ботлнека:
➡ неправильна оцінка
➡ неправильне планування
➡ мало тестерів
➡ запізнення строків розробки
➡ неправильні вхідні умови тестування
➡ неправильні вихідні умови тестуванн
➡ неправильні очікування від тестування
...
@@ypurek дякую за відповідь ❤️. Так, я говорила, що відповідальність за якість продукту лежить на всіх членах команди, що краще попередити баг ніж фіксити, що потрібно починати тестування від специфікаціі вимог, проводити планування, коректну естимацію для задач тестування, робити приоритизацію тестів, розробляти тестові дані, брати до уваги піраміду тестування (повна автоматизація юніт тестів розробниками і потім рухаємося через інтегральні догори до системних і приймальних автоматизованих і UI е2е мануальних яких менше всього мусить бути порівняно з іншими типами тестів). Але все рівно цього було недостатньо, коли я попросила пояснити, як вони бачать вирішення цієї проблеми (qa bottlenecking), то вони просто перейшли до наступного питання. Тому мене це і турбує. До речі, це була компанія The Workshop.
Швидше за все мається на увазі що тікети надходить пачкою в кінці спринта, що викликає ботелнек для тестування.
Вирішенням цієї проблеми є тестування завдань по мірі готовності. Для цього потрібно рухатися в сторону CI/CD та створити можливість деплоїти завдання на індивідуальні тестові прев'ю середовища.
@@ShedewrS дякую!
стоп стоп стоп, куди це ви? відкриваємо новий сезон зараз
літо, треба трохи відпочити
як раз літо і закінчилось)@@ypurek
@@OlehHlushko так отож - літо закінчилось, а ми так і не відпочили
Робив тестове
У любому випадку, тестер проганяє поведінку юзерів при використанні ПЗ
Дякую за цей подкаст, тільки вчусь QA дуже корисна дискусія з нетерпінням чекаю нові)
Як людина не з ІТ , для мене дуже дивно чути що хтось не хоче проходити тестове завдання на рівні джун - мідл-. Інша справа що завдання повинно бути таке яке відкриває всі необхідні знання для даної компанії та до прикладуть 1день в офісі компанії на виконання цього завдання. Для мідл+, сіньйор це вже дивно томущо інтервюєр спеціаліст і без тестового зрозуміє рівень кандидата
В тому і справа, що тестове завдання для QA навряд чи розкриє кандидата. Тестові завдання доречні для QA automation.
Поулібался минут 4)))))
Вже 10 років знаю адептів "мануал QA не потрібні" Це адепти американського підходу , що немає QA на проектах.
але це ж не правда, що в американських компаніях нема QA.
По-перше, я знаю компанії, де є.
По-друге, можна відкрити LinkedIn чи Glassdoor і подивитись - вакансії теж є
По-третє, якщо команда розробки не має QA в штаті, то тестування віддали на аутсорс
Баба противна, підкаст вода....
баба має дуже велику корону на башці.
та баба харить чсв
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ті шо шо рассказівают, а чтож тогда на дове столько вакансий если не нада
Ну та баба противна
Пані Оля, мабуть, з суворого ентерпрайзу)) Але погоджуюсь з кожним словом. )👍👍👍👍
такой подзаплет если честно))
ця малініна дуже зарозуміла. про мужчин таке враження не складається.
Думаю, вона часто говорить з точки зору людини з особистим і конкретним досвідом. Мені навпаки дуже багато її слів і моїх сумнівів про деякі речі відгукнулося. Наприклад про тест результати та метрики. Якщо є людина, яка в контексті, і яка може регулювати та перевіряти адекватність тої статистики, що команда подає, то тільки тоді це має місце. Інакше, цифра у 900 пройдених успішно автотестів це просто цифра, особливо коли вона не покриває смоук тест, або покриває його не повністю. Зате 900 тестів.