Как стать автором
Обновить

Как мы за год в 5 раз снизили количество приемочных багов через shift left testing

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров11K
Всего голосов 14: ↑13 и ↓1+13
Комментарии12

Комментарии 12

История стара как мир. Как говорится, без внятного ТЗ - результат ХЗ.

Хм, а я почему-то думал, что «таск» это мужской род. А выходит, что женский – «таска».

ага, все так. но тут уж поэзия it'шного жаргона) до сих пор, кстати, не могу привыкнуть, что "баг" иногда называют "бага"

Понятно. И уменьшительно-ласкательные формы лучше выглядят, когда из женского рода образуются. «тасечка» звучит лучше чем «таскунчик». :D

Как мы сократили количество приемочных багов? Стали меньше их заводить!

На самом деле классная статья, спасибо. Пойду закину в команду, как раз задумываемся над увеличением ttm.

2023 год, ребята из Тинькофф узнали, что оказывается тестирование требований - норм тема.

Кайф.

Тут больше о том, как мы это структурировали и поставили на нормальный рабочий поток)

Спасибо за статью)

Хотел спросить по поводу графика «Время доставки сторей». Как именно понять, что этот новый процесс повлиял на скорость доставки сторей, а не сами стори стали просто меньше или проще?)

Привет! Спасибо на добром слове)

Что касаемо вопроса, то, пожалуй, самый весомый критерий тут тот, что ничего в работе со сторями мы не меняли, среднестатистическая сторя осталась такой же, как и была год назад. А "Время доставки" при этом ощутимо снизилось, несмотря на необходимость выделять больше ресурса для работы со спецификациями.

Привет!

Получается что "тестирование ТЗ" все таки не включено в сторю?
Просто в моем понимании, время которое тратилось на приемочные баги, сейчас просто тратиться на "тестирование ТЗ", даже если оно не в рамках стори. Хочется узнать насколько уменьшелось как раз время от первого получения ТЗ (без его тестирования) до выпуска стори в релиз в отличии от того что было когда ТЗ получалось и сразу начиналась разработка, потом фикс приемочных багов и выпуск в релиз.

Отличный вопрос, спасибо! Сейчас сходил в Jira control chart и проверил помесячно нахождение каждой задачи в статусах от момента начала написания спеки, до момента, когда задача готова быть запланированной в разработку, т.е. когда спека по ней уже окончательно готова. И на графике не видно какой-то значимой просадки с момента активного внедрения и применения подхода (это примерно июнь-июль 22го). Правда, в октябре есть аномалия - написание спек для 90% задач заняло 44 дня, на фоне обычных ~30 дней. Наверное, задачи были сложные или осенняя хандра накатила) Главное тут, ИМХО, что мы на этом графике не взмыли в небеса

Зарегистрируйтесь на Хабре, чтобы оставить комментарий