Привіт друзі! в коментарях до останнього випуску подкасту “питання якості” написали, що не пройшли технічне інтерв’ю, бо не дали відповідь на запитання “як вирішити проблему qa bottlenecking в моделі скрам?”
Навіть мене подібне питання викликає ступор, бо не дуже зрозуміло, що хоче почути інтерв’ювер.
Тож даю пораду на всі випадки життя – не розумієте питання, не соромтесь перепитати, уточнити чи попросити навести приклад. Бо інтерпретацій може бути багато, і ви все одно відповісте неправильно. Ось наприклад:
✅ це питання – пастка, бо в скрамі нема ролі QA. А нема QA – нема проблеми ботлнеку 😁
✅ це питання – можлива пастка, залежить від того, кого питають. Junior, Middle і навіть не кожен Senior інженер мають вирішувати проблему ботлнеку. Ідентифікувати – так. Повідомити про це – так. Вирішувати – це менеджерська робота.
✅ це питання – не пастка. Тоді треба визначити причини ботлнека, щоб зрозуміти, чи точно QA – ботлнек:
➡️ неправильна оцінка задач, що беруться в спринт
➡️ неправильне планування. Якщо видати фічі в тестування в останній день спринта, то проблема в процесі, а не в QA
➡️ мало тестерів. Може QA фізично не встигають все перевіряти
➡️ неправильні entry criteria тестування. Беремо в тестування сирі фічі чи фічі, до яких ми ще не підготували тести. Тут вже QA можуть переглянути підхід і поставити інші умови
➡️ неправильні exit criteria тестування. Про це ми теж в одному з випусків подкасту говорили. Коли треба провести умовний смоук за 2 години, QA посинає робити 2-тижневе регресійне тестування, і звісно ж, не встигає. Треба обирати оптимальне для команди тестування і попереджати про строки заздалегідь
➡️ неправильні очікування від тестування. Тестування не ламає ПЗ. Тестування не фіксить баги і не покращує якість. Тестування – вимірює поточну якість продукту. Якщо в результаті тестування заведено 10 блокерів і 30 крітікал багів, це не QA блокує реліз, це якість процесу розробки треба покращувати
А як би ви відповіли на таке питання на співбесіді?