С пониманием целей вопросов нет.
И свои идеи по необходимым метрикам есть.

Просто хочется посмотреть на готовые велосипеды :-)

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

А если серьезно, то вам не поможет рецепт, взятый от другой компании. Там свои условия, свои процессы, свои головы и свои заморочки. Если уже вас интересует чужой опыт, то лучше всего привести свои метрики и свои рассуждения (как вы планируете пользоваться данной метрикой и чем именно она будет полезна). Тогда вы получите ответы тех, кто уже наступил на грабли и получил положительный опыт. Без конкретики - разговор абстрактен и польза от него абстрактна.

То, что вы наработали и продумали - характеристика зрелости вашего проекта / компании. Это означает, что есть основа для применения. Есть согласованность в понимании и в желании применять в повседневной работе. Все остальное - от лукавого и для вас не только не подойдет, но и будет вредно, так как попытка применить не свое решение приведет к потере времени, денег и положительного настроя.

Коллеги!

Всегда должна быть цель!

Какая цель у вашего пост-мортен митинга?
Что вы хотите получить по итогам митинга?
Кто именно будет являться потребителем метрик?
Вот получит этот чувак несколько показателей и что дальше?

Думаю, если ответите на эти вопросы, то сможете сами для себя сформулировать, как требования к самой системе, так и определить метрики, которые нужно собирать.

Тестирование - это специфичная деятельность. Она может поглотить любой объем выделенного времени и его окажется недостаточным.

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

Если говорить о более научном подходе, то существуют методики оценки трудозатрат на программирование. Их общая логика сводится к следующему. Делается ревью всей функциональности и она условно делится на 3 (в разных методиках по разному) категории: легкая, средняя и сложная. Каждая категория имеет свой вес в человеко -часах (разные методики различают разные коэффициенты, они могут быть выделены для конкретной технологии, отрасли промышленности и т.п.). Дополнительно применяется поправочный коэффициент для конкретной компании, полученный на основании анализа статистики по большому числу проектов. Потом все перемножается и выводится приблизительная оценка трудозатрат на реализацию каждой функции. Сумма затрат по каждой функции = трудозатраты по проекту.

Некоторые методики включают в себя общий коэффициент затраты на тестирование, некоторые - нет. Введите свой коэффициент и вычисляйте затраты на тестирование.

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

Но выплата высокой зарплаты не является мотиватором в долгосрочной перспективе.

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

Однозначно, зарплата должна быть на уровне "рынка". И изменяться она должна на уровне рыночных трендов. Тогда работодатель будет "как большинство". И что дальше? Что дальше, если все вокруг такие же? Именно поэтому, зарплата не является стимулятором производительности в долгосрочной перспективе. Помимо этого, подавляющее большинство людей считают, что им никогда не платят столько, сколько они заслуживают.

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

Я бы определил следующие мотивирующие факторы, помимо денег:

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

2. Сложность (комплексность, новизна) и, как следствие, интересность задач. Без предыдущего пункта это, как правило, является демотивирующим фактором.

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

4. Перспективы роста по служебной лестнице. Как ни крути, а более громкое название позиции всегда являлось очень сильным стимулом. Я как-то читал про результаты опроса менеджеров в США. Более половины опрошенных отметило, что они предпочли бы более "громкую" должность против повышения зарплаты. Социальный статус человека в обществе никто не отменял и более высокое положение на работе подразумевает более высокий статус в обществе.

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

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

Я не совсем понял, что значит "...при этом не загружая страницы...". Но вариант решения может быть таким:
1. Пишите скрипт, который "пробегает" по коду каждого файла-страницы (это ведь текстовый файл) и собирает линки в массив (либо записывает в файл). Если линки не текстовые, то скрипт может "вытягивать" их из базы или формировать по заданному алгоритму.
2. После этого другой скрипт берет по одному линку из массива, формирует и отправляет запрос к серверу. При этом запрос к серверу может быть сформирован таким образом, что бы не загружать весь код, а только проверить наличие страницы. Ответ от сервера покажет - жива ли страница.
3. Формируете отчет со списком линков и кодом ответа сервера.

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

Жизнеспособна ли такая схема:

Клиент создаёт запрос через вебинтерфейс
Запрос вешается на ответственного
2 случая:
1) Ответственный понимает, что вопрос лажовый - просто юзер что-то не понял. Объясняет ему и закрывает запрос
2)
- Ответственный сам разобраться не может. Перенаправляет запрос на тестировщиков. Помечает в хелпдеске, что запрос в работе
- Тестировщики проверяют, имеет ли баг место. Заносят в трекер
- Баг планово (уже зависит от менеджера проекта) исправляется
- В трекере фиксится. Проверяется. Выпускается очередная версия
- В хелпдеске запрос закрывается

Реально ли такая схема будет работать? Или есть более оптимальные варианты?
Спасибо

Будет.

Есть только два момента.
1. На входе хелп-деска у вас будут не только баги. Необходимо предусмотреть механизм "раскидывания" входных запросов по типу запроса.
2. Если у вас на входе баг, а в системе работает N пользователей, то высока вероятность, что вы получите N совершенно не формализованных, написанных с разным уровнем качества претензий, но имеющих ввиду один и тот же баг. Если вы вывалите все это на тестера, то он у вас уволится раньше, чем дочитает их все до конца. Необходимо подумать, кто, как и на каком основании будет принимать решение, что все последующие входные сообщения - это дубль уже полученного бага.

Как следствие второго вопроса, вам нужно быть уверенным, что все N дублирующих сообщений устранены. Для этого на входе нужно регистрировать ВСЕ сообщения и только первое отсылать тестировщику (или кому-то другому). Но при устранении дефекта и закрытии его в баг тркинге, необходимо закрыть и все остальные связанные с этим дефектом претензии. Так что нужна вторая система по учету входящих запросов. Это может быть и баг трекинговая система, но баги, как я написал выше, - это не единственный тип входной инфо на хелп деск.

Упссс...
Дублирование предыдущего сообщения.

Примечание: Узел графа потока управления представляет из себя простой блок.

Роман, спасибо.
Исправил.

Wide Band Delphi

Я ЗА

Кстати, только сейчас заметил, что в определении есть слово test. :-(
Получилось следующее:

"Экспертная техника оценки, целью которой является получение более точного значения трудозатрат на тестирование исходя из совокупного опыта членов команды."

Как то раньше не сталкивался с этим понятием, так что до конца не уверен, что правильно его понял.

Сергей ты упорно пишешь программа я же все таки считаю что правильнее программный продукт

Честно говоря, даже не задумывался. Но сейчас действительно возник вопрос.
Есть три варианта (больше пока не пришло в голову):
1. программа
2. программный продукт
3. программное обеспечение

Есть ли в их толковании существенная разница, которую стоит специально отражать в наших переводах?