Хмм, пользователи все скинулись разработчикам на зарплаты, а фичи на доске определили путём прямого демократического голосования? Речь о том, что лицо, принимающее решение, далеко не всегда -- пользователь. И никогда -- репрезентация всех пользователей. Как-то так.

Upd: *почти* никогда. В мире всякое случается ;)

Ну так подходы сильно зависят от команды. От того, какой приоритет у качества, от скиллов тиммейтов, от бюджета. Поэтому будет полезнее получить фидбек от своей команды, а не от ноунеймов из интернетов)

дико извиняюсь. а можно сразу к мысли о том, какое это имеет значение в текущем вопросе?

Ну, давайте говорить аналогиями.
Вот у вас есть sanity check, у которого приоритет 0, пушто он проверяет общую жизнеспособность.
Есть smoke check у которого приоритет 1, потому что он покрывает больше сценариев, но все они критически важны.
Есть функциональное тестирование фичи, у которго приоритет 2, потому что там не только важные сценарии.
И есть условный фулл-регрешн, где вы прогоняете все корнер кейсы, мультибраузерность, пиксельпёрфект, негативные тесты, и прочее, у которого приоритет 3, потому что это тоже важно и нужно, но самое критичное уже покрыто предыдущими шагами.

Вот история в том, что эти этапы тестирования (отражающие полноту тестов, которые вы гоните) приоритезируются так же, как и все остальные задачи.

И в кейсе, когда вам срочно надо заделиверить пять разных задач, проводить полное исчерпывающее тестирование каждой из них поочереди - плохая идея.
Лучше двигаться поступально, от более приоритетных кейсов по каждой из них, постепенно увеличивая степень покрытия тестами.

Л - любопытство) команде просто придётся смириться х)

У Х есть какая-то основная миссия(и), юзкейсы которые делают его годным? Может таковую можно придумать?

Берём майндмап. Начинаем строить дерево по этой основной миссии. Какие куски составят годность Х хотя бы до хотфикса, т.е. будет что-то чем можно пользоваться, а не сразу выкинуть? Идём по этим кускам.

Если возникают идеи что ещё составляет годность или критичность для Х, добавляем в майндмап немедленно.

Идём по этому пути, репортим баги.

Если упёрлись в какой-то блокер, спрашиваем оценку времени на фикс и его импакт.

Возможны варианты:
Фикс долгий и тяжёлый, другие задачи приоритетнее -- переключаемся.  

Фикс долгий и тяжёлый, но Х приоритетнее -- делаем ревизию все ли годные куски Х мы добавили в карту.

Если можем добраться до ещё кусков для годного, идём по ним.

Все предложенные варианты страдают негибкостью что подход только один. Но в принципе можно определять следующий приоритет после каждого условного промежутка.

и тут мы опять упираемся в вопрос приоритетов. представим, что по этим фичам есть чеклисты, и по чеклистам есть приоритеты. тогда мы можем сказать, что сначала проверяем приоритет 1, потом 2, потом 3 и так далее. То есть куски функционала, которые суперважны, очень важны, важны, не очень важны и т.д. Если же этого нет, то есть нет понимания, что в этих фичах важно, а что нет, то, во-первых, это уже задница размером с борца сумо, а во-вторых, как я уже сказал, если нет приоритетов и понимания - с тем же успехом можно просто лопатить до упора то, что попалось в руки, пока оно не истощится

а в чём смысл? так у нас не приблизится к реальному релизу ни одна из задач. Ничто не выйдет "пораньше".

на каком моменте тестировщик может сказать "я всё. пойду лучше потестирую вот ту, куда более симпатичную задачу"?)

Эмм, мысль была в том, чтобы навести Вас на мысль о приоритетности приоритетов, о чём коллеги ломали клавиатуры выше.

Канбан вполне себе реальность.  Я видал таковой не только там где "мы в огне и всё горит", но и у очень даже думающих и себя не обижающих людей, у которых много задач исследовательского толка,  в которых ещё неизвестно на что наткнёшься или что получится.

как видите, безуспешно) у коллег, впрочем, тоже...

хм...

Смысл в том, что бы:
а) максимально быстро давать фидбэк по каждой из фичей.
б) не тратить время на менее приоритетные тесты, когда вам ждут более приоритетные.

Дальше уже вопрос приоритетов.
Если бизнес говорит "окей, вот эта задача важнее - тестируем её пока она не будет ready to release, остальное откладываем" - значит приоритеты меняются.
Если бизнес говорит "все вот эти фичи капец срочные", то вы двигаетесь циклами по приоритету, каждый раз давая апдейт "вот здесь критичные сценарии работают, остальное ещё не тестировалось".

тут тот же вопрос. В чём смысл этого подхода?
у нас не приблизится к реальному релизу ни одна из задач. Ничто не выйдет "пораньше". Пользователи не получат ни одной из фичей до условного конца июня

тут другой вопрос - вы точно знаете, что вам РЕАЛЬНО хватит времени на то, чтобы протестировать и пофиксить ВСЕ баги, которые надо будет фиксить - и что все эти фичи 100% будут в релизе и будут рабочими?

Session-based. Это что-то вроде известного помодоро, но подлиннее -- часовые промежутки, или "пара", как в институте.

Промежуток непрерывен -- пока в нём, занимаемся чем-то одним. Когда его прошли -- можем, как студенты, решить идти на следующую пару, или куда ещё ;)

Если как-то построить карту приоритетов, вполне может получиться.

На самом деле действительно дико увлекательно, насколько у всех различаются контексты, вот что.

контекст у всех один

максимально закрыть самые уязвимые места в первую очередь