Отчасти так, разработка задач текущего спринта была 6 раб дней, а дальше фича фриз, в этот момент мы фиксили баги и дальше разработчики переключались на задачи следующего спринта, так как регресс изначально был ручным и занимал довольно длительное время, нам иногда приходилось жертвовать капасити команды для поддержания высокого качества системы, но после автоматизации смоука и части регресса, время на ручной труд снизилось и мы увеличили время на разработку внутри текущего спринта и соответственно снизили на регресс и стабилизацию.
Конкретно для этого проекта метрики собираем раз в месяц(раз в 2 спринта), после сбора, ответственный тестировщик анализирует данные на предмет отклонения от целевых показателей, если такое выявлено, анализируем причины и работаем с ними. Так как дефектов с прода у нас небольшое количество, анализируем первопричину каждого дефекта. Далее несколько вариантов, если баг пропущен на регрессе, обновляем регрессионную модель, если пропущен при тесте задачи, обсуждаем с командой на что стоит обращать особое внимание при тестировании, как нам в следующий раз не пропустить подобную ошибку, все проблемы при тесте задач обобщаем и выделяем в шаблон чит-листа, который используется при разработке ТК.
Достаточно донести до всей команды ценность планируемых изменений, конечно команде тестирования придется привыкнуть к новым правилам и регламентам, но когда процессы дойдут до автоматизма, все будут воспринимать новшества как данность.
???
Отчасти так, разработка задач текущего спринта была 6 раб дней, а дальше фича фриз, в этот момент мы фиксили баги и дальше разработчики переключались на задачи следующего спринта, так как регресс изначально был ручным и занимал довольно длительное время, нам иногда приходилось жертвовать капасити команды для поддержания высокого качества системы, но после автоматизации смоука и части регресса, время на ручной труд снизилось и мы увеличили время на разработку внутри текущего спринта и соответственно снизили на регресс и стабилизацию.
Конкретно для этого проекта метрики собираем раз в месяц(раз в 2 спринта), после сбора, ответственный тестировщик анализирует данные на предмет отклонения от целевых показателей, если такое выявлено, анализируем причины и работаем с ними. Так как дефектов с прода у нас небольшое количество, анализируем первопричину каждого дефекта. Далее несколько вариантов, если баг пропущен на регрессе, обновляем регрессионную модель, если пропущен при тесте задачи, обсуждаем с командой на что стоит обращать особое внимание при тестировании, как нам в следующий раз не пропустить подобную ошибку, все проблемы при тесте задач обобщаем и выделяем в шаблон чит-листа, который используется при разработке ТК.
Достаточно донести до всей команды ценность планируемых изменений, конечно команде тестирования придется привыкнуть к новым правилам и регламентам, но когда процессы дойдут до автоматизма, все будут воспринимать новшества как данность.
Привет! Спасибо, рад, что тебе понравилось. Над второй частью еще работаю. Обязательно опубликую её, как только закончу)