собственно вопрос/просьба. Чего предпочитаете/вынуждены/хотели бы придерживаться вы?
есть ли ещё какие-то варианты?)
есть ли явные минусы и плюсы у каждого из подходов?)

1. Идем к фича оунеру и узнаем бизнес-сценарии использования фичи.
2. На основании этого узнаем приоритет самого важного в ней и самого дорогого и нужного оунеру.
3. На основании этого создаем чеклист, состоящий из того что выше и "остального" (которое тоже можно отфильтровать по приоритетам".
4. Тестируем сначала приооритетное, потом не очень, сдавая баги в режиме реального времени.

то есть вариант 1. окей) спасибо

Казалось бы, при чём здесь канбан?

Это вариант или 1, или 2 -- как договорились. 3 -- так-то вообще не вариант.

Да, но не забываем про первые три пункта из того, что я написал. Или добавляем пункт 5: по вечерам плачем, запивая водкой.

да фиг его знает. в предыдущем чате задавала когда вопрос - несколько менее подробно формулировала. Пока объясняла в диалогах - сказали "а, канбан"

или пивом, хотя кто плачет под пиво

Ну, кто что из опыта вспомнил и на что спроецировал. Могу все варианты в любой итеративной модели представить.

После пятничнорелизного "приключения на 20 минут, вошли и вышли" не грех хоть под что плакать ;)

с этим вопросом как с курением (когда курящий уже сам может лекции о вреде курения рассказывать). Приходишь, спрашиваешь, получаешь тонну инфы про приоритизацию, и мало - по менеджменту своего времени :)
а приоритизация не интересует

По менеджементу СВОЕГО времени -- это к Дорофееву (джедайские техники, гуглятся на ютьюбе в +- полном изложении от автора, чуть меньше 3 часов

А, окей

у меня сложно с формулировками. Тут, конечно, не только своё время задействуется. Но "своё" - в первую очередь. И не только время

Мы предпочитаем менять такие проекты, пусть других дураков ищут)
Ну а вообще вариант 2 удобнее - декомпозируешь по блокам, на каждый блок пишешь кейсы, прогоняешь все кейсы, заводишь баги, занимаешься другими делами. После того, как некоторое количество багов пофикшено, прогоняешь полную регрессию по всей большой фиче и так до тех пор, пока все баги не будут найдены и пофикшены.
Количество кейсов определяется временем, доступным для тестирования. Если сроки постоянно горят, тогда тестировать только самые основные юзкейсы (аксептанс критерии, если есть) и заранее предупредить об этом менеджеров/продукт овнеров, чтобы потом у них не возникало вопросов “а как этот баг пропустили?”

спасибо! (поздравляю с ачивкой - первый человек в моей скромной статистике с вариантами, отличными от 0 и 1! :))

Делим фичу на тест-сессии, расставляем им приоритеты в рамках бизнес значимости, двигаемся по тому самому канбану исходя из приоритетов.

незнакомое словосочетание тест-сессии. Не совсем понятно - с другими задачами, висящими в очереди, ведь не мешаем эти сессии по приоритетам?

Ну, тест сессия на фичу х - это такая же задача для тестирования, как и все остальные.

Дык я ж то же самое и написал. Там выше сказали, что приоритеты не нужны, а ннужен тайм-менеджмент.