Довольно неплохая статья о том, как это должно работать. Из личного опыта могу внести комментарий по поводу релиза, а именно: «одна команда простаивает, пока работает другая (и далее)» Для того, чтобы не было простоя, актуализация кейсов может быть осуществлена в начале следующего спринта (обычно, первые пару дней, нагрузка в тестировании значительно ниже). Особенно это актуально, если бизнесом были внесены изменения во 2й половине спринта, из-за чего разработка физически не успевает и допилить доп.фичи, и актуализировать кейсы, и прорегрессить (в случае, когда покрытие автотестами мало или же вовсе отсутствует), и релизнуться. Это не норма, но на моей личной практике помогает сэкономить драгоценное время и избежать перекоса нагрузки между концом текущего и началом нового спринта.
Довольно неплохая статья о том, как это должно работать.
Из личного опыта могу внести комментарий по поводу релиза, а именно: «одна команда простаивает, пока работает другая (и далее)»
Для того, чтобы не было простоя, актуализация кейсов может быть осуществлена в начале следующего спринта (обычно, первые пару дней, нагрузка в тестировании значительно ниже). Особенно это актуально, если бизнесом были внесены изменения во 2й половине спринта, из-за чего разработка физически не успевает и допилить доп.фичи, и актуализировать кейсы, и прорегрессить (в случае, когда покрытие автотестами мало или же вовсе отсутствует), и релизнуться.
Это не норма, но на моей личной практике помогает сэкономить драгоценное время и избежать перекоса нагрузки между концом текущего и началом нового спринта.