Для меня не очевиден ответ на п.1. Поясните, пожалуйста.

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

Звучит так, что вы используете спринты просто как контейнеры. Нужны ли вам полноценные спринты в принципе?

Екатерина, спасибо за конкретный пример. Я пытался убедить в такои подходе МП, однако он против, и настаивает на том, что в таком случае разработчики не будут заинтересованы в качественном выполнении задачи, а будут пилить ее как можно быстрее, лишь бы скинуть на тестировщика.

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

Правильно против. И любой скрам мастер будет против. Там это классический антипаттерн

Видимо речь об ATDD

Это классный подход, если тестеры узкое звено

Большое спасибо за наводку, записал себе ознакомиться

Пожалуйста! Про «Цель» тоже посмотри. Перевернула мое представление об управлении любым производством

Эта книга? https://www.ozon.ru/context/detail/id/4341360/

Она

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

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

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

Я чуть позже также хотел задать вопрос о том, как вы решаете межличностные конфликты в командах (помимо увольнения).

угнетение и доминирование!!!! (нет, шутка)

Двухнедельный спринт. Большие задачи бились на более мелкие атомарные. Перетекания из спринта в спринт были, причем довольно часто. Очень часто были ситуации, что накапливалось много задач, человек, который должен был вливать все в ветку и запускать сборку на тестовый стенд, был загружен своей основной  работой. В итоге к концу спринта все вливалось и задачи целой пачкой падали на тестирование. Конечно же тут был выбор, либо тестировать поверхностно, чтобы не портить показатели спринта, либо просить людей перекидывать в следующий спринт. При первом подходе бывало, что пропускали дефекты на прод, опасные с точки зрения бизнеса. При втором подходе вероятность пропуска бага была ниже. Также мы не старались напихивать под завязку спринт, он у нас не был каким-то статичным, он был таким резиновым и наполняемым. Мы оставляли место для критов, внезапных хотелок заказчика и для багов, которые могли родится вследствие тестирования задач в спринте, также оставлялось некоторое пространство для задач, которые будут гоняться из тестирования в багфикс и обратно. Если мы понимали, что по окончании спринта мы не дотягиваем по сторипоинтам, то брались мелкие задачки и разного рода техдолги, чтобы разгрузить разрабов и дать им по фану на расслабоне наклепать мелких задачек

Также у нас особо ушлые разрабы клепали задачкт наперёд, вне спринта)

Т.е мы планировали не один спринт, а бывало что 2 и три. И разраб мог делать задачки из будущего второго или третьего спринта

Звучит в итоге как waterflow который скрамом обозвали

Ну наверное у нас был какой-то извращенный скрам)