Тогда уж лучше присоединиться к существующему opensource проекту. Например TestLink или Testopia.
"Не умножайте сущности без необходимости" (с) Вильям Оккама

Редкий диплом не "умножает сущности без нужды", это личный опыт ;)
Но при этом один из разделов диплома должен содержать обоснование вида "почему я решил изобрести велосипед вместо покупки готового изделия".

Например: "Автоматизированная система контроля и учета работы отдела тестирования на базе WEB-технологий". И вот "некая БД", куда неким "залогинившимся" тим лидом заносятся тест-кейсы с назначением выполнения оных некоторой "группе" тестировщиков и "залогинившиеся" тестировщики, получающие из "некой БД" тест-кейсы и ставящие через "интерфейс" отметки о выполнении. Также можно прикрутить туда модули взаимодействия с хранилищем документов типа VSS и системой баг-трекинга типа VI. В принципе, система достаточно забавна и более-менее нова. Для диплома более, чем достаточна, на мой взгляд.

На все случаи жизни совета тут дать явно не получится. Критерии оценки "годности" билда каждым отделом тестирования выделяются свои, причем, основанные на оценке рисков, как правильно заметил rlabs. К примеру, даже с блокирующим багом, на котором приложение периодически валится с несохранением данных и стоит такой обвал, к примеру, 1000 долларов, своевременное вхождение на рынок этого ПО может принести более миллиона этих самых вечнозеленых. И продактить/нет такой билд уже решается не только тестировщиками, как я думаю. К примеру, имеет смысл субъективно расчиывать для каждого бага величину "потенциального ущерба" (Х), основанную на субъективных факторах ("раздражающей способности" для багов в ГИП, к примеру) и создать примерную шкалу этой величины (0-10). Далее - уровень самих багов (Y), от Low (1) до Urgent (5). Результирующий вес считать как Sum (X*Y). При этом вес даже Low - бага с ужасающим "раздражителем" может быть больше веса бага высокого приоритета, повторяющегося эпизодически и потенциально менее опасного.

Повторюсь, такая оценка будет субъективной, но более адекватной, нежели просто ранжировать по уровню приоритета инцидентов.

Странно, что такой крупный западный банк имеет в HR-отделе контактную почту от bk.ru.

Ничего личного, просто вызвало удивление.

Glofiish X500 и FS LOOX 420. Использую крайне активно. С момента покупки фиши месяц назад дотестировал его до трех гарантийных обращений-)

...

Попробуйте Parasoft С++Test

Имеющаяся у меня версия 6.5 диаграмм и графиков строить, к сожалению, не умеет. Второй вопрос, вдогонку. Есть ли аналог IDA Pro для C++?

Вкратце мысль такова:

Имеются роботы, написанные под конкретные задачи(например, нагрузочное тестирование и критические секции регрессов), имеется тестирование черного ящика. Модульным тестированием по идее должен заниматься другой отдел. Но так как особого доверия к другому отделу тестировщиков не испытывается (тестировщик вообще существо недоверчивое -) ), то хотелось бы совета в вопросе выбора тулзы, которая занимается анализом кода модуля/класса/приложения с возможностью построения графа условных переходов, классовых взаимодействий и/или других диаграмм(графиков) примерно такой же направленности для визуального обнаружения критических секций внутри кода. Естественно, что отбирать критические секции буду сам, глядя на результаты анализа. Язык - C++. Также не откажусь от мнений по удобству использования и перечисления используемых средств автоматизации модульного тестирования приложений. Тестирование GUI клиентов не автоматизируется, ибо контролы нестандартные и средствами автоматизации не цепляются, только сервера.