Однажды мы исправили ошибку с накоплением скидок — промокод и скидка лояльности сочетались таким образом, что финансы определенно не одобрили — отправили исправление, закрыли заявку и перешли к следующему спринту. Одиннадцать месяцев спустя рефакторинг...
Однажды мы исправили ошибку с накоплением скидок — промокод и скидка лояльности сочетались таким образом, что финансы определенно не одобрили — отправили исправление, закрыли заявку и перешли к следующему спринту. Одиннадцать месяцев спустя рефакторинг службы ценообразования вновь выявил ту же самую ошибку. Та же первопричина, тот же неверный результат, те же клиенты получают скидки, которых им не следовало делать. Никто из команды не помнил первого инцидента. Человек, который изначально это исправил, покинул компанию. Единственной записью, которая когда-либо произошла, был закрытый билет Jira, который никто не подумал проверить перед слиянием рефакторинга.
Вот и весь аргумент в пользу регрессионного тестирования в одной истории, и это гораздо более узкий аргумент, чем «запустить тесты еще раз перед выпуском». Регрессионный тест не является универсальной страховкой. Это особая, постоянная запись, в которой говорится: именно эта штука однажды сломалась, вот доказательство, что ее нельзя сломать снова так же.
Почему одного исправления никогда не было достаточно
Исправление ошибки закрывает инцидент. Это не мешает следующему пользователю повторно ввести его, потому что исправление само по себе не оставляет в базе кода никаких следов, объясняющих, почему старое поведение было неправильным. Шесть месяцев спустя кто-то провел рефакторинг