Как оцениваете задачу и время на спринт

Что проверяют

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

Как отвечать

Отвечайте на своём процессе, но с понятным каркасом:

• сначала требования: до оценки выясните критерии приёмки и зависимости. Если задача непонятна, честнее взять исследовательскую задачу (spike) на день, чем назвать число наугад;
• декомпозиция тестирования: тест-дизайн, подготовка данных и окружения, прогон, повторная проверка исправлений, автотесты на новую функциональность, регресс затронутых мест. Каждую часть оценить проще, чем всё целиком;
• story points вместе с командой: на planning poker QA оценивает задачу вместе с разработчиками, и сложность тестирования входит в общую оценку истории. Если тестирование непропорционально тяжёлое, скажите об этом вслух;
• часы для своего планирования: для крупных задач помогает оценка по трём точкам, оптимистичной, реалистичной и пессимистичной, со средним по формуле (O + 4M + P) / 6;
• ёмкость спринта: вычтите отпуска, дежурства, встречи и время на регресс перед релизом. Опирайтесь на фактическую velocity прошлых спринтов, а не на желаемую;
• сверка: на ретроспективе сравните план и факт и найдите, где оценка систематически уезжает.

Приведите свой пример: задача, которую недооценили, почему (окружение, тестовые данные, неожиданные интеграции) и что поменяли. Если в прошлой команде оценки давал только тимлид, так и скажите и объясните, как включились бы в процесс сами.

Где спотыкаются

Оценивают только прогон тест-кейсов. Подготовка данных, повторные проверки и нестабильное окружение съедают не меньше времени, и оценка проваливается каждый спринт.

Путают story points с часами и пересчитывают их по курсу «один пойнт равен дню». Смысл относительной оценки теряется, а скорость команды превращается в план для отчёта.

Говорят, что тестирование начинается, когда разработка закончена. Интервьюер слышит мини-водопад внутри спринта, где QA гарантированно не успевает.