То есть разработчики трудятся две недели спринта, а вы тестируете это одну неделю? А что вы делаете вторую неделю?)

А эту информацию можно найти там же, где её получают разработчики: тикет в джире или что-то подобное. Зачем ещё тратить время на какую-то отдельную документацию?

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

Есть еще предрелизное большое регресс-тестирование, достаточно долгое по времени, плюс участие в проработке, аналитике и составлении документации - и требований, и составление тест-кейсов и т.д.
Так что телик посмотреть врмени нет)

У тебя на одной странице, предположим, реализовано 50 задач. Реализованы они в разные промежутки времени. Вот давай, удачи тебе серфить все задачи относительно этой страницы в поисках описания.
И, кстати, нет. В нормальных командах аналитики описание закидывают и на какую-нибудь конфлу, и разработчики успешно им пользуются оттуда. А в задаче же прикрепляется лишь короткое summary того, что надо сделать

И 50 - это число с потолка) Зачастую это число будет сиииильно больше. А если включать сюда не только новые фичи, но и переделки старых - добро пожаловать в ад

Если у вас действительно всегда 50% от времени разработки - это прям интересно. Но вы же понимаете, что выборка из одной команды - это не выборка) Да и если бы так всё просто было, тест-план не нужен был бы как вид

Ах, черт, ты про спринты даже.в данном случае это совпадение. Я как то думал о более длительных периодах. Но посыл, думаю, ты понял. Не за что зацепиться - эмпирические 50 процентов, в контексте месяцев, там будет время для манёвров.

Да нет, конечно.. Просто никогда не бывает))
И я понимаю, что один пример совсем не показательный. Но у нас выработался такой режим и всем достаточно комфортно, хотя и срывы тоже бывают и много чего еще..

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

А вообще, как по мне, не очень правильная организация работы в принципе, если 3,5 месяца никто не понимал, что происходит. Если задача разбита на мелкие задачи - можно попутно тестировать (ну или хотя бы поверхностно контролировать прогресс). Хотя бы раз в две недели демки проводить - сделано то-то и то-то... можно посмотреть (но руками пока не трогать, а не то сломается, то-то и то-то. К примеру, просто показывать даже самими разработчиками).
и в процессе уже можно сразу видеть какие-то отклонения от изначального плана, иногда - мелкие и не очень баги..

ИМХО, не бывает задач на несколько месяцев, которые нельзя разбить на подзадачи, не важно, монолит, микросервис - все равно не сразу Москва строилась, всегда можно делить и комфортно работать..

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

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

А вот организация бывает разная. Может он тестировщик-аутсорсер и его в принципе наняли после того, как задача была реализована

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

ну да, наверное, соглашусь.. Такое может быть. Но в таком случае, больше к нему самому вопрос - насколько он понял суть продукта и требования к нему. Потому что один "въезжает" в страницу документации за час,  а кто-то две недели мучает (иногда просто даже и написано все через ж...)

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

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

Опять-таки, если информация о фиче\фичах есть ТОЛЬКО у разработчика, который это делал - это жопа в процессах. Прям очень большая жопа

Да. Но процессы прямо сейчас мы не исправим, тем более для текущей задачи. 🤷‍♀️

Как бы да, но я пытаюсь показать, что обрисованный сценарий не реалистичен) 3.5 месяцев делается задача, по которой инфа только в руках разработчика и всё. Никакой документации, ничего подобного. Такой осталось может быть в каких-нибудь всратых гос-компаниях, может быть. И единственный совет тут может быть - бежать нафиг оттуда

Изи
Стартап в котором лагер и пи нихера не шарят а только требуют сроки

Если что, то стартап коллапсировал через 3 месяца с моего прихода )