grr~

Пункты 1 и 2 можно реализовать на SharePoint, хелпа для этого вполне достаточно.
Я пока-что заметил одно неудобство, встроеные алерты реализованы криво и что бы кого-то нотифицировать о задаче, придется самому писать письмо.

Это пока у вас одно неудобство, дальше больше. Зачем изобретать велосипед? Когда и так все написано: бесплатное, платное, такое, другое. Бери и пользуйся.
Все-таки трэкер - это совершенно отдельная вешь и реализовывать ее на таблицах ... Успех сомнителен.

Если отталкиватся от того что есть, можно использовать шарепоинт. Если есть возможность - ставить таск трекер.

...Не надо скрывать таски одних сотрудников от других....

Работал и при таких и при таких условиях, в обоих случаях есть плюсы и минусы.

Извините, но мне тоже не понятно какие есть плюсы в ситуации, когда таски скрыты от других участников рабочего процесса. Могли бы вы привести их?
Вопрос без подвоха, т.к. на самом деле интересно. Единственная ситуация, которую я придумал - когда в компании разрабатывается сверхсекретный продукт. В такой ситуации, вполне допускаю, что _все_ не дожны видеть чужие таски. Но, все-равно, те кто над этим секретным проектом работают, скорее всего должны знать, кто чем занимается в команде.

Скрывание тасков в ситуации со секретным проектом - это не плюс, обычно в таких проектах люди понимают степень ответственнтсти, тажке их ограничивают котнрактные обязательства. И при достаточном количестве мотивационных факторов на приватность тасков всем по большому счету просто плевать.

Из плюсов, могу отметить только два, все остальные могут появится только в определенных условиях:
+ Нет ориентира для других сотрудников в виде медленной\плохой работы
+ Меньшая вероятность утечки информации

Пункты 1 и 2 можно реализовать на SharePoint, хелпа для этого вполне достаточно.
Я пока-что заметил одно неудобство, встроеные алерты реализованы криво и что бы кого-то нотифицировать о задаче, придется самому писать письмо.

[Offtop]

...А еще не хочу, что бы сотрудники видели таски друг друга.

Имхо, подход в корне неправильный. Не надо скрывать таски одних сотрудников от других. Все должны быть одной командой. Может плохо закончиться, конфликтами, например.
Наоборот, каждый дожен видеть, что делают другие.

Работал и при таких и при таких условиях, в обоих случаях есть плюсы и минусы.
В моем проекте данные по таск трекингу доступны всем его участникам, кстати, неплохой мотивационный фактор для новичков - есть ориентир по перфомансу.

В принципе на ваш вопрос ответили, добавлю кое-какие наблюдения из своей практики:
1. Дебажная информация может присутствовать как в бинарнике откомпилированой программы, так и лежать отдельно в dbg файле.
2. У некоторых невнимательных разработчиков есть тенденция к неправильному дефайну кода, т.е. в релизную конфигурацию попадает код который должен идти в дебаг и наборот.

Дебаг информацию мы использовали для получения покрытия исходного кода тестами - Rational Coverage, для ловли утечек памяти - Rational Purify.
Все вышесказаное касается С++.

Сборки C# практически избавлены от такой разницы (Debug\Release), там заведует этим делом сборщик мусора. Хотя, попадаются иногда тоже интересные случаи.

Darkus, не могли бы вы поделится примерами?

Уважаемый, вы думаете, если задать вопрос больше чем в одной ветке, ответов будет больше?

Я насчитал как минимум еще 3 точно таких же поста.

Я бы сказал не уровень, а разница в подготовке и менталитете

Уровень. Именно уровень.

Отличия в уровнях подготовки не есть разница?
Уточню, разница не только в уровнях подготовки но и разница в менталитете между тестерами и разработчиками.

К теме: Процессы в нашей компании сходны с процессами который описал Mishelka, только экстраполируются на гораздо больший колектив.
В некоторых деталях процессы от отдела к отделу могут отличатся, но есть части процесса которые по Corporate Quality Manual установлены на уровне компании и наследуются каждым проектом. Тоже самое и с автоматизацией, в некоторых проектах она есть, в некоторых нету.
Автоматизация вводится только если есть выйгрыш от этой самой автоматизации, я лично считаю автоматизацию следующим логичным шагом после ручного тестирования, только вводить ее надо с умом.
А проблемы "я хочу быть разработчиком" почти не стоит, берут сразу людей с опытом, у которых есть желание совершенствоватся в области QA&QC.