Сообщений в теме: 19

[galogenIt]

Коллеги, кто какими метриками в тестировании пользуется, как их рассчитывает? Можете поделиться? Спасибо

Такой вопрос я задал на facebook в Интернациональном клубе тестировщиков, но формат обмена мнений в facebook, видимо, не очень удобен для подобной дискуссии. Я ее там начал, но потом перевел сюда. Кому небезынтересно, предлагаю продолжить ...

Наверное, имеет смысл добавить. Предлагаю желающим высказаться, предложить те или иные метрики. Я постараюсь все это собрать и опубликовать в блоге (вот сочинил себе блог:) http://insectfinder.blogspot.com)

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

Работы в системе управления работами имеют флаги: Проект, Направление деятельности, Тип работы, Приоритетность + есть еще принятые шаблоны сообщений, позволяющие облегчить контекстный поиск.

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

[galogenIt]

Алексей Лянгузов Кстати, если вы тестируете на пользователях, то вот бодрый и интересный долад, который может заинтересовать http://www.addconf.r...omanYuferev/321
Про manageability. понятно - готового решения там нет, но есть интересные идеи.

Спасибо, правда, тестируете на пользователях - это тайна :)

[LeshaL]

Алексей Лянгузов Кстати, если вы тестируете на пользователях, то вот бодрый и интересный долад, который может заинтересовать http://www.addconf.r...omanYuferev/321
Про manageability. понятно - готового решения там нет, но есть интересные идеи.

Спасибо, правда, тестируете на пользователях - это тайна :)

Почему-то ссылка неправильно вставилась, уж не знаю что не так - но вот рабочая.http://www.addconf.r...omanYuferev/321

[yagor]

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

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

Придумали четыре метрики:

Вспомогательное определение:
Итерация – абстрактная единица, под которой понимается некоторый отрезок времени, в течение которого выполнялся один раунд тестирования. (Более точного определения пока не сформулировали.)

Метрика: Доля повторно открытых дефектов.
Повторно открытые дефекты = заново открытые / открытые в первый раз (на одной итерации тестирования)

Ограничение: Не считаем дефекты, критичность которых ниже чем «незначит.» это в «мантисе»: миним.; текст; тривиа; дополн.

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

Метрика: Убойность тестов
Убойность тестов = число дефектов*100 / число тестов.

Определение: Убойность тестов – это количество дефектов на 100 тестов
Определение. Число дефектов – все дефекты, которые были найдены по шагам из тестов на данной итерации тестирования.
Определение. Число тестов – все тесты, которые были пройдены за итерацию.
Ограничение: Не считаем дефекты критичность которых ниже чем «незначит.» это в «мантисе»: миним.; текст; тривиа; дополн..

Обоснование: Эта метрика косвенно отображает качество нашей работы, или работы программистов.

Метрика: Число дефектов найденных вне теста. (антиубойность) (тут мы маленько отожгли)
Число дефектов найденных вне теста = число дефектов, найденных вне тестов*100 / число тестов
Требует введение следующего Правила:
«Нельзя приписывать тесту найденный дефект, если шаги для воспроизведения этого дефекта отличаются больше чем на 30% от шагов, описанных в тесте».
Примечание: Понятно, что правило субъективно, но думаю, со временем, если метрика приживется, то у нас появятся набор фильтров, которые помогут выделять эти дефекты.
.... (ограничения и определения пропускаю)
Обоснование: Эта метрика напрямую отображает недостатки методики (тестов). Идеальным было бы, чтобы все баги находились при прохождении шагов по тесту.

Метрика: Эффективность тестирования
Эффективность тестирования = число дефектов/трудозатраты (чел/ч).
Определение. Эффективность тестирования – это число дефектов, найденных за один час одним человеком.

Обоснование: Эта метрика отображает эффективность использования ресурсов

Метрики хранились в Access базе было написано приложение в котором тестировщики вовремя или по завершению тестирования вносили данные приложение само раскидывала числа по табличкам.

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

[galogenIt]

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

Спасибо. Очень познавательный пост. Итог, надо сказать, меня не удивил, ждал что-то подобное. Может из Вашего стиля :)
Не кажется ли Вам, что дело не только в нехватке ресурсов, а скорее сложности подсчетов и то, что все делается вручную? Т.е. статистика не накапливается, а ее приходится потом вводить?

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

Отчет выглядит примерно так:
ID теста Укороченное описание ошибки (выбирается из лога) Дата Статус Причина падения Примечание
Статус - это критично некритично
Причина падения - ошибка тестируемого объекта, ошибка прогона (сбой), ошибка в тестовой процедуре, изменение интерфейса или вообще изменения в тестируемой программе
Примечание - обычно указывает номер работ и ее состояние в системе управления работами

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

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

[SALar]

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

Плохая цель. Чаще всего проекты с плохой целью терпят крах. Так получилось и у вас.

[yagor]

Не кажется ли Вам, что дело не только в нехватке ресурсов, а скорее сложности подсчетов и то, что все делается вручную? Т.е. статистика не накапливается, а ее приходится потом вводить?

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

Т.е. я хотел сказать нехватка ресурсов не на работу с системой, а не ее постоянную доработку.

Плохая цель. Чаще всего проекты с плохой целью терпят крах. Так получилось и у вас.

Похоже так оно и было. Ну опыт он как говориться "сын ошибок" (конечно лучше когда чужих).

[elfische]

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

Плохая цель. Чаще всего проекты с плохой целью терпят крах. Так получилось и у вас.

Скажите, пожалуйста, почему плохая. А какая, например, будет хорошей?

[SALar]

Скажите, пожалуйста, почему плохая. А какая, например, будет хорошей?

...
Цель контроля тестирования состоит в получении обратной связи и визуализации процесса тестирования.

Классическая ошибка целеполагания. В качестве цели стоит средство. Классика из классик. Процентов 90 целей проектов именно так и пишутся. И в итог е мы имеем то что имеем.

--
Применяем первую мантру:
Как вы узнаете, что проект успешен?
Визуализация появится? Ух ты. А что это? И, главное, зачем? В какое место вы эту визуализацию собираетесь засовывать?

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

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

PS. Это не совсем правда. Но это правда о том, что цель очень плохая.

[Natalya Rukol]

Мне очень нравится ТОС, модель Голдберга. В числе прочего он утверждает, что всегда, везде, в одну единицу времени в вашем процессе есть одно наиболее слабое звено. Которое и надо исправлять в первую очередь, не отвлекаясь на остальное. В добавление к ТОС, Kaizen проповедует "визуальный менеджмент": возможность видеть, действительно видеть, и не прятать, все проблемы. Смело о них говорить, обсуждать, и благодаря этому иметь возможность их решить.

К чему я это? К тому, что метрики должны иметь своей целью УЛУЧШЕНИЕ процесса. Для этого надо знать КРИТЕРИИ УСПЕШНОСТИ этого самого процесса. После чего необходимо заполучить инструменты, позволяющие выяснить ПРИЧИНУ проблем, чтобы работать с их корнями.

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

Моё ИМХО: сначала надо проводить грамотные пост мортемы, обсуждать, выяснять, с какими проблемами столкнулись. Анализировать их: как они повредили, как вы можете оценить масштабы их вреда и т.д. Благодаря пост мортемам можно:

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

В принципе, подход "давайте пособираем всякие разные метрики, а по результатам решим, какие из них приносят пользу", тоже имеет право на существование, но определять их по результатам Post Mortem эффективнее.

[elfische]

В качестве цели стоит средство.

Эта фраза объяснила всё, спасибо.

[galogenIt]

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

Да, наш разговор о метриках привратился в философский вопрос: Don't ask me ask God. Не пойму почему бы просто не рассказать о метриках и способах их сбора и использования. Как это сделал yagor. Можно будет решить имеет смысл и нам делать также или нет. Просто это выглядет примерно так. Я спрашиваю: коллеги а как вы решаете квадратное уравнение, а мне в ответ: а зачем вы его хотите решать?

[Natalya Rukol]

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

:)
НаталЬя!
Post Mortem - это процесс анализа результатов проекта. Когда все участники садятся вместе за чашечкой чая и обсуждают: что было хорошо, что было плохо. Пост-фактум многие вещи видны значительно лучше, чем в процессе. И делается это с вполне понятной целью: всё хорошее закрепить и сохранить, всё плохое решить и больше не допускать.


Я могу рассказать о метриках, которые были мне когда-либо полезны, но я боюсь подмены понятий, о которой говорит Salar.

- Петька, приборы!
- 200!
- Что "двести"?
- А что "приборы"?

У проекта есть цель, или цели. Её достижение - единственная прямая метрика результативности. Но упс! Её невозможно собирать ДО завершения проекта, а ПОСЛЕ уже невозможно что-то поменять. Получается, метрики нужны, они помогают влиять на результат, корректировать действия, но они всегда являются косвенным показателем. Чтобы понять косвенные показатели, нужно знать конечные. Какие критерии успешности у Вашего проекта?

Вы можете "измерять" статус продукта: открытые баги / KLOC, открытые баги / разработчик, % реализованных требований, % реализованного функционала с учётом веса, tests pass rate и tests fail rate (желательно с учётом приоритетов) и т.д.
Можете "измерять" статус тестирования: % покрытия функционала тестами и/или автотестами, % багов, найденных после выпуска, средний срок жизни дефекта, срок нахождения критичных дефектов (в баг-трекере проставлять не только сборку обнаружения, но и при фиксе - выявленную сборку "внесения", мне эта метрика почти всегда была полезной), собирать субъективные оценки по анкетам, % reject'ов, % дополнительно запрошенных данных по багам, $/bug, % покрытия окружений и т.д. и т.д.

НО я бы не делала ничего из этого до выявления двух факторов:
- Цели вашего проекта. Измеримые и всем понятные. Поверьте, если участники вашего проекта будут одинаково понимать цели, это поможет в сто раз лучше любых метрик!
- Выявление всеми участниками процесса "слабого звена", чтобы не акцентироваться на том, что и так никого не тормозит. Проблемы с дефектами? Анализируем их. Проблемы с пропусками багов? Анализируем их. И уже на основании этих пунктов действуем, выявляем метрики.

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

[elfische]

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

Сборка "внесения"? Это что такое? Внесения чего? Единственное, с чем могу соотнести из собственной практики, поле "Исправлено в сборке", но формулировка намекает, что это не оно.

[Natalya Rukol]

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

Сборка "внесения"? Это что такое? Внесения чего? Единственное, с чем могу соотнести из собственной практики, поле "Исправлено в сборке", но формулировка намекает, что это не оно.

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

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

[galogenIt]

НаталЬя!

Извините, Наталья. Можете за это меня несколько раз назвать каким-то Этуартом :)

Спасибо за интерес к теме и подробные ответы-советы.

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

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

Какие критерии успешности у Вашего проекта?

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

Вы можете "измерять" статус продукта: открытые баги / KLOC, открытые баги / разработчик, % реализованных требований, % реализованного функционала с учётом веса, tests pass rate и tests fail rate (желательно с учётом приоритетов) и т.д.
Можете "измерять" статус тестирования: % покрытия функционала тестами и/или автотестами, % багов, найденных после выпуска, средний срок жизни дефекта, срок нахождения критичных дефектов (в баг-трекере проставлять не только сборку обнаружения, но и при фиксе - выявленную сборку "внесения", мне эта метрика почти всегда была полезной), собирать субъективные оценки по анкетам, % reject'ов, % дополнительно запрошенных данных по багам, $/bug, % покрытия окружений и т.д. и т.д.

Спасибо, правда я не понял, поскольку не знаю, что такое:
- % реализованного функционала с учётом веса, что вкладывается здесь в понятие функционал и чем он отличается от требования.
- tests pass rate и tests fail rate (желательно с учётом приоритетов) - доля прошедших и доля упавших тестов? Приоритет - критичность для тестируемой системы?
- % багов, найденных после выпуска, что является основанием? Общее количество багов в релизе? А как его замерить? Когда начинать измерять основание? % найденный после выпуска - вроде понятно, а вот процент к чему нет.
- средний срок жизни дефекта - что это означает? средний срок устранения дефекта? Если да, то тут думаю дефекты тоже имеет смысл разделять иначе данная статистика как средняя температура по больнице.
- срок нахождения критичных дефектов - где? в каком состоянии? или это примерно тоже , что и средних срок пребывания заявки в системе (в системах массового обслуживания?) правда я не очень понимаю, какое это отношение имеет к тестированию, это скорее к дисциплине разработки и устранения ошибок.
- собирать субъективные оценки по анкетам, поясните, пожалуйста, что Вы имеете в виду.

НО я бы не делала ничего из этого до выявления двух факторов:
- Цели вашего проекта. Измеримые и всем понятные. Поверьте, если участники вашего проекта будут одинаково понимать цели, это поможет в сто раз лучше любых метрик!
- Выявление всеми участниками процесса "слабого звена", чтобы не акцентироваться на том, что и так никого не тормозит. Проблемы с дефектами? Анализируем их. Проблемы с пропусками багов? Анализируем их. И уже на основании этих пунктов действуем, выявляем метрики.

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

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

Да, я не сержусь :) Я ну скорее недоумеваю. Я еще ничего не начал собирать (в смысле никаких метрик), я пока обогащаюсь идеями этих метрик. Поймите, да наверняка, можно засесть за книги, статьи, блоги. Таким образом составить для себя некоторый список метрик, способов их измерения и использования. Потом через анализ или методом проб и ошибок, понять, что это подходит, это не подходит. Раньше это был бы, пожалуй, единственный способ получения знания. Но сейчас есть же такие прекрасные возможности :)
Уже кое-что для себя понял, куда как быстрее, чем от простого прочтения :)

[Natalya Rukol]

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

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

Что-то мне подсказывает, что выпуск очередного релиза и есть проект

Какие критерии успешности у Вашего проекта?

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

Вы сейчас говорите о тестировании "вообще", сферическом коне в вакууме, или учитываете специфику своего проекта? Рыночную ситуацию, ожидания руководства от релиза, предыдущие выпуски?

- % реализованного функционала с учётом веса, что вкладывается здесь в понятие функционал и чем он отличается от требования.

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

- tests pass rate и tests fail rate (желательно с учётом приоритетов) - доля прошедших и доля упавших тестов? Приоритет - критичность для тестируемой системы?

Доля прошедших и упавших. Понимаю, что здесь спрашивать проще, но гугл ответит на такие вопросы легко ;) А что такое для Вас приоритет - можете ответить только Вы!

- % багов, найденных после выпуска, что является основанием? Общее количество багов в релизе? А как его замерить? Когда начинать измерять основание? % найденный после выпуска - вроде понятно, а вот процент к чему нет.

Если после выпуска продукта клиенты нашли неизвестных 50 багов - это много или мало?
А теперь по-другому спрошу: если мы выпустили продукт с 3000 известных открытых багов, а пользователи нашли 50 новых - это много или мало?
Или нет :) Мы выпустили продукт с 30 известными дефектами, а пользователи нашли 50 новых - это много или мало?

Количество найденных пользователями дефектов само по себе не так интересно, как в сравнении с известным изначально количеством.

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

Средний срок исправления, да. Как предлагаете разделять? По приоритетам?

- собирать субъективные оценки по анкетам, поясните, пожалуйста, что Вы имеете в виду.

Берём и делаем опросник на простой веб-форме, после каждого выпуска рассылаем его разработчикам, аналитикам, РМу. В нём 3-5 вопросов из серии "Оцените глубину тестирования по 10-балльной шкале", "Оцените качество дефектов по 10-балльной шкале" и т.д. Оценки ничего интересного не покажут (люди разные!), а вот динамика между версиями - очень показательна.

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

Начнём с глубокого анализа. Почему пропускались баги. Берём конкретные баги и анализируем. У вас тесты документируются? Тестовое покрытие измеряется? Почему конкретный баг N был пропущен? Возможно, корень приведёт вас к некачественному проектированию тестов, или маленькому тестовому покрытию, или нехватке времени на тестирование, или неэффективному планированию и т.д. То есть сами по себе метрики % пропущенных багов можно собирать, только к решению проблемы эта цифра Вас не приведёт.

И самое главное: Вы уверены, что пропуск багов в Вашем случае - это проблема? Докажите, убедите меня, Этуарт! :)

[galogenIt]

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

Но...

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

Средний срок исправления, да. Как предлагаете разделять? По приоритетам?

Да, по приоритетам. В целом у нас уже есть свой регламент: немедленные - исполняются в течение дня, важные - в течение недели, релизные - в течение релиза, обычные - когда руки дойдут + на "днях дезинсектора". Есть конечно внеприоритетные работы, т.е. им ставят, естественно, немедленно, но выполняются они мгновенно :)
Можно придумать и другие способы разделения - по исполнителю, например. Зависит от ситуации, которую требуется контролировать.
Правда мне не совсем понятно какой момент считать начальным, а какой конечный. В принципе, если следовать логике СМО, то от момента создания работы по дефекту до момента закрытия дефекта. У нас такой ЖЦ работ (не обязательно дефектов): предложена - запланирована - в работе - выполнена - проверяется - принята (естественно есть циклы и ветви)

- собирать субъективные оценки по анкетам, поясните, пожалуйста, что Вы имеете в виду.

Берём и делаем опросник на простой веб-форме, после каждого выпуска рассылаем его разработчикам, аналитикам, РМу. В нём 3-5 вопросов из серии "Оцените глубину тестирования по 10-балльной шкале", "Оцените качество дефектов по 10-балльной шкале" и т.д. Оценки ничего интересного не покажут (люди разные!), а вот динамика между версиями - очень показательна.

Вероятно, я еще не очень опытный тестировщик, но затрудняюсь что-то сказать, будь я на месте аналитика или программиста, на эти вопросы: оцените глубину тестирования? - интересно, что ответят все наши "оппоненты" - мне думается, это будет пальцем в небо :)

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

Начнём с глубокого анализа. Почему пропускались баги. Берём конкретные баги и анализируем. У вас тесты документируются? Тестовое покрытие измеряется? Почему конкретный баг N был пропущен? Возможно, корень приведёт вас к некачественному проектированию тестов, или маленькому тестовому покрытию, или нехватке времени на тестирование, или неэффективному планированию и т.д. То есть сами по себе метрики % пропущенных багов можно собирать, только к решению проблемы эта цифра Вас не приведёт.

И самое главное: Вы уверены, что пропуск багов в Вашем случае - это проблема? Докажите, убедите меня, Этуарт! :)

а/ я написал допустим
б/ фраза про проблему с пропусками багов взята из Вашего предыдущего поста
в/ сама по себе метрика никак не может исправить, решить проблему - это точно так же как факт обнаружения ошибки не означает факт ее устранения или другими словами не решает проблему этой ошибки :) Так что тут у меня никаких возражений нет, да и не могло быть
г/ пропуск багов - это всегда риск. Риск предусмотренный и управляемый или непредусмотренный и неуправляемый. Пропуск ошибки - это выпуск некачественного продукта. Это определенная проблема. Всегда! Ее можно решать: ничего не делать - "сам дурак"; извинится и мгновенно устранить; обещать устранить в будущем. Пропуск багов - это лишние затраты, это риск недополучения прибыли и т.п. - это действительно проблема - серьезная или нет, it depends on
Ваш глубокий анализ верный, он вскрывает корневую причину: root problem, the problem of problems. В общем не вижу противоречий.

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

Аривидерчи

[SALar]

1. Метрики не нужны "для контроля" или "для визуализации". Метрики нужны для принятия решений.

2. Есть два типа метрик. Одни нужны для "измерения температуры больного"/"измерения эффективности предприятия" , другие для "поиска ограничений".

3.

Средний срок исправления, да.

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

[galogenIt]

1. Метрики не нужны "для контроля" или "для визуализации". Метрики нужны для принятия решений.

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

2. Есть два типа метрик. Одни нужны для "измерения температуры больного"/"измерения эффективности предприятия" , другие для "поиска ограничений".

И в чем их различие? Можно примеры?

3.

Средний срок исправления, да.

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

А каким образом ты предлагаешь фиксировать этот самый момент на стороне заказчика?