А для чего нужны Test Plan(тестовые планы)?
Покажите примерчик плиз

Андрей, рекомендую посмотреть:
http://www.protesting.ru/testing/plan.html
там же два шаблона тестового плана: RUP и IEEE 829

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

Я вот в этом не уверен. Всё зависит от того, для кого описание предназначено.

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

Но я не гарантирую, что это моё окончательное мнение.

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

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

Ситуация:
Тестовый случай - создание счета на поставку по схеме А
Если написать просто: выберите клиента 1, создайте счет на поставку по схеме А. Результат счет создан.

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

Однако в случае отсутствия конкретики - всегда есть возможность выполнить тест иначе (особенно если способов несколько).

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

Андрей, рекомендую посмотреть:
http://www.protesting.ru/testing/plan.html
там же два шаблона тестового плана: RUP и IEEE 829

Спасибо за ссылку и за помощь.
Разработал тест-план и тест-кейсы.
Отдал результаты.
В ответ тишина.

Пользуется кто результатами я не знаю.

Разработал тест-план и тест-кейсы.
Отдал результаты.
В ответ тишина.
Пользуется кто результатами я не знаю.

Вообще у меня отчет по результатм генерируется автоматически ежедневно по трем стендам
Всего тестов уже более 200
ПМ меня ежедневно опрашивает по результатам, частенько ругает, никогда не хвалит, много требует

Сейчас прихожу к выводу, что мне нужна система для управления тест-кейсами, присматриваюсь к testlink

А вот как протестировать веб-сайт?...
Как тестировать такие вещи?

1. Проблема тестирования - проблема разрботчика.
2. Ваша задача проверить соответствие разработке функциям в ТЗ, т.е. Вы сами должны ясно и четко представлять, а чего Вы хотели и действительно сумели донести это до разработчика.
3. Вы всегда сможете проверить работоспособность
  - а локально на некотором собственном стенде
  - б удаленно на хостинге, привлекая для этого кого-то
4. ВИ совокупность сценариев использования имеющих либо положительный либо отрицательный результат - так что по сути уже тест
5. Каждое требование, если оно сформулировано атомарно и однозначно проверяется на соответствие: как минимум тест на прохождение и тест исключения. Типа пароль должен быть не менее 6 символов. ВВодим 6 и более символов. Все ОК. ВВели 5 символов - появлется пердупреждение, страница обновляется. Если это проходит - гуд
6. Вы имеете право потребовать от разработчика (если такова была договоренность) предоставить Вам приемочный план тестирования и сами тесты

Я правильно поняла, что можно для начала записать все функции в виде ВИ (и прогонять их в процессе тестирования)?

Насколько я помню теорию тестирования, бывают разные типы тестирования. То, что приведено в цитате - функциональное тестирование.

Но есть такие вещи, которые к ВИ не относятся - типа какая-нибудь маленькая настройка, и их немало.

Еще бывает:

• тестирование интерфейса пользователя;
• тестирование локализации;
• тестирование скорости и надежности;
• тестирование безопасности;
• тестирование совместимости;
• и другие типы тестирования.

Думаю, стОит понять, какие виды тестирования вам необходимо провести и почитать про них что-нибудь интересненькое.

Сколько тут много всего интересного понаписано...
А вот как протестировать веб-сайт?...
Столкнулась с такой задачей.
Написала ТЗ, отдала разработчикам. Они там у себя как-то будут тестировать во время разработки, 2-й этап - тестирование на хостинге. Так вот как раз мне нужно придумать, что и как тестировать на хостинге (т.е. как мне проверить, что все, что они сделали, работает как надо).
Я правильно поняла, что можно для начала записать все функции в виде ВИ (и прогонять их в процессе тестирования)?
Но есть такие вещи, которые к ВИ не относятся - типа какая-нибудь маленькая настройка, и их немало.
Как тестировать такие вещи?

Даже больше, чем немало. Для веб-сайта тестирование производительности наверняка будет важнейшей составляющей.

Тестировщики, в основном, тусуются на форуме it4business.ru, можно там поискать.
Возможно, есть статьи на software-testing.ru