Мне всё-таки больше импонирует задачку по доске двигать, если честно)

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

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

Да, конечно. Но я спрашиваю не для того, чтобы "сделать у нас так, как расскажут", а просто чтобы понять, какая ситуация у других людей)
Хотя местами перегибаю с вопросами, кажется :)

И идёшь ногами до Самары, потому что удалёнка)))
Простите)
А у разработчика в это время другая задача горит, прям синем пламенем) пока на тестирование чего-то другого переключитесь?)

Как по мне, то подход  "увидел и завел" может быть довольно опасным, но, как обычно, это зависит от многих факторов.
Опасность 1: много времени займет процесс заведения из-за чего тестирование и принятие решение о качестве затягивается. Иногда если понимаешь, что тестирование хотя бы по верхам займёт разумное количество времени и ничего не горит, то лучше протестить все и принять решение - релизим как есть и доделываем потом или возвращаем на доработку и ждем исправления. Иногда в процессе приходит понимание, что багов слишком много и проще всю фичу развернуть разработчику с просьбой протестить базовые кейсы самому (если их нет, то написать их в задачу) и не заканчивать тестирования.
Опасность 2: если задач с багами будет слишком много, то можно утонуть в тасках и МР-ах. К тому же ни кто не гарантирует, что исправление №1 после, допустим, исправления №5 будет работать корректно и не поломается из-за связанности багов - кажется разработчику проще видеть все баги сразу, возможно многие исправляются в одном месте.

Всё по делу)
Правда, не очень ясно, как время на заведение багов зависит от времени их заведения.
И почему если возвращаешь разработчику - необходимо и самому продолжать тестировать Оо

Ещё удивляет, что никто не упомянул смок-наборы, если честно...

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

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

Если речь про новую функциональность, где обычно багов больше всего, то смоук тесты тут вообще не применимы, так как на эту функциональность их нет.

У вас как с коммуникациями в команде?

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

всё хорошо с коммуникациями)
эт просто я капризничаю и думаю итеративно тестировать. и стало интересно узнать мнения

Я всегда все записываю в текстовый документ, потом сижу разбираю :) иногда пока руки дойдут завести, то уже баг и не воспроизводится 😂

🍦

Тоже так делаю, и бывает что баг не баг а сама накосячила, лишний перенос строки сделала или ещё чё..:)

Не пройден acceptance-возвращай в разработку. Сами acceptance criteria пишутся до девелопмента в задаче и согласовываются заранее До начала имплементации с ответственным разработчиком. JFI acceptance criteria - это critical path сценарии с точки зрения бизнеса и технических рисков ( смотришь сам код в репке). Всё, что не прописано в acceptance criteria - пространство для маневра "стоит - не стоит"

а можн мне тож запись? 😌