По части поддержки тестов в актуальном состоянии, тут все очень зависит от степени детализации тестов.

Ну скажем так. Автоматизированные тесты поддерживаются в актуальном состоянии почти всегда (по крайней мере те наборы, которые работают в автоматической сборке или запускаются перед релизом). Бардак же с ручными заключается в том, что они редко (я бы сказал преступно редко) обновляются, иногда ручное тестирование сложного функционала (особенно регрессионное) проводится с салфеточкой с графом состояний вместо обновленного документа (бумажка идет потом на вторсырье, естественно) - и это плохо. Скорее всего неправильное планирование или/и нехватка людей.

А вопрос "Как правильно" имеет свой ответ в каждом случае. Очень многое зависит как от приложения, так и от степени детализации постановок задач/ТЗ, так и от численности проектной группы. Мы стараемся включить тестеров в работу как можно раньше, ТЗ не идет в работу, если по нему есть вопросы/замечания от тест-аналитиков и разработчиков (разумеется, одно ТЗ смотрит по одному представителю от тестеров и разработчиков).

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

atermath ,
Не совсем понял 2ую часть последнего ответа, но если выходить на выпуск работающего ПО каждую итерацию, то надо по максимому автоматизировать тестирование. Плюс если подготовить правильные тестовые данные, то можно автоматизировать и тестирование сложной ф-ти хотябы в части наиболее частно встречаемой.

atermath ,
Не совсем понял 2ую часть последнего ответа, но если выходить на выпуск работающего ПО каждую итерацию, то надо по максимому автоматизировать тестирование. Плюс если подготовить правильные тестовые данные, то можно автоматизировать и тестирование сложной ф-ти хотябы в части наиболее частно встречаемой.

Да, автоматизировать надо по максимуму, согласен. Но есть долго/сложно автоматизируемые вещи (автотесты еще и отладки требуют, ага - даже behavioural-testing), а тестировать надо уже сейчас: так что прикидываем все тестовые варианты на салфеточке, и вперед - ручками :-) Потом, конечно, автоматизируем (в зависимости от приоритета) но не все, что надо бы. Но это скорее вопрос зрелости процессов и наличия опыта.

Кстати, а почему на салфетке??? Может сразу писать в Вики?

Ну, самая малая степень детализации тест-сценария - чек-лист ;-)
А насчет графа на салфетке - для этого прекрасно подходят средства моделирования, ну или даже Visio. Т.е. рисуем там, а не на салфетке (это не так уж и долго), а потом храним со всем остальным.
А нехватка людей - это вечная проблема, приходится выкручиваться так, как получается... Но у вас все выглядит очень неплохо.

Кстати, а почему на салфетке??? Может сразу писать в Вики?

получается дольше, пробовали... Еще будем )

Ну, самая малая степень детализации тест-сценария - чек-лист ;-)
А насчет графа на салфетке - для этого прекрасно подходят средства моделирования, ну или даже Visio. Т.е. рисуем там, а не на салфетке (это не так уж и долго), а потом храним со всем остальным.

Visio по идеологическим причинам не используем (лицензии нет и не купят), в Dia это достаточно неприятно. Но это все больше отговорки :-)
 А вот по поводу чеклистов (их хранения как таковых) - это большой вопрос, иногда бывает очень проблематичным поддерживать все это хозяйство в актуальном виде. Так что частого их использования в текстовом виде мы отказались, но на одном проекте используем Fitnesse (на движке Fit с собственнымы расширениями на HtmlUnit), что по сути недалеко ушло от чеклистов.