xska

Встретил тут на одном замечательном ресурсе нечто подобное:

There were a total of 2 QA guys let go due to this project, both managers.  The first was let go because he knew the system wasn't ready and refused to sign off on it.  The second was let go as the scapegoat; he came in, they told him to sign off, he signed off, it failed, they blamed him.

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

Встречались ли вы с подобными ситуациями, и если да - то как с ними боролись? Или более конкретно:

Как боролись с:
1) Оказанием давления на команду тестировщиков - особенно с попытками заставить принять заведомо нетестируемые, неполные и ошибочные требования
2) Тенденцией сваливать все обнаруженные в стадии post-production ошибки на "недотестировали" (т.е. на команду тестировщиков)
3) и более общее, с политическими играми в цепочке отделов управления, разработки и тестирования (project management, development and testing/QA)

Кто чем пользуется для управления требованиями (requirements management)?
Особенно хотелось бы узнать плюсы и минусы следующих двух систем:
1. Mercury QualityCenter
2. Rational RequisitePro

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

Есть ли на этот счет другие мнения?
Насколько вообще оправдано время, вложенное в обработку requirements?

Просмотрев около 30 вакансий на позицию тестировщик (старший, простой, QA lead, и т.д.), обнаружил, что в большинстве - требование высшего образования!

В связи с этим вопрос - есть ли какие-либо объективные причины такого требования? Ведь в ВУЗах тестированию не обучают.