Легко прорегрессить и выпустить релиз, когда у вас одна команда. И когда две или даже три. А что, если этих команд 15, и они в разных часовых поясах? И глубина понимания бизнес - логики продукта у QA в разных командах отличается в разы? И главное, это не выделенная команда QA. Это QA - инженеры из fullstack feature teams, у которых жесткий тайминг работы над фичами, и в их распоряжении не более двух дней, чтобы оказать помощь на регрессе. При этом продукт один. И он из сферы Финтеха, где цена ошибки очень высока… Надеюсь, опыт компании, которая сумела меньше, чем за полгода, сократить время регрессионного тестирования с недели до 2 дней, будет полезен тест – лидам, пытающимся задать определенную скорость прохождения регрессионного тестирования, не потеряв при этом на качестве.
Я постараюсь пополнить чек-листы best practices и epic fails всех тех, кто организует работу QA при выпуске релизов.