Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

Dmtm, Возможно это экономия времени разработчика. Но в этом случае разработчик никогда не задается вопросами типа "а все ли я учел? " и "а будет ли все это вместе корректно работать?".
Тестировщик не видит кода и менее квалифицирован, поэтому ему сложно задаться этими вопросами.
При этом некоторые проблемы так и останутся не решенными. Проблемы будут накапливаться и этот хаос будет тормозить работу всех, включая тимлида. Не говоря уже о качестве в итоге.

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

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

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

В вашей ситуации, видимо, проще повысить тестировщика до тестировщика-аналитика: сперва отдаёте ТЗ ему, он пишет тестовый план и в процессе уточняет ТЗ с его автором, берёт с кодеров подписку, что им всё понятно, и только потом они идут кодить.

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

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

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

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

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

И еще: проблема в том, что идеально формализованное ТЗ - это и есть код.

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

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

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

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

Логика проработана аналитиком, но программисты не вникают до конца в эту логику и не задают вопросов. Вместо этого они предпочитают сделать как им проще и затем получить критику от тестировщика. При этом отдать результаты аналитику для оценки они не могут, поскольку баги неотличимы от недопонимания на этом этапе. Поэтому тестировщику приходится работать за аналитика.

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

Vitaly Karasik, Тестировщик в данном случае - это обычно инженер который не то что бы эксперт по предметной области, но где-то близко к ней работал. Навыков архитектора у него точно нет. Он не понимает задачу так же хорошо как аналитик или даже тимлид, но не него нет выбора отказаться от вникания в суть задачи, который есть у программистов. Программисты в данном случае этим пользуются, чтобы упростить себе жизнь. Хотя на деле ИМХО код без понимания бывает даже сложнее написать, чем с пониманием.

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

Александр Прохорович, Спасибо!

Является ли порочной практика итеративных попыток сдачи тестировщикам сырых результатов работы?

Это нормальная практика, когда тестировщик итеративно смотрит сырые варианты.

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

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

Здесь вопрос лучших практик. Как люди работают в большинстве случаев: стремятся сделать из программистов самодостаточных специалистов, способных сделать только по user story готовый продукт или пусть лучше программисты будут узкими специалистами, винтиками, а работа будет четко разделена между разными людьми.
Тот вариант, что я описал, он в некотором роде промежуточный - программисты могут сделать все сами хорошо, но если не справились, то тестировщик их прикрывает и они начинают ходить по кругу. Вопрос, имеет ли смысл заставлять программистов избегать этого итеравтивного штурма тестировщика сырыми решениями или не заставлять, пусть будет как есть. Понятно, что в каждом коллективе и задаче оптимальное решение может отличаться.