Можно я тоже выскажусь.
Сейчас в компании, в которой я работаю, я как раз отвечаю за это самое тестирование.
До этого момента тестирование носило хаотический характер, процедур тестирования не было. Каждый аналитик в меру своего понимания предметной области и того, что и как надо проверять, гонял систему, ведя или нет при этом записи.
Такой процесс не дает никакой реальной пользы. Почему?
1. выявить все ошибки не возможно
2. человек даже самый аккуратный не в силах методично и систематически проверять систему (тем более без всякого плана)
3. просто физически аналитик не в состоянии прогнать даже все тесты, которые у него сидять в голове, а следовательно его выводам мало доверия
Простой пример: у меня сейчас сделано не так много тестов, но некоторые направления более или менее покрыты. Например нужно посмотреть работает биллинг или нет. Как обычно поступает аналитик(он же по совместительству тестер). Запускает билинг, выбирает каких-то двух трех клиентов и смотри - о все окей.
Как я поступил - во-первых я выбрал 50 разных клиентов (т.е. с разными начальными условиями). Я написал ОДНУ процедуру проверки и запустил ВСЕХ 50 клиентов на проверку. Из них 10 клиентов не прошли.Причем как выяснилось проблема не в алгоритме биллинга, а некоторых предварительных действиях. Вот этих 10 клиентов при старом подходе мы бы пропустили, а так удалось найти ошибки совершенно другого характера.
Чтобы написать такую процедуру, мы должны понимать, что будем тестировать. Обычно тестируют на соответствие требований. Было бы замечательно, если аналитк писал требование и способ как его проверять. Но ... аналитик часто это упускает из виду, он смотрит на систему оптимистически. Тестер - пессимистически, потому он смотрит на требования критически. По требования, будь то ВИ - т.е. связанная цепочка действий, или единичное требований можно написать целый ворох тестовых случаев.
Тестовый случай - нечто единичное желательно, оно позволяет внимательно посмотреть и на качество разработки требований и на проектирование и реализацию.
Документированный тестовый случай, будет ли он автоматизирован или нет, это артефакт, который можно передать любому: например нанять студентов за невысокую плату, передать заказчкиу, чтобы он провел приемычные испытания. И согласен с Александром - правильно записанный тестовый случай - это и отличное средство обучения и написания технологических инструкций по использованию
Не знаю как в других системах, но в TestComplete есть так называемые сценарии ручного тестирования, которые можно просто понимать как мастера освоения работы с системой
Test Case & Test Analyst