Коллеги,

может показаться, что те, кто ратует за CDT - это прогрессивные ребята, а я - ретроград и тормоз прогресса.
Но я совсем и не против CDT. Я даже за него. И давно пользовался такими приемами. Вот только не знал, что они так называются.

Меня только одно интересует. Я сторонник логики и структурированного подхода (ну, вот такой я). Приемами (практиками) тестирования можно пользоваться любыми. Однако, в каком виде вы, ребята, представляете заказчику отчет о тестировании? В количестве протестированных функций? В % соотношении проверенного кода? В ощущениях? Или отчет тоже нужно отбросить (так же как и тест-план), как нечто устаревшее и не достойное высокого исскуства тестирования?

Коллеги,

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

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

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

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

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

Другими словами, context-driven testing - это очень просто. Прежде чем начать тестирование, следует спросить заказчика о том, что он считает наиболее важным в релизе и скорректировать тест-план в зависимости от полученного ответа.

Поэтому и возникло это "движение протеста", новая школа, которая стремится сбросить шелуху стандартов, привычных техник, метрик, инструментов, и вернуться к основам, к сути тестирования.

Леша,
это ты, пожалуй, загнул.


Согласно тому же Канеру CDT не является методологией и применим в рамках любого подхода тестирования. Так что о "новой школе" речь уж точно не идет. Да и против привычных техник он так же не выступает.

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP?

Это невозможно. Я думаю нельзя натянуть CDT на какую-то методологию, потому что методология это не контекст. Методология это то, что уже натянуто на контекст.

Теперь настала моя очередь "тыкать пальцем в книжку". В приводимых выше ссылках у Канера есть раздел, посвященный CDT для RUP и других методологий.

Нашли кого слушать! Консультантов, которые этим зарабатывают деньги.

Хм. А кого слушать? Вас что ли? :) Нет, действительно интересно, чье мнение может быть для вас авторитетно? Только чтобы это был не консультант и не придумавший свою школу\религию.

А хотя бы и меня.

Другими словами, context-driven testing - это очень просто. Прежде чем начать тестирование, следует спросить закзаичка о том, что он считает наиболее важным в релизе и скорректировать тест-план в зависимости от полученного ответа.

Сергей, читаем внимательно всё по вышеприведённым ссылкам :)

Это в точности соответствует подходу, который назван там context-aware: "... some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard provides implementation-level suggestions rather than prescriptions."

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

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP? Куда ж там тест-план делся?


Ребята,
вы иногда бываете такими наивными.

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

Давно известно - хочешь заработать больше других, придумай свою религию или школу.

Но,
прошу обратить внимание. Я не говорю, что это плохо! Просто это не настолько хорошо или координально, как это пытаются преподнести.

У меня был случай. Пришлось тестировать 4-е активных (по ним велась разработка) проекта одновременно. Это был просто кошмар. После месяца такой работы я был выжат как лимон. При этом не было большой уверенности в качестве тестирования. Практически везде удавалось проводить только smoke tests.

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

Черт кроется в деталях.

Коллеги, извините. Отвлекся.
Постараюсь ретроспективно изложить основные мысли по экономике качества ПО и тестирования, в частности.


Посыл 1-й. Единый центр качества повысит удовлетворенность клиента и обеспечит повторные продажи.

Центр качества - это хорошая маркетинговая вывеска, прием для повышения продаж. Она будет полезна для компании - разработчика программ или системному интегратору (для последних, из тех про кого я слышал или доводилось общаться, вопросы качества - это более чем актуальная проблема).

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

В этом нет особой необходимости. Достаточно нанять подготовленного специалиста, который будет говорить правильные слова в нужном месте. Заказчик ВСЕ РАВНО не увидит особых отличий между тем, как было и как стало (т.е. до того как были введены активности по тестированию). Это результат того, что системы ВСЕГДА имеют дефекты. И заказчики всегда будут недовольны. После начала работ по тестированию поводы для недовольства будут возникать реже. Но они все равно останутся, а это означает, что большой экономической выгоды от создания Центра качества не существует (возможно, это поможет в процессе продаж, но не более).

Во всяком случае, в такой постановке задачи.



Посыл 2-й. Служба качества удешевит разработку софта или АС.

Часто, для подтверждения этой мысли показывают диаграмму зависимости роста стоимости от фазы выявления дефекта. Чем позже, тем стоимость дефекта дороже. ВСЕ ПРАВИЛЬНО! Чем позже, тем дороже. Главный вопрос современности - кто за это платит? А платит за это ВСЕГДА клиент.
(В подавляющем большинстве случаев - все риски несет плательщик.)

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

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

Но проблема в том, что этот подход в реальной жизни не работает! Вы не можете (как студент перед экзаменом) выявить и исправить дефекты в программе за одну итерацию потому что в программах 99,9% дефектов - это скрытые дефекты. Пользователь программы имеет дело не с самим багом, а с его проявлением. В итоге, поиск, и в дальнейшем исправление дефектов - это эксперимент. Вначале мы делаем предположение, а затем проверяем реакцию системы на внешнее воздействие, постепенно сужая круг поиска. Мы действуем вслепую (или почти), что распыляет усилия и занимает массу времени работой не дающей результата (точнее сказать, экономического результата).

Какой из этого вывод? Для обеспечения контроля качества необходимы планомерные и равномерные усилия. Другими словами, если вы не тестировали систему на этапах ее создания, то вам уже ничто не поможет существенно улучшить ее качество.


Так в чем может заключаться экономическая привлекательность создания службы тестирования?
(Морально этические разглагольствования предлагаю не рассматривать).

Я вижу только один повод - удешевление системы на стадии поддержки. Поясню свою мысль.

Предположим мы продали программу компании и она ей пользуется. При этом она платит нам за поддержку (как правило, за поддержку платят от 5% до 15% от стоимости самой системы). Чтобы осуществлять обновление системы и исправление дефектов нам нужно содержать фактический клон проектной команды. Нужен как минимум один специалист, знающий систему и способный не испортить ее. Так же нужна вся инфраструктура по поддержанию разработческой и тестировочной версии системы. Чем масштабнее (крупнее) программа или система, тем большего внимания она требует. Зачастую необходимо содержать не одного программиста, а целый штат - бизнес-аналитиков, тестировщиков, специалиста по ДБ, да еще менеджера по управлению всем этим кагалом. В результате затраты по поддержке системы не сильно отличаются от затрат по ее созданию.

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


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

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

2. Создание единой службы тестирования позволяет распространить единую практику (и инфраструктуру) тестирования на все проекты.
Очень часто в компаниях складывается такая ситуация, что каждый проект делается так, как умеет менеджер проекта. Это не всегда самый оптимальный путь. Нужно консолидировать положительный опыт и распространить его среди сотрудников.

Если все тестировщики подчиняются одному руководителю, то "насадить" единую модель работы будет значительно легче. Так же легче будет проводить работу по улучшению процессов тестирования, собирать управленческую информацию и данные о состоянии проектов.

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

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

4. Эффект правды.
Когда руководство компании получает отчет от руководителя проекта о состоянии дел в проекте, то оно видит не всегда правдивую картину. Чаще всего представляется желаемое положение дел на проекте. Отчет тестировщика - это снимок реального положения дел. На его основе можно делать вывод об успехах или не успехах проекта.


Может быть есть еще что-то. Просто, пока в голову пришли только выше изложенные аргументы.

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

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

Чего нет
1. ясного понимания цели.

GalogenIt,

Вы сейчас пытаетесь найти ответы находясь внутри системы. Для того, что бы решить Вашу задачу необходимо "подняться" над проблемой.

Тестирование - это способ выявления дефектов. Оно не обеспечивает качество, оно только дает информацию для улучшения программы (в этом плане говорят, что тестирование это элемент обеспечения качества).

Проблемы могут быть нескольких типов:
1. Сделали не то, что хотел заказчик (не корректная постановка задачи)
2. Реализация расходится с поставленной задачей (сделали не то, что заказали)
3. Сделали не так, как это общепринято (не учли стандарты)
4. Сделали не так, как удобно
5. Исправили то, что было не правильно, но внесли новую ошибку
6. Все работало по отдельности, но когда собрали - что-то перестало работать
Каждый аспект контроля реализуется посредством своего типа проверок (видов тестирования).

То, чем Вы занимаетесь сейчас - это регрессионное тестирование (неоднократное повторение одних и тех же тестов). В результате прогона таких тестов Вы можете выявить только 5 и 6 типы проблем. Следовательно, Ваша основная задача на данном этапе - это проверка целостности билда (что он работает и в нем ничего не поломалось из старой функциональности). Другими словами, Вам нужно сформировать набор автотестов, которые вы будете выполнять каждый раз, когда будет готова новая версия (сборка) продукта.

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

Для повышения эффективности автотестов необходимо проанализировать риски попадания ошибок в старую функциональность. Исходя из рисков можно сформулировать подходы к выбору тест кейсов для автоматизации. Однозначно должны проверяться критические пути (бизнес-функции). Так же должны проверяться выявленные ранее критические ошибки (необходимо быть уверенным, что они не вернулись). Это только пример рассуждений.

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

Правда стоит сказать, что пока задача unit testing передо мною не стоит. Предполагается, что этим будет заниматься сам разработчик.

Вижу необходимость пояснений.

Я привел пример с unit testing именно потому, что это не тестировочная активность. Не хотел, что бы была прямая связь тестирования с примером, чтобы продемонстрировать проблему в целом и избежать "скатывания" на обсуждение плюсов и минусов частной практики.

У меня вопрос к специалистам, опытным инженерам качества ПО.

Спасибо за ответы...

2 galogenIt

Честно говоря, в Вашем посте нет вопросов. Точнее, те вопросы, которые Вы задали, не относятся к главной проблеме. Вы просто изложили ситуацию, а так же то, что уже принято решение об автоматизации. Причем, как я понял, автоматизация поручена Вам и Вы уже приступили к ее реализации.

Ну, что ж. Это тоже вариант. Однако Вы выбрали один из наиболее длинных путей - набивание шишек через свой опыт за счет своей компании.

Для решения проблем вашей компании необходимо понимать ряд вещей:

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

2. Повышение качества - это переход к сервисной структуре работ.
Качество возможно только если процесс станет типовым. Если каждый раз все делается по-новому, то и уровень качества будет не предсказуемым.

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

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


Как можно поступить в Вашей ситуации?

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

2. Отдать работы на аутсорсинг.
Быстро, но не очень дешево. Зато проблема решается сразу же и, к тому же, лично у Вас есть возможность взять этот процесс в свои руки и повысить квалификацию за счет опыта аутсорсеров.

3. Нанять консультанта и организовать работы "внутри".

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

>GREEN
>Честно говоря, в Вашем посте нет вопросов.
Да наверное. Пока я просто изложил ситуацию. И хотел бы набрать критическую массу информации скажем так из первых рук. Что в общем получается...

Приобретения опыта за счет фирмы - ну не совсем согласен. И я получу велью, но и фирма его получит.

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

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

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

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

Сорри за оф-топ.

Блин! И тоже вынужден отказаться по той же причине.
SQA - это хобби, а Интернет - это работа.

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

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

В связи с совпадением по датам с РИФ+КИБ вынужден отказаться от посещения конференции. Жаль.

Блин! И тоже вынужден отказаться по той же причине.
SQA - это хобби, а Интернет - это работа.

Up.

У меня тоже есть интерес.
Ваше резюме - как прелюдия к дальнейшему общению.
Для быстроты обработки можно выслать на segrin четвероногий друг gmail сами знаете что com.

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

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

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

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

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

Ни то и ни другое.
Временно заморожен.
Но разморозка зреет.

А можно его разморозить?
Конкретно сейчас интересует перевод глоссария. Старые ссылки не работают (http://spreadsheets....w...F3yLA&gid=1), а копии глоссария у меня нет.
И именно сейчас она мне понадобилась.
Хорошо бы просто бросить личное сообщение с Excel файлом, если можно.

Хотя наверно есть/будут еще желающие, так что открытая публикация на Google Docs им понадобится.

Сейчас пошел посмотреть и оказалось, что действительно убрали такую фичу в Докс, как расшаривание табличных файлов. Блин! А было так удобно.
Если кому надо, могу выслать полуфабрикат pdf файлов (импорт в экселовский формат почему-то тоже не сработал).

Green, а что с переводом глоссария ISTQB получилось? Проект заглох или закончился?

PS
Прошу прощения, если просто пропустил какое-то знаковое мгновение.

Ни то и ни другое.
Временно заморожен.
Но разморозка зреет.

есть ли у вас план товарищ Alfa? :)

Не понял. Какой план имеется ввиду?

план как закончить данный процесс с нужным результатом, правда вопрос скорее всего к Green

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

Ни от кого ответа пока не получил.
Либо все заняты, либо...

Да, получилось экселевским файлом сделать.
Вышлю.

Только слишком сырой пока словарик.
Будем доделывать!

Ищу альтернативу гуловским докам.
Посмотрю на майкрософт.

Кстати, это не работает фича по публикации для коллективного доступа.
Но фича по расшариванию и коллективной работе над документом - работает.

Просто для доступа нужен Гугловский экаунт.

Механизм прост:
1. Заходите в гугловский экаунт или в почтовик Gmail.
2. Слева вверху есть ряд линков - жмете на Documents
- открываются Гугл Докс и вы там видите нужный файл и полным доступом на редактирование.

Кто подписывался на файл с НЕ гугловского ящика, можете выслать мне гугловский - я расшарю для вас документ по новой.

P.S.
В личных сообщениях форума не нашел фичу по добавлению файла в сообщение.

Коллеги,

два сообщения.

1. Выложил таблицу на майкрософтовский сервис. Всем участникам разослал сообщение и открыл доступ.
Что понравилось - наличие версионности и прямой доступ в файловое хранилище через проводник.

2. Я решил не раздавать всем желающим не законченный перевод.
Давайте закончим работу!

Время на написание "шапки" поста очевидно потрачено зря.

Ничего не бывает зря! Просто иногда мы не можем интерпретировать результат.


Роман,

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

Например,
"Количество «псевдо-исправлений» (Re-open после Fixed) – количество багов"

Описание метрики: Тестировщик во время проверки новой версии продукта (релиза), при проверке дефекта, имеющего статус "исправленный", выявил, что дефект не исправлен. Он переоткрывает дефект со статусом "re-open".

Получатель метрики: руководитель проекта

Интерпретация: наличие дефекта со статусом re-open означает, что разработчик, назначенный на исправление дефекта,
а. либо не исправил дефект, но при этом поставил статус исправлено,
б. либо код с исправленным дефектом не попал в выпущенную версию программы.

Критерий: Следует принимать меры в случае, если
а. дефекты данного типа превышают 3 в новой версии продукта;
б. если дефекты со статусом "re-open" проявляются у одного и того же разработчика на протяжении двух релизов подряд.

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

Например
Если разработчик допустил дефекты со статусом "re-open" на протяжении трех релизов, то руководитель проекта должен подойти к нему и "дать по голове", что бы "вправить мозги на место".

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

Вот только после этого у вас появиться инструмент в виде системы метрик, который ВОЗМОЖНО будет работать. Но если он будет "пробуксовывать" в применении некоторых показателей, то, во всяком случае, можно будет понять что и где не работает.

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

2 Roman,

Алексей (LeshaL) написал ключевую фразу всего поста.

Метрики по конкретному проекту не могут помочь в повышении уровня качества другого проекта напрямую.

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


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

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

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


Вывод

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

2. За счет классификации и группировки проблем (с целью их измерить) можно выявлять типовые инциденты (часто повторяющиеся). Для устранения причин таких проблем необходимы дополнительные действия - внесение коррективов в процессы.
* Если нет формализованных процессов, то и смысла в финальных метриках нет.


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

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

...
Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования ...

Team System Developer Center имеет блок по автоматизации тестирования (функционального и нагрузочного) - Test Edition.
http://msdn.microsof...m/dd408381.aspx