Чому в команді 5 QA, а якість все одно тримається на одному Senior?

За роки роботи з різними командами я бачив цю ситуацію десятки разів.
У компанії вже є QA
є Jira
є тест-кейси
є баг-трекінг
є навіть Test Lead
Але якщо завтра найсильніший QA піде у відпустку – процес фактично зупиниться.

Чому?
Тому що команда не має керованого процесу тестування.
Наприклад, приходить нова фіча.
Менеджер каже:
– Нам треба протестувати до п'ятниці.
QA починають ставити питання:
– А що саме тестувати?
– Які ризики?
– Які частини системи зачіпає?
– Що вже перевіряли?
– Який regression scope?
– Що критично для бізнесу?
– Хто приймає рішення, що реліз можна випускати?
І замість тестування команда витрачає час на з'ясування того, як взагалі організувати тестування.

Я часто бачу ще одну проблему.
Команда намагається вирішити процес за допомогою інструменту:
«Давайте поставимо Xray»
«Давайте перейдемо на TestRail»
«Давайте спробуємо Testomatio».
Але якщо немає Test Strategy, планування, правил роботи, відповідальності, критеріїв входу/виходу і зрозумілого тест менеджменту – новий інструмент просто допоможе швидше створювати безлад.

Що я зазвичай роблю під час аудиту QA-процесу?
Я дивлюся не тільки на тестувальників
Я розкладаю весь процес:
Business → Requirements → Development → QA → Release → Production
І шукаю, де саме виникають втрати.

Наприклад:
– вимоги приходять до QA вже після початку розробки
– QA не залучені до аналізу ризиків
– немає зрозумілого regression scope
– кожен QA тестує «по-своєму»
– тестова документація існує, але ніхто не знає, навіщо вона
– баги закриваються, але root cause ніхто не аналізує
– менеджмент бачить кількість багів, але не бачить реальний стан якості
– відповідальність за quality фактично лежить тільки на QA

І ось тут починається справжній Test Management.
Не з тест-кейсів
А з питання:
«Як зробити так, щоб команда могла стабільно забезпечувати потрібний рівень якості?»

У хорошому процесі QA не повинні бути «фінальним фільтром перед продом».
QA повинні допомагати команді керувати ризиками ще до того, як код написаний.
І це одна з найбільших змін, які я бачу, коли команда переходить від «ми тестуємо» до «ми керуємо якістю».
Бо зрілий QA-процес – це не більше тест-кейсів.
Це менше невизначеності, менше втрат і більш передбачувані релізи.
Саме тому під час роботи з командами я завжди починаю не з питання:
«Який у вас Test Management tool?»
А з питання:
«Як у вас зараз приймається рішення, що продукт достатньо якісний для релізу?»

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