сгущать не вариант. Наше дело - донести всю актуальную информацию без приукрас и без недоговорок. Чтобы другие делали выбор на основе правдивой информации, а не предоставленной в удобном для нас свете

Потеря сотрудников. Кажется, это должно быть главной причиной

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

выкатывать по фиче - вряд ли, а вот ломать по одной-две-три рандомной фиче - запросто 😂

такое бизнес решение уже звучит как катастрофа)

На первый взгляд да. Для второго не хватает контекста. Донести почему это решение - катастрофа - гуд. Сгущать краски - не гуд

Но это, конечно, дело этики и личного выбора. Мне нравится подход как в ‘бригаде ‘. Все, что мы делаем - мы делаем вместе. И отвечаем тоже вместе

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

звучит как аргумент конечно)

Это хорошее решение если бизнес идёт на встречу и выдвигает адекватные требования.

Релизимся каждый день (а скорее несколько раз в день), дежурный тестировщик тот же, что и не дежурный (потому что я тут один :D).
Пока что полёт нормальный.

Комментируя ваш вопрос и в целом ветку дискуссии.

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

История с назначением "дежурного" на неделю - довольно спорная и опасная по нескольким причинам.
1) Банально замыливается глаз.
Повторять в течении недели прогоны одних и тех же тестов, не переключаясь на другие задачи - довольно лютая задача, шансов на то, что пропустишь очевидные баги просто из-за того, что задолбался - много.

2) Люди выгорают, начинают делать "на отвели" - ровно туда же история.
Человек начинает проходить тесты на автомате, особенно не вглядываясь и ставим "Passed" там, где его быть не должно.
В итоге QA не выполняет свою главную функцию - не даёт отчетов о состоянии продукта, которым можно доверять.

3) Нет мотивации "делать хорошо", в принципе.

Что делать, что бы релизить каждый день было не так больно?

1) Уменьшать объем тестирования - выкидывать из регрессии всё лишнее и не приоритетное, остальное проверять уже исходя из скоупа изменений.
Если бизнес хочет "скорость в обмен на качество" - это как раз про это.

2) Упрощать тестирование - автоматизировать то, что можно автоматизировать, упрощать тестирование там, где оно тратит много времени, оптимизировать тестовые сценарии и т.д.

3) Распределять нагрузку - перекладывать часть проверок на разработчиков, параллелить между тестировщиками, привлекать внешние ресурсы, т.д.

Какой аргумент?  Аргументы нужно обговаривать честно и быть честными. Хотите приукрашивать аргументы, тем самым влияя на решение не аргументами - тогда идите свой открывайте и приукрашивать ничего не нужно будет

при урезании регресса мы заранее предупреждаем, что качество страдает, пока не хотя бы процентов 70 не покрыто автотестами. нам говорят "да, ок", но когда критикалы на проде - то чет мы как-то не дотестили получается)

По умолчанию давайте считать что все идут на встречу и выдвигают адекватные требования. Если не идет на встречу, то валите, а не опускайтесь до уровня приукрашиваний

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

Ну, значит «поймали критикал, добавили в тестовый набор, выкинули то, что не критикал».

Почему?

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

Таким образом через некоторое время всё в тестовом наборе будет критикалом и будут находиться дополнительные критикалы, которые некуда впихнуть

В ежедневном релизе нет ничего плохого, главное настроить процесс CI/CD и свести кол-во ручных действий к минимально возможному кол-ву