Управление качеством
Инструментарий QA-лида — плотность дефектов и другие метрики, пропущенные в прод дефекты, триаж багов, отчёты о тестировании, quality gate в CI/CD, MTTD и MTTR, анализ первопричин, приоритизация по рискам и решение о выпуске релиза.
12 вопросов
JuniorТеорияОчень частоЧем различаются метрики реагирования на инциденты MTTD и MTTR и что измеряет каждая?
Чем различаются метрики реагирования на инциденты MTTD и MTTR и что измеряет каждая?
MTTD, mean time to detect, — среднее от появления дефекта или инцидента до момента, когда его заметили. MTTR, mean time to restore, — от обнаружения до восстановления работы сервиса. MTTD оценивает мониторинг и тестирование, MTTR — реакцию. Разные меры двигают их, поэтому отслеживают раздельно.
Типичные ошибки
- ✗Сливать MTTD и MTTR в одно число «время инцидента»
- ✗Считать, что более быстрая выкатка сокращает время обнаружения
- ✗Читать MTTR как время поиска первопричины, а не восстановления сервиса
Уточняющие вопросы
- →За какую из двух возьмётесь первой в системе со слабым мониторингом?
- →Как MTTR может выглядеть отличным, пока пользователи сидят в долгом простое?
JuniorТеорияЧастоЧто такое defect density, как её вычислить и о чём говорит полученное число?
Что такое defect density, как её вычислить и о чём говорит полученное число?
Defect density — подтверждённые дефекты на размер компонента, обычно на KLOC (тысячу строк) или функциональную точку. Метрика сравнительная: ранжирует модули или релизы, показывая, где скапливаются дефекты. Высокое значение ничего не доказывает — это и хрупкий код, и глубже тестирование.
Типичные ошибки
- ✗Читать высокую плотность как доказательство плохого кода, а не тщательного тестирования
- ✗Сравнивать плотность у продуктов, где размер измеряется в разных единицах
- ✗Считать плотность абсолютным приговором качеству, а не сравнительным сигналом
Уточняющие вопросы
- →Почему модуль с нулём заведённых дефектов может быть самым рискованным в релизе?
- →Какую единицу размера взять, если строки кода несравнимы между модулями?
MiddleТеорияЧастоЧто происходит на bug triage и когда закрыть дефект как «won't fix» — правильное решение?
Что происходит на bug triage и когда закрыть дефект как «won't fix» — правильное решение?
Triage — встреча, где лид, владелец продукта и разработчик дают дефектам severity, priority и владельца — что чинить сейчас, что подождёт, а что отклонить. «Won't fix» уместен, когда цена или риск фикса перевешивают пользу: косметика, корректное поведение, дубликат или снимаемая фича. Это записанное решение, а не способ спрятать баги.
Типичные ошибки
- ✗Отклонять баг как «won't fix» лишь потому, что спринт заполнен
- ✗Решать по одной трудоёмкости фикса, игнорируя ценность дефекта для пользователей
- ✗Считать триаж делом одного тестировщика, а не решением нескольких ролей
Уточняющие вопросы
- →За кем финальное слово, когда QA и владелец продукта расходятся на триаже?
- →Как не дать бэклогу «won't fix» тихо накапливать реальный риск?
MiddleТеорияЧастоЧто такое утечка дефектов между фазами и чем defect-detection % отличается от pass rate?
Что такое утечка дефектов между фазами и чем defect-detection % отличается от pass rate?
Утечка дефектов — дефект, проскользнувший из фазы, что должна была его поймать, в более позднюю; в худшем случае в прод. Defect-detection percentage — ваш «улов»: в фазе ÷ (в фазе + утёкшие). Pass rate — лишь доля прошедших кейсов, другая ось. Pass rate 99% при большой утечке горит зелёным, пропуская реальные дефекты.
Типичные ошибки
- ✗Считать высокий pass rate доказательством, что мало дефектов сбежало
- ✗Считать пойманный разработчиком баг утечкой, а не ранним уловом
- ✗Путать сбежавшие в прод дефекты с дефектами, просто ещё открытыми
Уточняющие вопросы
- →Обе команды дают pass rate 98% — как понять, чьи тесты лучше?
- →Почему дефект, пойманный в своей фазе, стоит куда меньше сбежавшего?
MiddleДизайнЧастоВы ведёте встречу go/no-go по завтрашнему релизу. За столом владелец продукта, разработчик и релиз-менеджер, и все ждут вашей рекомендации. Сборка прошла большую часть тестирования, но несколько дефектов ещё открыты, а один крупный модуль в этом цикле отрефакторили. Разберите, как вы приходите к обоснованному вердикту go или no-go. Охватите, какие exit criteria проверяете, как оцениваете регрессионный риск отрефторенной области, как отличаете известную проблему, с которой можно выпускать — с задокументированным обходным путём, — от блокирующего дефекта, который обязан остановить релиз, и как ведёте короткий risk register принятых рисков с владельцем и мерой снижения для каждого, чтобы выпуск с открытыми дефектами был осознанным записанным решением, а не случайностью.
Вы ведёте встречу go/no-go по завтрашнему релизу. За столом владелец продукта, разработчик и релиз-менеджер, и все ждут вашей рекомендации. Сборка прошла большую часть тестирования, но несколько дефектов ещё открыты, а один крупный модуль в этом цикле отрефакторили. Разберите, как вы приходите к обоснованному вердикту go или no-go. Охватите, какие exit criteria проверяете, как оцениваете регрессионный риск отрефторенной области, как отличаете известную проблему, с которой можно выпускать — с задокументированным обходным путём, — от блокирующего дефекта, который обязан остановить релиз, и как ведёте короткий risk register принятых рисков с владельцем и мерой снижения для каждого, чтобы выпуск с открытыми дефектами был осознанным записанным решением, а не случайностью.
Начните с exit criteria: покрытие критичных путей, нет блокеров. Смещайте регрессионный риск к отрефакторенному модулю — он менялся, вероятнее сломается. Проблему с обходом и малым влиянием выпускать можно; блокер — потеря данных, сломанный путь, без обхода — жёсткое no-go. Заносите каждый риск с владельцем, чтобы вердикт был обоснованным.
Типичные ошибки
- ✗Считать каждый открытый дефект блокером либо каждый — выпускаемым
- ✗Не смещать регрессионный риск к коду, который реально менялся
- ✗Выпускать с открытыми дефектами, но не вести register принятых рисков
Уточняющие вопросы
- →Какой один открытый дефект перевернёт ваш go в no-go и почему?
- →Кто владеет принятым риском после выпуска и на что он берёт обязательство?
MiddleДизайнЧастоДефект, добравшийся до прода, только что починили, и вы ведёте по нему ретроспективу. Инстинкт команды — похвалить разработчика за быстрый патч и двигаться дальше. Вы же хотите предотвратить весь класс дефектов. Разберите, как вы проведёте анализ первопричин: как отделяете симптом от глубинной причины, как приём вроде «5 почему» ведёт от видимого сбоя к системной причине, как классификация дефекта по типу помогает увидеть, разовый это случай или паттерн среди недавних утечек, и как ретроспектива превращает вывод в конкретное предупреждающее действие, а не в записку, которую никто не читает. Объясните, что делает результат устойчивым, а не повтором через месяц.
Дефект, добравшийся до прода, только что починили, и вы ведёте по нему ретроспективу. Инстинкт команды — похвалить разработчика за быстрый патч и двигаться дальше. Вы же хотите предотвратить весь класс дефектов. Разберите, как вы проведёте анализ первопричин: как отделяете симптом от глубинной причины, как приём вроде «5 почему» ведёт от видимого сбоя к системной причине, как классификация дефекта по типу помогает увидеть, разовый это случай или паттерн среди недавних утечек, и как ретроспектива превращает вывод в конкретное предупреждающее действие, а не в записку, которую никто не читает. Объясните, что делает результат устойчивым, а не повтором через месяц.
Отделите симптом, что увидел пользователь, от первопричины. Копайте «5 почему» до системной причины — пропущенного теста, пробела в ревью, — а не багованной строки. Классифицируйте дефект и сравните недавние утечки, чтобы отличить разовое от паттерна. Выход ретро — конкретное предупреждающее действие с владельцем, останавливающее класс.
Типичные ошибки
- ✗Останавливаться на багованной строке, а не на системной причине, почему она выжила
- ✗Превращать «5 почему» в поиск человека, на которого свалить вину
- ✗Заканчивать ретро запиской без конкретного предупреждающего действия с владельцем
Уточняющие вопросы
- →Как не дать «5 почему» остановиться на удобном, но поверхностном ответе?
- →Что подскажет, что утечка — паттерн, а не изолированный промах?
MiddleДизайнИногдаКоманда хочет добавить автоматический quality gate в CI/CD-пайплайн, чтобы сборка не продвигалась в staging, пока не пройдёт объективную планку качества, вместо того чтобы кто-то глазами смотрел на результаты. Спроектируйте этот gate. Решите, какие условия он проверяет — пороги прохождения тестов, покрытие кода, находки статического анализа, отсутствие новых дефектов высокого severity — и, что важно, где вы проводите каждую границу, чтобы gate блокировал реально рискованные сборки, но не падал на шуме. Объясните, как не дать ему стать ни формальной печатью, которую все игнорируют, ни флаки-блокером, который команды учатся обходить, и как метрики вроде тренда утёкших дефектов и времени обнаружения покажут за следующие месяцы, реально ли gate улучшает качество.
Команда хочет добавить автоматический quality gate в CI/CD-пайплайн, чтобы сборка не продвигалась в staging, пока не пройдёт объективную планку качества, вместо того чтобы кто-то глазами смотрел на результаты. Спроектируйте этот gate. Решите, какие условия он проверяет — пороги прохождения тестов, покрытие кода, находки статического анализа, отсутствие новых дефектов высокого severity — и, что важно, где вы проводите каждую границу, чтобы gate блокировал реально рискованные сборки, но не падал на шуме. Объясните, как не дать ему стать ни формальной печатью, которую все игнорируют, ни флаки-блокером, который команды учатся обходить, и как метрики вроде тренда утёкших дефектов и времени обнаружения покажут за следующие месяцы, реально ли gate улучшает качество.
Определите gate как объективные pass/fail на каждой сборке: порог прохождения, растущее покрытие, нет новых дефектов высокого severity, лимиты статанализа. Проводите границы без шума — карантин флаки-тестам, новые находки, а не легаси. Реагируйте на падения и следите за трендом утёкших дефектов и временем обнаружения.
Типичные ошибки
- ✗Ставить абсолютные пороги (100% прохождения, 100% покрытия), падающие на шуме
- ✗Проверять весь легаси-бэклог дефектов вместо только новых находок
- ✗Никогда не мерить, реально ли gate снижает утёкшие дефекты со временем
Уточняющие вопросы
- →Как не дать флаки-тестам сделать gate недоверенным?
- →Какой тренд докажет, что gate помогает, а не просто тормозит мержи?
MiddleДизайнИногдаОкно регресса для релиза только что урезали с трёх дней до одного, а полный набор прогоняется три дня. Дата не сдвинется, релиз затрагивает флоу оформления заказа плюс горсть несвязанных багфиксов. Всё прогнать нельзя. Разберите, как вы решаете на основе рисков, какие тесты прогнать первыми, а какие отложить. Объясните, как ранжируете области по риску, какие сигналы — объём изменений, влияние на бизнес, история дефектов — питают это ранжирование, как используете метрики дефектов прошлых релизов, чтобы найти хрупкие модули, и как доносите остаточный риск того, что решили не прогонять, чтобы решение go/no-go принималось с открытыми глазами.
Окно регресса для релиза только что урезали с трёх дней до одного, а полный набор прогоняется три дня. Дата не сдвинется, релиз затрагивает флоу оформления заказа плюс горсть несвязанных багфиксов. Всё прогнать нельзя. Разберите, как вы решаете на основе рисков, какие тесты прогнать первыми, а какие отложить. Объясните, как ранжируете области по риску, какие сигналы — объём изменений, влияние на бизнес, история дефектов — питают это ранжирование, как используете метрики дефектов прошлых релизов, чтобы найти хрупкие модули, и как доносите остаточный риск того, что решили не прогонять, чтобы решение go/no-go принималось с открытыми глазами.
Ранжируйте области по риску = вероятность × влияние. Влияние выше на критичных путях вроде заказа; вероятность выше там, где код менялся и где метрики дефектов помечают хрупкие модули. Прогоняйте это пересечение первым, отложите стабильные области, затем озвучьте пропущенный остаточный риск, чтобы go/no-go был осознанным.
Типичные ошибки
- ✗Приоритизировать по скорости или числу тестов вместо риска для бизнеса
- ✗Игнорировать историю дефектов при выборе хрупких областей для покрытия
- ✗Молча выкидывать отложенные области вместо озвучивания остаточного риска
Уточняющие вопросы
- →Как учесть область, что стабильна, но критична для бизнеса, вроде логина?
- →Что делать, когда двум областям высокого риска обеим не хватает оставшегося времени?
MiddleТеорияИногдаЧто такое test summary report, что он содержит и кто его читает?
Что такое test summary report, что он содержит и кто его читает?
Test summary report закрывает цикл тестирования. Он фиксирует, что протестировано и что осталось, сколько кейсов прошло, упало и заблокировано, открытые дефекты по severity и метрики вроде defect density и pass rate — и завершается явной рекомендацией по выпуску. Он начинается с вердикта для лида и стейкхолдеров, а не с сырых логов.
Типичные ошибки
- ✗Вываливать сырые логи вместо ясной рекомендации по выпуску в начале
- ✗Опускать то, что НЕ тестировалось, скрывая от читателей остаточный риск
- ✗Писать его для тестировщиков, а не для лида и стейкхолдеров
Уточняющие вопросы
- →Почему раздел «что мы не тестировали» так же важен, как pass rate?
- →Как изменится отчёт для хотфикса против крупного релиза?
SeniorДизайнИногдаВторая половина дня перед релизом, дата которого уже объявлена клиентам, и вы только что нашли критический баг — реальный путь к повреждению данных на частом действии пользователя. Разработчики говорят, что нормальный фикс требует двух дней; спешный патч можно попробовать сегодня ночью, но он несёт свой риск. Маркетинг уже пообещал дату. Разберите, как вы действуете — не только технически, но и как человек, на котором теперь держится go/no-go. Охватите, как подтверждаете и оцениваете реальное влияние бага и как часто он срабатывает, как формулируете варианты — сдвинуть дату, выпустить с отключённой фичей, попробовать рискованный хотфикс — для принимающих решение, как сопротивляетесь давлению просто пропустить его и на чём настаиваете до любого пути «выпускать всё равно», чтобы бизнес решал с полным знанием.
Вторая половина дня перед релизом, дата которого уже объявлена клиентам, и вы только что нашли критический баг — реальный путь к повреждению данных на частом действии пользователя. Разработчики говорят, что нормальный фикс требует двух дней; спешный патч можно попробовать сегодня ночью, но он несёт свой риск. Маркетинг уже пообещал дату. Разберите, как вы действуете — не только технически, но и как человек, на котором теперь держится go/no-go. Охватите, как подтверждаете и оцениваете реальное влияние бага и как часто он срабатывает, как формулируете варианты — сдвинуть дату, выпустить с отключённой фичей, попробовать рискованный хотфикс — для принимающих решение, как сопротивляетесь давлению просто пропустить его и на чём настаиваете до любого пути «выпускать всё равно», чтобы бизнес решал с полным знанием.
Сначала подтвердите: воспроизведите и оцените влияние и частоту — повреждение данных на частом действии тяжело. Не пропускайте молча под давлением — этого нельзя. Формулируйте варианты, не решайте одни: сдвинуть дату, отключить фичу или хотфикс. Любой путь «выпускать всё равно» — задокументированное решение с владельцем и знанием риска.
Типичные ошибки
- ✗Пропускать баг с повреждением данных как известную проблему под давлением графика
- ✗Тихо применять рискованный хотфикс без эскалации и оценки влияния
- ✗Принимать решение go/no-go в одиночку вместо формулировки вариантов для бизнеса
Уточняющие вопросы
- →Как возразить, когда менеджер давит просто пропустить это?
- →Чем «выпустить с отключённой фичей» безопаснее спешного хотфикса здесь?
SeniorДизайнИногдаЗа день до релиза вам нужно отправить короткий письменный статус нетехническим стейкхолдерам — директору по продукту и двум владельцам бизнеса, которые не полезут в баг-трекер и не знают, что такое «p2 regression» или «флаки-набор». Им нужно принять бизнес-решение по вашему сообщению. Опишите, как вы напишете этот статус. Охватите, как выносите суть в начало — выпускать, придержать или выпускать с оговорками, — а не хороните её под деталями, как переводите счётчики и severity дефектов в понятное им влияние на бизнес и риск для пользователей, как делаете остаточный риск и любые допущения явными и честными без технического жаргона, и как держите текст достаточно коротким, чтобы занятой руководитель его реально прочитал и смог действовать.
За день до релиза вам нужно отправить короткий письменный статус нетехническим стейкхолдерам — директору по продукту и двум владельцам бизнеса, которые не полезут в баг-трекер и не знают, что такое «p2 regression» или «флаки-набор». Им нужно принять бизнес-решение по вашему сообщению. Опишите, как вы напишете этот статус. Охватите, как выносите суть в начало — выпускать, придержать или выпускать с оговорками, — а не хороните её под деталями, как переводите счётчики и severity дефектов в понятное им влияние на бизнес и риск для пользователей, как делаете остаточный риск и любые допущения явными и честными без технического жаргона, и как держите текст достаточно коротким, чтобы занятой руководитель его реально прочитал и смог действовать.
Вынесите суть в первую строку — выпускать, придержать или с оговорками, — чтобы читатель получил решение сразу, до деталей. Переведите дефекты на язык бизнеса: не «три бага p2», а «заказ работает, но промокоды падают у ~5% пользователей, есть обход». Уберите жаргон, изложите остаточный риск и допущения честно и завершите одним нужным решением.
Типичные ошибки
- ✗Хоронить решение выпускать/придержать в конце вместо вынесения в начало
- ✗Оставлять счётчики и severity дефектов непереведёнными в влияние на бизнес
- ✗Прятать остаточный риск ради успокоения или опускать сам запрос решения
Уточняющие вопросы
- →Как честно донести плохую новость, не вызвав паники или поиска виноватых?
- →Что вы вырежете первым, если статус должен уместиться в три предложения?
SeniorДизайнИногдаРуководство просит вас доказать, что команда QA реально стоит своих денег, и предостерегает от тщеславных цифр вроде «написано тест-кейсов» или «выполнено тестов», которые меряют активность, а не ценность. Спроектируйте способ измерить, насколько эффективно ваше тестирование на самом деле. Объясните, какие сигналы действительно отражают эффективность — сколько дефектов тестирование ловит до релиза против того, сколько утекает к пользователям, насколько глубоко оно прорабатывает реальный риск, а не просто строки кода, и во что эти числа обходятся по времени. Охватите, почему надо читать тренды за несколько релизов, а не одну абсолютную цифру, как защититься от метрики, которую можно накрутить, и как подать результат, чтобы он вёл к улучшению, а не к поиску виноватых.
Руководство просит вас доказать, что команда QA реально стоит своих денег, и предостерегает от тщеславных цифр вроде «написано тест-кейсов» или «выполнено тестов», которые меряют активность, а не ценность. Спроектируйте способ измерить, насколько эффективно ваше тестирование на самом деле. Объясните, какие сигналы действительно отражают эффективность — сколько дефектов тестирование ловит до релиза против того, сколько утекает к пользователям, насколько глубоко оно прорабатывает реальный риск, а не просто строки кода, и во что эти числа обходятся по времени. Охватите, почему надо читать тренды за несколько релизов, а не одну абсолютную цифру, как защититься от метрики, которую можно накрутить, и как подать результат, чтобы он вёл к улучшению, а не к поиску виноватых.
Единого числа нет. Читайте эффективность как дефекты, пойманные до релиза, против сбежавших к пользователям (defect detection percentage), плюс насколько тесты бьют по риску, а не только покрытие. Следите за трендами, защищайтесь от накрутки: счётчики раздуваются, не ловя больше. Подавайте ради предотвращения, не вины.
Типичные ошибки
- ✗Приравнивать счётчики активности (число кейсов, прогонов) к эффективности
- ✗Читать одну абсолютную цифру вместо тренда за несколько релизов
- ✗Подавать метрики эффективности так, что они ранжируют или винят людей
Уточняющие вопросы
- →Как заметить, что команда накручивает выбранную вами метрику?
- →Почему доля сбежавших дефектов честнее любого внутреннего pass rate?
