Что делает тестировщик на каждом этапе разработки по Scrum
Что проверяют
Понимаете ли вы, что в Scrum нет отдельной фазы тестирования, и умеете ли встроить проверку в двухнедельный ритм. Ответ показывает, работали вы в команде со спринтами или пересказываете учебник.
Как отвечать
Строить рассказ по событиям, а не по этапам водопада:
- уточнение бэклога: вопросы к требованиям до оценки, критерии приёмки, оценка тестируемости, поиск противоречий. Здесь тестировщик приносит больше всего пользы, правка требования дешевле правки кода;
- планирование спринта: сколько времени занимает проверка, входит ли автотест в определение готовности, какие риски закрываем в этом спринте;
- работа в спринте: тест-дизайн параллельно разработке, ранняя проверка по готовым кускам, вопросы разработчику до передачи задачи, регресс в CI, заведение дефектов и решение, что чинится сейчас, а что уходит в бэклог;
- обзор спринта: инкремент показывают заказчику готовым по общему определению готовности, и подтверждение, что показанное работает не только на демонстрационных данных, лежит на команде;
- ретроспектива: что мешало (поздняя передача в тест, нестабильные автотесты, размытые критерии) и что меняем в следующем спринте.
Стоит добавить, что качество в Scrum общая ответственность команды разработчиков, отдельной роли тестировщика во фреймворке нет, и это как раз аргумент за раннее подключение, а не за проверку в конце.
Где спотыкаются
Описывают водопад внутри спринта: сначала разработка, потом фаза тестирования в последние два дня. Так проверка не помещается в спринт, задачи переезжают, и команда каждый раз закрывает спринт незавершёнными историями.
Второе: путают обзор и ретроспективу. На обзоре показывают инкремент и собирают обратную связь от заказчика, ретроспектива внутренняя и про процесс.
Третье: обещают полный ручной регресс и нагрузочное тестирование каждый спринт. Про объём спросят сразу, и отвечать нужно про выбор проверок по риску, автоматизацию и то, что запускается реже и по расписанию.