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

Мне кажется, расставлять надо не только приоритеты требованиям, но и оценивать риски (что может произойти, потери в случае наступления риска).
Таким образом, получаем 2 линейки:
1. Требования, упорядоченные по приоритету;
2. Риски, упорядоченные по стоимости.

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

Однако, если в процессе тестирования выявлены серьезные ошибки в рамках второй линейки, выпуск будет задержан во избежание потери лица фирмы. Либо у тестера будет бумажка о том, что он предупреждал...

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

Поднимая давно забытую форумчанами тему...
Я в таких случаях
1. требую максимально возможного времени на тестирование;
2. составляю представление о новой архитектуре, выявляю наиболее вероятные проблемные места;
3. тестирую:
3.1 проблемные места архитектуры с максимальной интенсивностью минимальное время, стараясь покрыть наибольшее число рисков;
3.2 основной функционал тщательно.

Обоснование:
При срочном переходе на новую архитектуру очень вероятны ее недоработки.
Пока программисты дорабатывают архитектуру можно заняться тестированием основного функционала.

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

Что нужно сделать, чтобы присоединиться?

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

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