Перейти к содержимому

Автоматизатор мобильных приложений
онлайн, начало 11 августа
Тестирование безопасности
онлайн, начало 11 августа
Тестирование мобильных приложений
онлайн, начало 11 августа
Автоматизация тестирования REST API на Python
онлайн, начало 11 августа
Фотография

Принципиальная разница между Severity & Priority


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 83

#41 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 26 июня 2008 - 10:56

На сколько я вижу мнения разделились, кто-то за один только приоритет, кто-то за разделение на Северити и Приоритет. А где же правда???


"смешались в кучу кони, люди..." Мне кажется, что за деревьями лес уже и не виден.
Что мешает настроить jira так, как вам нужно? добавить нужные поля, установить свой воркфлоу...
Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность - добавляйте. Если внесет путаницу - не множьте сущности без необходимости :)
  • 0

#42 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 26 июня 2008 - 12:06

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

Это называется дефферед и не имеет отношения к приоритету бага. Это статус, а не приоритет.


Ага, я понял, в чем дело. У нас всех разные трекеры и разные workflow. Отсюда разное понимание.
У меня, я тут подумал, вообще приоритета нет как отдельного поля. А статус есть.
  • 0

#43 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 26 июня 2008 - 19:26

У нас у одного из клиентов был интересный подход к решению проблемы priority/severity.

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

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

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

Важно, что все видят откуда у задачи взялся такой приоритет. Например, если саппортер не согласен с низким приоритетом бага, он не просто меняет ему "priority" на high, а смотрит из-за чьей оценки багфикс получил низкий приоритет и идет разговаривать с этим человеком. Удалось его переубедить и человек изменил оценку - отлично, приоритет задачи поднимется автоматически. Саппортер чего-то не знал и его самого переубедили - еще лучше.

Такой подход ускоряет обмен информацией по важным задачам внутри организации, ведь слишком высокая или слишком низкая оценка задачи кем-то из работников влияет на порядок работ и сразу привлекает к этому внимание всех остальных.
  • 0
Максим Крамаренко

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#44 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 854 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 27 июня 2008 - 07:22

Аджильность тут вообще не при чём, Леша - ты же понимаешь.

Понимаю. Специально в кавычки взял. Не придирайся к словам :)
Просто надо было как-то обозвать те два подхода к формированию набора тасков, которые я описал.

По сути (да и по названию :)) таск -- это задание, которое менеджер даёт одному из исполнителей.

Ну блин! :) А я про что? А баг он просто так появыляется как-то на ком-то? :)) Тот же таск - тот же.

Да, баг-репорт (а вовсе не баг!!! раз уж ты придираешься к словам, я тоже буду :) ) можно при определённых условиях интерпретировать как таск -- если нас устраивает линейный воркфлоу. Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#45 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 27 июня 2008 - 09:35

У нас у одного из клиентов был интересный подход к решению проблемы priority/severity.

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

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

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

Важно, что все видят откуда у задачи взялся такой приоритет. Например, если саппортер не согласен с низким приоритетом бага, он не просто меняет ему "priority" на high, а смотрит из-за чьей оценки багфикс получил низкий приоритет и идет разговаривать с этим человеком. Удалось его переубедить и человек изменил оценку - отлично, приоритет задачи поднимется автоматически. Саппортер чего-то не знал и его самого переубедили - еще лучше.

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


Описанная система не отвечает на вопрос: что делать в случае, когда багов сотни? Да, вы получите более тщательную разбивку по весам, но в каждом весе опять будет несколько десятков багов.
  • 0

#46 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 27 июня 2008 - 11:21

Да не придираюсь я к словам, чего ты :)

Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?

Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#47 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 27 июня 2008 - 11:23

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

То есть вместо того чтобы полагаться на одно решение, вносим фактор ошибки многих решений. Бр-р-р.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#48 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 27 июня 2008 - 11:29

Описанная система не отвечает на вопрос: что делать в случае, когда багов сотни? Да, вы получите более тщательную разбивку по весам, но в каждом весе опять будет несколько десятков багов.


Так весов может быть хоть тысяча или даже десять тысяч. Параметры, влияющие на вес тоже могут быть самыми разными: состояние счета клиента, время до дидлайна, группа автора сообщения и время его работы в организации и т.п.
  • 0
Максим Крамаренко

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#49 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 27 июня 2008 - 12:28

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

То есть вместо того чтобы полагаться на одно решение, вносим фактор ошибки многих решений. Бр-р-р.


Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?

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

В качестве примера - посмотрите приоритеты багов по JIRA 3.12.x. Там critical-ом оказалась "Unclear error message when bulk moving issues whose reporter cannot create issues", а что-нибудь типа "Moving portlet up reults in IndexOutOfBoundsException" оказалось minor.

Ситуация, когда все подряд назначают "своим" багам приоритет повыше, конкурируя за время команды похожа на "трагедию общих ресурсов":
http://www.seed.slb....nge/tragedy.htm

===
Термин трагедия общих ресурсов появился в 1968 году в статье Гаррета Хардина. Он считает, что проблемы, попадающие под эту категорию, технически решения не имеют. Они требуют изменения поведения и привычек человека.
...
Проблема в том, что большинство из нас действует лишь в собственных интересах, желая получить немедленный эффект. Но потери от влияния этих действий на климат планеты мгновенно не ощущаются. Я могу ездить на большом автомобиле, потому что мне так удобно. Дискомфорт от повышения уровня моря или количества штормов может появиться лишь через несколько десятилетий. Я не вижу прямой взаимосвязи между своими действиями и этими последствиями. Фактически, если бы на большой машине ездил один человек, то негативных последствий не было бы. Так же и пастух, который добавляет одну овцу к стаду – преимущества очевидны и мгновенны, в то время как потери пространны и растянуты по времени. Когда все пастухи поступают так, то в результате в проигрыше оказываются они вместе.

Решение требует взаимодействия людей, вместе принимающих решение об изменении поведения всех, включая себя.
===
  • 0
Максим Крамаренко

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#50 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 27 июня 2008 - 12:49

Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?

Максим, странно что это именно вы спрашиваете :) Железка тут не при чём. Есть мнение моё как тестера. С ним можно соглашаться или нет. Это решается трекингом через тех, кто имеет право влиять на моё решение.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#51 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 27 июня 2008 - 12:57

Добрый день,

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

А то как и что применять - это уже дело каждого, как сказал Jackie:

Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.


Вот.
Спасибо всем.
  • 0
Алексей Булат
Про Тестинг

#52 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 854 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 30 июня 2008 - 07:22

Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?

Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?

Слава, этот спор аналогичен спору про ресурсы и роли. "Баг-репорт" и "таск" -- это две роли. Я не спорю, что один и тот же артефакт может выступать в двух разных ролях, хотите совмещать -- пожалуйста. Мой тезис заключается в том, что атрибут "критичность" относится к роли "баг-репорт", а атрибут "приоритет" -- к роли "таск". Исходя из этого тезиса, мне кажется, что физическое совмещение этих атрибутов в одном поле накладывает серьёзное ограничение на удобство использования системы.
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#53 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 30 июня 2008 - 12:28

Леша :) Ты согласен что достаточно одного атрибута?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#54 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 854 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 30 июня 2008 - 16:38

Леша :) Ты согласен что достаточно одного атрибута?

НЕТ :acute:
Я согласен, что при определённых предположениях и ограничениях можно использовать один артефакт в двух ролях. Но для каждой роли лучше иметь свой атрибут.
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#55 darm

darm

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Иван

Отправлено 08 июля 2008 - 21:22

Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?


Именно, что одного параметра достаточно, если у каждого члена команды есть более-менее четкое представление, что важно, а что не очень, и такое "кажется" происходит редко. А вот если приложение большое, народу много, процессы поставлены не очень, клиенты психованные или ещё что там - тогда возникает необходимость в человеке, который будет приоритеты расставлять. Ну а вся эта система со сложным вычислением весов, конечно, забавная, но избыточная уже, наверное. Если у тестера оказался кривой билд и не работает вообще, он занёс шоустоппер с заголовком капслоком, а у остальных всё отлично, это и само быстро всплывёт - впрочем, скорее всего, ещё до занесения в трекер.
  • 0

#56 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 09 июля 2008 - 10:00

Леша :) Ты согласен что достаточно одного атрибута?

НЕТ :mega_shok:
Я согласен, что при определённых предположениях и ограничениях можно использовать один артефакт в двух ролях. Но для каждой роли лучше иметь свой атрибут.


Леша, ты играешся в слова :acute:
Маппинг между статусами один-к-одному?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#57 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 854 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 09 июля 2008 - 14:38

Леша :) Ты согласен что достаточно одного атрибута?

НЕТ :mega_shok:
Я согласен, что при определённых предположениях и ограничениях можно использовать один артефакт в двух ролях. Но для каждой роли лучше иметь свой атрибут.


Леша, ты играешся в слова :acute:
Маппинг между статусами один-к-одному?

Именно потому и два, что не один к одному.
Я выхожу из дискуссии. Твою точку зрения, Слава, я понял.
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#58 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 17 сентября 2008 - 20:52

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


Одна из целей тестирования - получение информации от свойствах ПО.
Создание баг-репорт - это фиксирование полученной информации.

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

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

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


Понятно, что в конечном итоге все сводится к фиксим - не фиксим.
Но решение принимается на основании анализа различных факторов. Северити - один из них.

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

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

Да не придираюсь я к словам, чего ты :)

Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?

Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?


  • 0

#59 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 17 сентября 2008 - 22:04

Уточню.

Баг-репорт может не являться таском или реквестом на изменение кода.

От этого его сущность не меняется.

Да, баг-репорт (а вовсе не баг!!! раз уж ты придираешься к словам, я тоже буду :) ) можно при определённых условиях интерпретировать как таск -- если нас устраивает линейный воркфлоу. Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?


  • 0

#60 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 19 сентября 2008 - 12:28

Баг-репорт может не являться таском или реквестом на изменение кода.

Наверное, можно придумать такую ситуацию - но я не сумел. Пример подскажете?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru


Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале