Прямо по списку.
Зачем нужны Варианты Тестирования???
--------------
Для повышения качества продукта(чем больше и верно написано ТС тем больше функциональности протестовано, тем меньше ошибок в коненом продукте).
Не верю! Сколько ТС ни пиши, качество от этого не растёт. Даже очень сомнительно, что в результате будет "больше функциональности протестовано".
Для уменьшения затрат времени на регресионное тестиорование (не потребности снова писать ВТ, достатоно провести уже созданніе ранее ВТ ).
Верю условно. Хотя не очень убедительно звучат слова "нет потребности снова писать ТС", выглядит так, будто это неизбежность -- не сейчас, так потом, лучше уж сейчас отмучаюсь. А вообще, если уж регрессионного тестирования действительно много, имеет смысл потратить часть времени на автоматизацию вместо написания ТС.
Для облегчения передачи заний новому сотруднику .
Не верю! И мой личный опыт, и разговоры с коллегами показывают, что гораздо эффективнее для этой цели использовать описание требований. Тесты (особенно написанные в виде множества ТС) -- это лоскутное одеяло, глядя на них составить общее представление о системе совершенно невозможно. Если нет описания требований -- лучше потратить время, чтобы сделать его, а не ТС писать.
Для экономии времени, при фиксации ошибок (можна шаги для воспроизведения брать уже с готового ТС).
Не верю. Один и тот же ТС очень редко находит ошибку повторно, подавляющая часть ТС вообще никогда не превратится в описание ошибки, а тех, которые по несколько раз обнаруживают ошибку и того меньше. Экономия явно не стоит затрат на написание ТС.
Для сдачи продукта клиету (на основе розработаных ВТ можно создать приемочные тесты).
Верю условно. Как правило бывает наоборот -- приёмочные тесты выкатываются заказчиком заранее. Но если заказчик хочет -- действительно, можно часть разработанных ТС включить в приемо-сдаточный набор. Хотя, вообще-то, по такому случаю опять же лучше автоматизировать эту выбранную часть, на заказчиков это производит благоприятное впечатление
Для контроля и управления тестированием (по ВТ можно проверить покрытие).
Верю условно. Покрытие по ТС померить можно, но это очень недостоверная метрика. Лучше всё-таки, если есть возможность, мерить покрытие требований. Если все требования (в том числе нефункциональные) покрыты тестами -- тогда можно, действительно, считать по тестам.
Для прогнозирования времени ресурсов на тестиование(оценка трудозатрат при планировании следующих робот).
Не очень верю. Как правило, следующие работы связаны в большей степени с тестированием новой функциональности. Регрессионное тестирование не должно занимать много времени.
Для выявления ошибок на раних стадиях разработки(путем статического тестирования требований к продукту).
Верю наполовину. Верю в то, что анализ требований позволяет выявлять ошибки на ранних стадиях, и это хорошо. Не верю в то, что написание ТС является обязательным условием для проведения анализа требований.
Для розработки контрольного примера и автоматизации тестов (проще и быстрее автоматизировать тесты уже по описаным шагам ).
Верю условно. Дело в том, что автоматизация это программирование. Представьте себе, что программисты каждый вариант использования реализовывали бы независимо от других. Почему они так не делают? Почему они вместо этого строят единую архитектуру системы, в которой все эти варианты использования реализуют? Потому что так эффективнее. И с тестами то же самое -- программировать каждый отдельный TC независимо от других означает сделать кучу лишней работы. Нужно стремиться к построению более сложной архитектуры тестового набора, повышающей степень переиспользования.
Для подтвержедния проведения тестов.
Не верю совсем! Если тесты написаны, даже очень много, это ещё не означает, что хотя бы один из них реально выполнен
Нужны другие доказательства.
- зачем всетаки они нужны (мы ТЕСТЕРЫ конечно понимаем зачем он нам нужен), но наши мененджеры не хотят, или не могут этого понимать 
, и естественно не выделяют на это ресурсы.
