всё, я вас люблю.

У нас с вами разное представление о "странно".
Обычно есть Definition of Done фичи (что должно быть сделано) и некие критерии качества aka quality gate, описывающие с каким объемом проблем можно или нельзя релизить.

Но надо понимать, что и то, и другое - не монументальная истина.
Всё это может отлично меняться (и в нормальных командах должно) в зависитмости от бизнес значимости.
Потому что иногда можно упороться по полишингу и максимально сузить quality gate.
Иногда надо заделиверить минимально жизнеспособную фичу.

Слишком много переменных (специфика проекта, критичность фичи, внешние дедлайны, бизнес значимость, процессы в команде, релизный цикл, етк етк етк).

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

>Всё это может отлично меняться (и в нормальных командах должно) в зависитмости от бизнес значимости.
Упаси Боже. Но я понял)

Ну, сорян. В этом смысл всех этих ваших канбанов и ажилов.
Инкременты в продукт важнее, чем соблюдение инструкций и процессов.

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

Смотрите. Придти и сказать "нужно больше времени" можно, но это плохая практика.

Хорошая практика придти и сказать "Смотри, у нас есть вот такие, такие и такие проблемы, они чреваты вот этим, этим и этим. На их исправление нужно столько времени".
Дальше менеджер уже идёт общаться с бизнесом (или не общаться) и принимать решение, что перевешивает - срочность задачи (выпустить сейчас as is) или те баги, которые вы нашли (отложить дедлайн).

Ситуаций для каждой из этих опций более чем достаточно.

Ну, в скраме с таким никогда не сталкивался. Там задачу могут хоть 3 спринта переносить, пока у тестировщика руки до неё не дойдут и DoD не выполнится. А вот в канбанах релизить задачи без тестов и 3 раза в день менять приоритеты - это прям мастхэв, по ходу

Не "такие и такие проблемы", а "такие и такие не протестированные области, это чревато такими и такими багами на бою в перспективе". Но суть, кажется, не меняется.

Ну, "мы это не тестировали" - тоже проблема, ибо == "мы не знаем, работает ли оно в этих кейсах".

Вы описываете два примера кривых процессов, но при этом одни считаете нормальными, а вторые дерьмовыми.
Интересно. :)

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

но ведь про "переносить задачу три спринта" - это как раз про те самые приоритеты задач, про которые мне так активно пытались объяснять выше :о  
были задачи на тестирование поприоритетнее, вот и переносилось.
я совершенно отчаянно ничего не понимаю, как правильно-то

Разница в том, что "нужно больше времени" не предполагает пространства для решения.
Это просто "выдели больше времени".

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

В “нормальных” процессах все спокойны, счастливы и уверенны в завтрашнем дне. В дерьмовых все бегают с горящей жопой, потому что заказчику выкатили дерьмо (по его же просьбе), он разозлился (внезапно), вставил всем п*здюлей и в очередной раз переколбасил все приоритеты. Но это моя личная градация

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

К сожалению, Дмитрий не сожет дальше поддерживать дискуссию.

Правильно - не брать больше задач, чем команда успевает сделать за спринт.
Если вы не успеваете что-то сделать, это значит что процесс уже сломан и что-то идёт не так.

Дальше у вас есть простая пропорция: N необходимой работы и M ресурсов, где N > M.
Решить эту проблему можно двумя способами (каждый из которых, на самом деле, включает в себя несколько вариантов).
Или увеличивая количество ресурсов (нанять ещё людей, взять больше времени).
Или уменьшая объем работы (меньший объем тестирование -> меньше уверенности в уровне качества).

Оба варианта это tradeoff в определенную сторону.
В одном случае вы теряете деньги, которые могла бы принести фича из-за отложенного релиза или тратите больше денег на команду тестирования.
В другом случае вы несёте определенные риски из-за того, что где-то баги.

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

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

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

как убить дискуссию, убрав ровно одного человека))
(флейм, ага. извиняйте)