За факапы отвечают вся команда.

Давайте представим, что у вас есть датацентр, который моргнул и клиенты оказались без связи на полчаса ю
Очевидно, что исходя из того что куашник отвечает за факапы, он должен отвечать за то что хреновое железо, за то что перебьои со связью, за то что в момент моргания был релиз и система не смогла подняться за адекватное время, за то, что в этой же момент времени шла рассылка по итогам олимпиады на весь мир и она немношк нагнула базу, и за то что от сервиса отказались клиенты, потому что у них тяжелые внутренние переговоры, они еле еле затащили к себе пушвуш и попали на поломку и люли от своих менеджеров которые "ЖЕ ГОВОРИЛИ ЧТО НАМ ЛУЧШЕ ПИСАТЬ СВОЙ СЕРВИС"

Возвращшаясь к стоимости куашников, спец, который может отвечать за это все, стоит очень очень дорого))и скорее всего не существует

Ну я так утрированно конечно)))но суть в общем что все совсем не однозначно

Как вы оцениваете, насколько команда справляется с QA? Кто отвечает за факапы?)

Оценка работы – не обязательно метрики

Я сам не знаю никаких хороших KPI ни для кого, кроме продажников

А девелоперские нормальные метрики знаешь?

Неа

Давайте расширим вопрос: а такие хорошие метрики существуют?

Нет, давайте так: как Саша Прихожденко понимает, что метрика "хорошая"?

кажется, что в чате мы не найдем ответ:) вживую поговорим)

тем не менее, вопрос о том, как оценивать качество работы куа все ещё остается :)
есть работающие практики помимо заднеполусферных ощущений?

К чему эти крайности: за всё отвечает один QAшник и за всё отвечает "команда"?)

Я вот QA-шника не стал бы ругать за какие-то там моргания датацентра

Просто когда отвечает "команда", где та точка входа, с которой начинается анализ проишествия?

А у вас анализ начинается с куа?

С классической композицией команды мне всё понятно:

Пришел к QA, спросил, "это подлежит тестированию? это тестировали? это прошло тест?"
Если там всё ок, идёшь к тимлиду, там "задачу можно было выкатывать в релиз? был техдолг про это?"

И так далее, пока не разберёшься, где провал, и можно ли было его избежать

Да

Они последние в цепочке поставки, от них в обратную сторону иду до аналитиков

Мне кажется логичным сразу идти в разработку чтобы и ответы получить и фикс)

какие выводы делаются или решения принимаются по итогу такого анализа?

Если это просто не тестировалось, то разработка не ответит. А в тестировании еще очень часто какие-то доп. сведения добываются при вопросах

Как это разработка не ответит за багу в своём коде? 🤔

С кем-то одним говорить опасно, мало кто с себя не спихивает ответственность)

Это если проблема в баге, а не, например, что ПМ забил на неё болт и поднял приоритет у косметики