Приоритет дефекта

Должен ли влиять способ обнаружения дефекта влиять на его приоритет?
При прочих равных, если багу обнаружила CI - должна ли эта бага быть выше на доске задач?

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

Напишите, мне очень важно ваше мнение :) И его обоснование.
Заранее спасибо.

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

Если CI обнаружила багу, это значит только то, что CI работает :) ИМХО, на приоритет влиять она не должна.
Можно кинуть ссылку на этот баг разработчику и сказать "ты вот тут только что слажал, приоритет у бага средний, но лучше поправь сразу, чтоб не возвращаться".

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

Если, как шарики в вакууме, то, как найден дефект, не влияет на его приоритет и серьезность.

На приоритет дефекта влияет то, КТО его нашёл, а КАК его нашли не столь важно.

На приоритет дефекта влияет то, КТО его нашёл, а КАК его нашли не столь важно.

Как влияет то, кто нашел, не совсем понял.

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

CI используется для оперативной поддержки рефакторинга в том числе :) Какой в этом случае вывод?

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

На мой взгляд, способ обнаружения бага не должен влиять на приоритет.

Аргумент в пользу да: если не исправлять сразу - нивелируется одно из основных преимуществ автоматических тестов - оперативность. Слабый аргументик...

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

То кем оно обнаружено не важно.

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

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

CI используется для оперативной поддержки рефакторинга в том числе :) Какой в этом случае вывод?

Проще уточнить у менеджера, полагаю у него уже посчитано, что важнее :)

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

• Устранение ошибок от рефакторинга после реализации функционала+доп. рефакторинг+перетестирование;
• Отладка модулей, которые падают, что бы в релиз кандидате не выполнять опять полный рефакторинг;
• Оценка актуальности и изменение набора тестов в CI, т.к. если они не важны - их может вынести в регрессию?

Что даст больший выигрыш из 1,2,3.
Там, где затрат меньше а выигрыш больше - большой приоритет, для дефектов такого типа:)

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

То кем оно обнаружено не важно.

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

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

Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.

(с) Velocity is Killing Agility by Jim Highsmith

Хотя... who cares?

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

Это называется «наклонить высказывание под нужным углом». То, что дефект обнаружил заказчик влияет на приоритет, а не «complete priority control». Да, видимо «взлететь до небес» не стоило использовать.

И severity тоже не стоило. Не у всех есть. Да и заказчик понятие растяжимое. А менеджера вообще может и не быть.

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

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

И severity тоже не стоило. Не у всех есть. Да и заказчик понятие растяжимое. А менеджера вообще может и не быть.

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

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

Тотальный блокер, мелкая проблема - для меня это пункты из severity, а не приоритеты. Может отсюда у нас недопонимание идёт?
Да, способ обнаружения не влияет ни на приоритет, ни на серьёзность, об этом я и писал.

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

Честно говоря не до конца понял вот это место... "незначительность" - это приоритет или серьёзность?

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

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

Конечно не скатимся =)))

Давайте я укажу первоисточник вопроса.

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

Тестировщик вручную нашел несколько важных баг. CI каждый день находит массу не самых важных баг, исправление которых по объективным причинам откладывается.
К тому моменту когда доходят до их исправления - тестировщик их успевает найти и вручную (это отслеживается).
Смысл CI пропадает. А совсем отказаться жалко :)

stmark, ящетаю не стоит нам скатываться в обсуждение того чем severity от priority отличается (это уже бюрократия, а не тестирование). Тем более что по работе я с первым вообще последние года четыре практически не сталкиваюсь. Договорились что не важно кто обнаружил и ладушки.

Wolonter, тогда в чем вопрос? Надо ли править ошибки приводящие к "красной лампочке"? Или надо ли подкрутить автоматическую репортилку с CI?

Давайте я укажу первоисточник вопроса.

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

Тестировщик вручную нашел несколько важных баг. CI каждый день находит массу не самых важных баг, исправление которых по объективным причинам откладывается.
К тому моменту когда доходят до их исправления - тестировщик их успевает найти и вручную (это отслеживается).
Смысл CI пропадает. А совсем отказаться жалко :)

На вопрос автора уже написал своё мнение, не важно, как найден баг. Отказываться от автотестов или нет, это уже отдельный вопрос. Не ясно, на сколько дорога поддержка этих автотестов. А вдруг они критичный баг найдут? Может они ещё для чего-либо нужны...

Не ясно, на сколько дорога поддержка этих автотестов. А вдруг они критичный баг найдут? Может они ещё для чего-либо нужны...

Поддержка достаточно дорога =)).
Может и найдут критичный баг. И еще для чего-то - нужны. Это - точно. Вопрос в том, что делать со смыслом их существования сейчас.

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

Поддержка достаточно дорога =)).
Может и найдут критичный баг. И еще для чего-то - нужны. Это - точно. Вопрос в том, что делать со смыслом их существования сейчас.

лучше, если в один прекрасный момент они этот критичный баг найдут, и найдут быстро! :)
ИМХО автотесты и нужны не в последнюю очередь для того, чтобы удостовериться, что ничего не поломалось.

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