QA в Agile
Как тестирование встраивается в спринт — роль QA от груминга до сессии трёх амиго, тестирование внутри итерации, а не после неё, критерии QA в Definition of Done и оценка трудозатрат на тестирование.
5 вопросов
MiddleТеорияОчень частоКакие QA-критерии входят в Definition of Done истории и чем он отличается от Definition of Ready?
Какие QA-критерии входят в Definition of Done истории и чем он отличается от Definition of Ready?
Definition of Done — это общий чек-лист команды, которому история должна соответствовать, чтобы быть готовой к поставке. Его QA-критерии требуют: критерии приёмки проверены, тесты зелёные, нет открытых критичных/крупных дефектов, регресс пройден. Definition of Ready — входной gate: история стартует, лишь когда её критерии приёмки и тестируемость ясны.
Типичные ошибки
- ✗Сводить Definition of Done к «код смёржен» без тестовых критериев
- ✗Путать Definition of Done (выходной gate) с Definition of Ready (входной gate)
- ✗Считать DoD чек-листом одного человека, а не соглашением команды
Уточняющие вопросы
- →Почему Definition of Done должен быть соглашением команды, а не только QA?
- →Что входит в Definition of Ready, чтобы история была тестируемой с самого старта?
JuniorТеорияЧастоЧто такое сессия трёх амиго и что привносит в неё QA?
Что такое сессия трёх амиго и что привносит в неё QA?
Сессия трёх амиго сводит вместе три взгляда на пользовательскую историю — бизнес (PO или аналитик), разработку и тестирование — чтобы выработать общее понимание до начала кодирования. QA привносит взгляд тестирования: граничные случаи, критерии приёмки и тестируемость, чтобы неоднозначность всплывала рано, а не во время прогона тестов.
Типичные ошибки
- ✗Думать, что три амиго — это три разработчика или три тестировщика, а не бизнес/dev/тест
- ✗Считать её формальным gate приёмки, а не разговором ради общего понимания
- ✗Полагать, что QA лишь слушает, а не поднимает граничные случаи и вопросы тестируемости
Уточняющие вопросы
- →Кто эти три амиго, и может ли каждую роль представлять больше одного человека?
- →Как обсуждение истории заранее снижает переделки по сравнению с ревью в конце?
MiddleТеорияЧастоКогда тестирование идёт внутри спринта и как не дать ему скопиться в конце?
Когда тестирование идёт внутри спринта и как не дать ему скопиться в конце?
Тестирование идёт непрерывно весь спринт, а не фазой после разработки. QA тестирует каждую историю, как только она собирается, а не ждёт, пока допишут весь код. Это избавляет от мини-водопада, где тестирование сжато в последние дни: тонкая нарезка историй, парная работа с разработчиками и автоматизация регресса держат тестирование в ногу с кодом.
Типичные ошибки
- ✗Считать тестирование фазой, начинающейся только после всей разработки
- ✗Откладывать непротестированную работу в следующий спринт или hardening-спринт
- ✗Не нарезать истории достаточно тонко, чтобы начать тестировать частичную работу
Уточняющие вопросы
- →Что такое hardening-спринт и почему опираться на него — антипаттерн?
- →Как тестирование истории сразу после сборки меняет то, как их нарезают?
MiddleДизайнЧастоВаша Scrum-команда на планировании двухнедельного спринта. Владелец продукта приносит историю: добавить новый способ оплаты в существующий флоу оформления заказа, и разработчики оценивают её в 5 story points. Как единственный QA в команде, вы должны оценить трудозатраты на тестирование, чтобы вся история всё же уместилась в спринт. Опишите, как вы приходите к оценке тестирования: что спросите об истории до того, как назвать число, какие факторы поднимают или снижают трудозатраты (новый или изменённый код, интеграции, риск, имеющееся покрытие автотестами, подготовка тестовых данных), как учтёте регресс и исследовательское тестирование и как донесёте оценку и её неопределённость. Скажите, что сделаете, если по вашей оценке история слишком велика, чтобы закончить её в спринте.
Ваша Scrum-команда на планировании двухнедельного спринта. Владелец продукта приносит историю: добавить новый способ оплаты в существующий флоу оформления заказа, и разработчики оценивают её в 5 story points. Как единственный QA в команде, вы должны оценить трудозатраты на тестирование, чтобы вся история всё же уместилась в спринт. Опишите, как вы приходите к оценке тестирования: что спросите об истории до того, как назвать число, какие факторы поднимают или снижают трудозатраты (новый или изменённый код, интеграции, риск, имеющееся покрытие автотестами, подготовка тестовых данных), как учтёте регресс и исследовательское тестирование и как донесёте оценку и её неопределённость. Скажите, что сделаете, если по вашей оценке история слишком велика, чтобы закончить её в спринте.
Сначала разберитесь в истории — объём, критерии приёмки и риск. Затем взвесьте драйверы трудозатрат: новый или изменённый код, число интеграций, имеющаяся автоматизация и подготовка тестовых данных. Добавьте время на регресс вокруг затронутых мест и на исследовательское тестирование, а не только на happy path. Дайте диапазон, а не ложно-точное число, и отметьте неопределённость. Если история не влезает в спринт, предложите разбить её или урезать объём с PO, а не молча срезать тестирование.
Типичные ошибки
- ✗Применять фиксированное соотношение «тесты = X% от dev» к любой истории без учёта риска
- ✗Оставлять регресс и подготовку тестовых данных вне оценки
- ✗Давать одно точное число вместо диапазона с указанной неопределённостью
Уточняющие вопросы
- →Как бы вы разбили историю, если тестирование выводит её за ёмкость спринта?
- →Почему оценку лучше давать диапазоном, а не одним числом?
SeniorДизайнИногдаВы — единственный QA-инженер в Scrum-команде с шестью разработчиками, релиз выходит раз в две недели. Каждая история проходит тестирование через вас, и очередь готовых, но непротестированных историй растёт к концу каждого спринта — вы стали бутылочным горлышком, и качество проседает, пока вы гоните в последние дни. Нанять второго тестировщика нельзя. Опишите, как бы вы держали качество высоким, не будучи той единственной точкой, за которой всё выстраивается в очередь: как распределите ответственность за тестирование по команде, куда вложите своё ограниченное время, что автоматизируете или встроите в Definition of Done, как помогают тестирование внутри спринта и разговоры трёх амиго и какие риски осознанно примете, вместо того чтобы пытаться протестировать всё самому.
Вы — единственный QA-инженер в Scrum-команде с шестью разработчиками, релиз выходит раз в две недели. Каждая история проходит тестирование через вас, и очередь готовых, но непротестированных историй растёт к концу каждого спринта — вы стали бутылочным горлышком, и качество проседает, пока вы гоните в последние дни. Нанять второго тестировщика нельзя. Опишите, как бы вы держали качество высоким, не будучи той единственной точкой, за которой всё выстраивается в очередь: как распределите ответственность за тестирование по команде, куда вложите своё ограниченное время, что автоматизируете или встроите в Definition of Done, как помогают тестирование внутри спринта и разговоры трёх амиго и какие риски осознанно примете, вместо того чтобы пытаться протестировать всё самому.
Перестаньте быть единственным gate. Распределите тестирование по команде: разработчики владеют unit- и интеграционными тестами, а критерии качества уходят в Definition of Done. Нарезайте истории так, чтобы тестирование шло по мере готовности — внутри спринта, а не в конце. Своё время тратьте там, где риск выше: исследовательское тестирование и обучение разработчиков. Автоматизируйте стабильный регресс и ловите неоднозначность рано на трёх амиго. Приоритизируйте по риску и примите низкорисковые пробелы, а не тестируйте всё сами.
Типичные ошибки
- ✗Пытаться лично тестировать каждую историю и просто работать дольше
- ✗Верить, что 100% автоматизация убирает нужду в живом тестировании и QA в планировании
- ✗Сдвигать тестирование в следующий спринт, создавая постоянный лаг тестирования
Уточняющие вопросы
- →Какое одно изменение вы сделали бы первым и как измерили бы, что оно сработало?
- →Как решить, какие риски безопасно оставить непротестированными?
