Как вы встраивали QA в agile/scrum sprint, чтобы тестирование не становилось бутылочным горлышком в конце?
Сначала попробуйте ответить сами30 секунд
Участвовал в refinement и уточнял acceptance criteria до начала разработки, тестировал фичи инкрементально по мере готовности срезов. К последним дням спринта оставалась только валидация — открытий новых проблем на финише не было.
Пример 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, автоматизацию и расширение команды.
- Нет данных о распределении дефектов по времени спринта — нельзя диагностировать и улучшать процесс.
Частые вопросы на собеседовании
- Приведите пример, когда вы выбирали между ручным тестированием и автоматизацией.
- Расскажите, как вы боролись с flaky tests.
- Опишите ситуацию, когда релиз шёл с известными дефектами. Как вы участвовали в решении go/no-go?
- Расскажите, как вы строили тестовую стратегию для продукта или крупной фичи с нуля.
Что портит ответ
- Ждать готовой задачи в конце sprint.
- Считать QA единственным владельцем качества.
- Не участвовать в acceptance criteria до разработки.
Что слушает интервьюер
- Практикует shift-left testing.
- Снижает bottleneck в конце sprint.
- Делает качество общей ответственностью команды.