Кто должен составялять данную "нетленку"? По опыту других проектов даже не возникало проблем: их составляет заказчик. Каково же было мое удивление, когда я узнала, что теперь составляет исполнитель. А как у вас?

Продуктовая разработка - это делаем мы. Заказная - сталкивался и с тем и с другим, зависит от заказчика.

Все зависит от контекста, в котором Вы употребляете это понятие.

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

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

Все зависит от контекста, в котором Вы употребляете это понятие.

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

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

Да, конечно, первый вариант. 

Да, конечно, первый вариант. 

Если Заказчик готов платить за это Исполнителю то почему бы и нет.
Для избежания тех ситуаций о которых упомянул Galogen, необходимо четко ограничить зону ответственности Исполнителя по данной задаче (и зафиксировать это документально в регламенте проекта):
"Задача Исполнителя предложить Заказчику методику проведения испытаний и план тестирования основанный на документации по проекту (в частности на функциональных и не функциональных требованиях)."
Но подписаться под представленным вариантом должен все таки Заказчик.

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

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

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

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

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

У на на проекте мы (разработчик) готовим тест-кейсы. Но у нас это в контракте.

Т.е. исполнитель знает все тонкости бизнеса заказчика лучше чем сам заказчик?

Т.е. исполнитель знает все тонкости бизнеса заказчика лучше чем сам заказчик?

А Вы знаете, порой бывает именно так. Правда я хотел бы пожаловаться на другое.

У меня подобная ситуации с аналитиками. Они мне (тестировщику) говорят, как же вы тестируете не понимая бизнеса. Я согласен нужно понимать бизнес, но аппелирую к ним: а вы на что. Это вызывает "возмущение".

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

Пример. Делаем отчет по штатному расписанию.
У меня есть все цифры. Есть масса тестовых случаев. Я все проверяю и неоднократно. Но ....
Только сделали изменения в алгоритме отчета, я не вижу проблему, заказчик сразу мне ее указывает.

А вот говорит у вас в 500 строке 10 столбца сумма больше на копейку

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

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

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

А еще ...бывало ли в вашей  практике- разработка по тест кейсам?

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

Потому пока у нас происходит примерно так:
Есть релизная задача.
Если она прописана достаточно подробна или является совершенствованием старой задачи, то тут удается спланировать тестирование и написать рабочие тестовые сценарии.
Если это что-то совершенно новое, бесполезно дергаться "доказано зануси" (c). В этом случае пытаемся разобраться хотя бы в бизнес-контексте, что бы понять зачем такая переделка устроена

Однако мой товарищ, работает в фирме по производству игр на ruby on rails, у них чистый TTD в действии и ему очень нравится.

Все зависит от заказчика. Им надо решить проблему - и они нанимают разработчиков. Некоторые заказчики могут иметь высокий уровень ответственности, и полагать что в качественном решении они могут быть уверенны, только если сами примут и протестируют на основании ими же составленных примеров. Особенно если у них есть служба IT, на которую это дело можно свалить. Другие - полагают, что решение проблемы - поставка качественного софта, и если для этого нужны какие-то там тесты - это ваша задача. Заказчик прав по-любому, а дальше вопрос правильных условий контракта и убеждения.

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