Как вы встраивали QA в agile/scrum sprint, чтобы тестирование не становилось бутылочным горлышком в конце?

Пример Gherkin-сценария, написанного до начала разработки

# features/checkout.feature
Feature: Checkout payment

  Scenario: Successful card payment
    Given the user has items in cart
    When the user submits payment with valid card details
    Then the order confirmation page is shown
    And the order appears in user history

  Scenario: Payment declined
    Given the user has items in cart
    When the user submits payment with declined card
    Then an error message is displayed
    And no order is created

Встраивание QA в agile-спринт без бутылочного горлышка

Классическая проблема agile-команд: разработчики пишут код весь спринт, отдают QA в последние 2 дня — и либо тесты срезаются, либо спринт срывается. Решение — сдвинуть QA-активности влево и распределить их по всему спринту.

Структура спринта с встроенным QA

Sprint planning — QA как равноправный участник

На планировании я активно участвую в refinement:

• Уточняю acceptance criteria вместе с PM до начала разработки — двусмысленные требования порождают баги.
• Выявляю отсутствующие edge cases в user story.
• Оцениваю тестовые задачи явно в story points — тестирование входит в DoD, а не добавляется сверху.

Во время разработки — shift-left

• Готовлю тест-кейсы параллельно с разработкой, не дожидаясь завершения.
• Тестирую фичи по мере готовности отдельных вертикальных срезов (разработчик отдаёт backend + unit endpoint — QA тестирует API, не дожидаясь UI).
• Участвую в code review с фокусом на тестируемость: наличие data-testid, логируемость ошибок, observability.

Definition of Ready для задачи

Договорился с командой: задача не берётся в спринт без:

• Acceptance criteria в формате Gherkin или чёткого списка.
• Описания happy path и известных edge cases.
• Макета (если UI-задача) или контракта API (если backend).

Конец спринта — только валидация, не открытие

Если QA-активности распределены по спринту, в последние 2 дня я делаю только: финальный smoke, regression по затронутым модулям и sign-off. Никаких «открытий» новых проблем — они должны быть найдены раньше.

Метрика здоровья процесса

Отслеживал: сколько дефектов найдено в последние 2 дня спринта vs в первые 8. Если соотношение смещается в конец — процесс сломан.

Подводные камни

• QA не приглашают на refinement — тогда требования уточняются поздно, баги встраиваются в дизайн.
• DoD без тестирования — разработчики считают задачу готовой без QA sign-off, QA оказывается в конце.
• Разработчики не отдают фичи инкрементально — «отдам всё сразу в конце» убивает параллельную работу QA.
• Не разделять тестовые задачи по времени — все тест-кейсы пишутся в последний день вместо начала спринта.
• Один QA на всю команду — структурное бутылочное горлышко; решение через developer-testing, автоматизацию и расширение команды.
• Нет данных о распределении дефектов по времени спринта — нельзя диагностировать и улучшать процесс.

• Ждать готовой задачи в конце sprint.
• Считать QA единственным владельцем качества.
• Не участвовать в acceptance criteria до разработки.

• Практикует shift-left testing.
• Снижает bottleneck в конце sprint.
• Делает качество общей ответственностью команды.