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

Перед запуском автоматизации у команды десятки ручных проверок. По какому критерию выбрать первую?

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

После нагрузочного теста оценка вероятности сбоя изменилась. Как корректно обновить риск в реестре?

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

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

Дефект исправлен, но команда проверяет только сценарий, на котором он проявился. Какой механизм определит необходимый объём повторных проверок?

Команда использует показатель эффективности удаления дефектов, рассчитанный так:

def эффективность_удаления(до_релиза, после_релиза):
    return до_релиза / (до_релиза + после_релиза)

команда_а = эффективность_удаления(90, 10)
команда_б = эффективность_удаления(9, 1)

Можно ли на основании одинакового результата сравнить качество двух команд?

В репозитории два pull request по отдельности проходят CI, но после объединения иногда ломают основную ветку. Какой контроль CI предотвращает проверку устаревшего результата слияния?

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  quality:
    script: run-tests
    required: true

merge:
  strategy: direct

Пайплайн стал на 20% медленнее после расширения набора тестов. Чем проверить, ухудшилась ли скорость обратной связи на самом деле?

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