Процессы качества

В сервисе появился фрагмент, который должен пройти CI. Какой процессный контроль качества должен автоматически обнаружить потенциальную инъекцию до интеграционных тестов?

def find_user(user_id):
    sql = "SELECT * FROM users WHERE id = " + user_id
    return db.execute(sql)

Тестовый пайплайн стабильно зелёный, но изменения долго ждут выпуска. Какой показатель покажет скорость прохождения изменения от коммита до production?

Команда сравнивает среднее время восстановления сервисов, учитывая только инциденты, зафиксированные мониторингом. Какое искажение возникает в такой метрике?

Команда выявляет дефекты только на редких сочетаниях данных, отсутствующих в регрессионном наборе. Какой механизм управления тестовыми данными закроет этот пробел?

В бэклоге смешаны критические и косметические дефекты. Как процесс дефектного триажа должен влиять на решение о выпуске?

Объясните механизм трассировки требований, который связывает бизнес-риски, проверки и дефекты в единую цепочку.

Автоматизированный регресс перестал находить ошибки в новых пользовательских сценариях. Какую роль в стратегии качества должно вернуть исследовательское тестирование?

Отчёт показывает, что среднее время исправления дефектов сокращается, но критические ошибки по-прежнему долго остаются открытыми. Как скорректировать метрику, чтобы она не скрывала этот риск?

На дашборде QA видны только дефекты после релиза. Какой класс метрик добавит управляемости процессу качества?

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

Дефект обнаружен перед релизом, хотя ошибка была заложена в требовании. Как принцип стоимости качества должен изменить решение команды?

На проекте дефекты теряются между разработкой, QA и эксплуатацией. Какой механизм распределения ответственности устранит этот пробел?

На ретроспективе после серьёзного инцидента команда ищет виновного, хотя дефект уже исправлен. Какой механизм качества превращает инцидент в системные улучшения?

После замечаний в pull request автор изменил код, но старые согласования всё ещё считаются действительными. Определите риск в политике защиты основной ветки и исправьте его.

protected_branch:
  name: main
  require_pull_request: true
  required_approvals: 2
  dismiss_stale_approvals: false
  allow_direct_push: false

Сервис исчерпал допустимый бюджет ошибок, но бизнес настаивает на новом релизе. Как механизм error budget должен повлиять на решение?

Команда хочет выкатывать новую логику без немедленного показа пользователям. Как механизм feature flags отделяет развёртывание от выпуска?

В команде проверки запускаются только после попадания изменения в основную ветку. Какой контроль CI должен перенести обратную связь на этап до слияния?

on:
  push:
    branches: [main]

jobs:
  quality:
    runs-on: linux
    steps:
      - run: install
      - run: test

Независимые быстрые проверки в пайплайне выполняются последовательно. Какое изменение его организации сократит время обратной связи без ослабления quality gate?

В QA одновременно открыто больше проверок, чем команда успевает завершить. Какой механизм управления потоком снизит накопление незавершённой работы?

Как превратить расплывчатое требование «сервис должен быть быстрым» в управляемую цель качества?