если что, речь только о моменте с кейсами, а не то, что тестировщик должен вникать еще на этапе разработки (учавствовать в демо и т.д)

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

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

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

в хороших командах это так независимо от процесса разработки

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

или речь о другом?
мб я бегло слишком прочитал

Ну, смотрите.
У вас есть система пропорций.
X кейсов
Y времени
Z ресурсов

Если вам не хватает времени * ресурсы на прохождение кейсов, вы можете:
- Увеличить количество времени.
- Увеличить количество ресурсов.
- Более правильно использовать ресурсы.
- Изменить количество кейсов.

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

я пытаюсь отталкиваться от изначального вопроса

а так то я ж написал - если тестировщик для написания кейсов/стратегии/тестирования ждёт окончания кодинга - это вотерфол в худшем виде

+

я это и писал выше
(брать людей из других отделов, отсеивать мене важные кейсы)

это какой то воображаемый мир, когда у тестировщика нет работы до конца разработки фичи

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

но в этом вопросе ключевое - узнать у тестировщика КАК он будет подходить к вопросу
то есть понять - он тупо возьмёт кейсы, свесит на менеджера, предложит варианты и если предложит - какие

Да, сорян. Не туда зареплаил.
Это, конечно же, было адресовано автору исходного вопроса, ака @cedarcedar99

классический kanban - когда GTD построен так, что задачи параллелизируются минимально

как вариант

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

то есть вся команда обычно параллелит задачу с минимальными шифт-лефт/райт активностями

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

ну да, ессесно, но, например, приоретизация не отсекает варианта "если успеем", она принимает риск "не успеть менее приоритетное"

Мне кажется довольно очевидным, что «успеть сделать больше, чем планируешь» лучше, чем успеть сделать меньше.
Поэтому не вижу особого смысла это отдельно проговаривать.
Но в целом да, вы, конечно же, правы.
Подход «протестировать сколько успеешь» - тоже есть, распространён, работает.