Баг или Фича? Кричать или молчать?

Всем доброго дня (или ночи), прежде чем поднять интересующую меня тему, хотелось бы представиться:
Александр, Тестировщик (стаж 1,5 года). Омск.
Я тут человек новый, и, наверное, с первым же постом создавать тему - не самая лучшая затея, главное не сочтите за наглость. Оставим лирику и сразу к сути первого вопроса:
========================================================================
Баг или Фича?
Ни один раз сталкивался с проблемой когда я оформляю баг, а мне в ответ: "Won`t Fix" - требую пояснений - в ответ: "Это Фича! Так было задумано." (Кем? Когда?)
Понятно что надо смотреть в требования, но ведь так не всегда происходит, учитывая что всех требований до сих пор нет!
Как быть если портал и без меня функционировал 4-5 лет, без документации, отлова багов и процесса тестирования в целом?

Как делаю я сейчас: Оформляю Improvement (работаем в JIR`е) - вешаю на менеджера проекта и с ним, долго и упорно пытаемся понять суть, как это уже реализовано, выявляем + и - данного дополнения / изменения.
Как правило в 8 случаях из 10 - Improvement остается без изменений и отдается разработчику - вот только времени уходи в разы больше.

Интересует мнение: Как с этим бороться? Как убедить разработчика что эта фича - не фича, а самый настоящий баг? Где грань? Как ускорить процесс?
========================================================================
Кричать или молчать?
Тема вытекает из первого вопроса.
Мысли навеяли некоторые наблюдения в работе форума software-testing.ru, бегтрекера JIR`а и система uTest
Суть в следующем, что если мне кажется что я нашел баг - говорить об этом? А если это не баг, а все та же Фича? (требований ведь я не вижу)
Я как тестировщик до мозга костей не могу мимо пройти - чувствую что надо сказать! Но мысли типа: "А вдруг об этом уже знаю и я покажусь выскочкой?" или "Вот щас напишу - а мне потом рейтинг подпортят" (uTest) и тд.

Что думаете?
P.S. Надеюсь моя писанина не покажется вам слишком сумбурной - пятница, да и выкладка вот вот намечается а я тут, пишу и отвлекаюсь постоянно.
P.S.2 А по поводу особенностей работы данного форума и Джиры я не просто так написал, "меня терзают смутные сомнения" ©
Всем спасибо!

Мысли сходу по первому: надо вести документацию. Баг оказался фичей - ок, так и запишем в документ или вики. Чтоб в следующий раз не надо было мучительно думать, баг ли это. Так и документация постепенно появится на проекте - благое дело.
Мысли сходу по второму: говорить и кричать. Но сначала пытаться разобраться самому, потратив какое-то разумное время. А потом уже отвлекать других.
Имхо, лучше лишний раз сказать, чем лишний раз не сказать. Для проекта это полезнее, но может быть вреднее для меня (паникером обзываться начнут). Ну что ж поделать - се ля ви.
Занудное ЗЫ: слово "фича" происходит от англ. feature, которое приближенно читается как "фича", а не "фиТча".

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

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

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

Давайте конкретно: Даже в данной теме есть 2 смайла топ-посте. Так вот, смайлы отображаются если вы залогинены, стоит только выйти (разлогиниться) и снова зайти в тему -
они (смайлы) уже будут не видны (отображение в виде текста).
Почему усомнился? Потому что проверил подобное на 3 разных форумах, полет нормальный.
Фича? Баг? =)

Занудное ЗЫ: слово "фича" происходит от англ. feature, которое приближенно читается как "фича", а не "фиТча".

Согласен. И весьма не занудное ЗЫ, моя ошибка.

P.S. Модератору, если возможно - исправьте в заголовке, пожалуйста, чтобы "бывалым" глаза не мозолить

Заголовок поправил.

Про uTest мы однажды уже дискутировали на близкую тему: http://software-test...inking/235.html

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

Давайте конкретно: Даже в данной теме есть 2 смайла топ-посте. Так вот, смайлы отображаются если вы залогинены, стоит только выйти (разлогиниться) и снова зайти в тему -
они (смайлы) уже будут не видны (отображение в виде текста).
Почему усомнился? Потому что проверил подобное на 3 разных форумах, полет нормальный.
Фича? Баг? =)

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

UPD. А если на этом движке форума нет такой фичи - не показывать ничего незалогиненным пользователям, то ненарисованные смайлики - баг. И запись в багтреккере я бы создал, хоть и с низким приоритетом. Не захотят фиксить (по какой угодно причине: слишком долго и дорого, нет свободных рук и т.д.-т.п.) - пусть остается висеть незакрытой или с резолюцией "won't fix". Я обратную связь обеспечил, о баге заявил.

Алексей, спасибо за заголовок.

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

Стоимость ущерба - Ноль! ИМХО. Такой баг с приоритетом Minor не более (Trivial, ага)
А вот вопрос в исправлении - это уже дело заказчика / владельца. Если бага жила и до этого и не была никем замечена, значит о критической ошибки, из-за которой и теряются деньги, - речи быть не может.
Я всегда отвечаю так: На ваше усмотрение.

Наверное, мне надо учиться настаивать и заставлять исправлять все что не вписывается в общую картину, даже ценой переделки требований и ломки "всей фичи"
Мы ведь стремимся к идеалу?
Как раз кстати подойдут слова, уважаемого bugzilkin`а

Я обратную связь обеспечил, о баге заявил.

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

UPD. А если на этом движке форума нет такой фичи - не показывать ничего незалогиненным пользователям, то ненарисованные смайлики - баг. И запись в багтреккере я бы создал, хоть и с низким приоритетом. Не захотят фиксить (по какой угодно причине: слишком долго и дорого, нет свободных рук и т.д.-т.п.) - пусть остается висеть незакрытой или с резолюцией "won't fix". Я обратную связь обеспечил, о баге заявил.

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

Давайте на яблоках тогда.
Организация в которой вы работаете и как Вы решаете подобные казусы? (вопрос ко всем)

Я все же не увидел ответа на вопрос, где грань между багом и фичей? (в условиях отсутствия исчерпывающей документации)

Нет грани. Есть явные баги, есть явные фичи, и есть огромная область неопределённости.

Организация в которой вы работаете и как Вы решаете подобные казусы? (вопрос ко всем)

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

Потом тестировщик погружается в бизнес, он уже хорошо знает что должно быть в продукте, а что не должно. Из таких соображений он и решает: баг или фича.

Понятно что надо смотреть в требования, но ведь так не всегда происходит, учитывая что всех требований до сих пор нет!

А я часто без требований работаю... Тяжело, конечно, но делать-то нечего... Было 1 раз мой репорт закрыли с комментарием "It works as required". Иногда прямо в процессе общения в баге выясняется, как данная функциональность должна работать. Я себе эту инфу сохраняю - вдруг ещё пригодится...

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

Послешайте доклад Алексея Баранцева со встречи московского клуба тестировщиков(link). Алексей очень хорошо рассказал именно про этот аспект взаимоотношений разработчиков и тестировщиков.

С разработчиками всегда можно найти общий язык ;)

Организация в которой вы работаете и как Вы решаете подобные казусы? (вопрос ко всем)

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

Потом тестировщик погружается в бизнес, он уже хорошо знает что должно быть в продукте, а что не должно. Из таких соображений он и решает: баг или фича.

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

Баг или Фича?
Ни один раз сталкивался с проблемой когда я оформляю баг, а мне в ответ: "Won`t Fix" - требую пояснений - в ответ: "Это Фича! Так было задумано." (Кем? Когда?)
Интересует мнение: Как с этим бороться? Как убедить разработчика что эта фича - не фича, а самый настоящий баг? Где грань? Как ускорить процесс?

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

Кричать или молчать?
Тема вытекает из первого вопроса.
Мысли навеяли некоторые наблюдения в работе форума software-testing.ru, бегтрекера JIR`а и система uTest
Суть в следующем, что если мне кажется что я нашел баг - говорить об этом? А если это не баг, а все та же Фича? (требований ведь я не вижу)
Я как тестировщик до мозга костей не могу мимо пройти - чувствую что надо сказать! Но мысли типа: "А вдруг об этом уже знаю и я покажусь выскочкой?" или "Вот щас напишу - а мне потом рейтинг подпортят" (uTest) и тд.

Что думаете?
P.S. Надеюсь моя писанина не покажется вам слишком сумбурной - пятница, да и выкладка вот вот намечается а я тут, пишу и отвлекаюсь постоянно.
P.S.2 А по поводу особенностей работы данного форума и Джиры я не просто так написал, "меня терзают смутные сомнения" ©
Всем спасибо!

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

А я часто без требований работаю... Тяжело, конечно, но делать-то нечего... Было 1 раз мой репорт закрыли с комментарием "It works as required". Иногда прямо в процессе общения в баге выясняется, как данная функциональность должна работать. Я себе эту инфу сохраняю - вдруг ещё пригодится...

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

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

Сделал запрос, получилось 106 issues (Bug, Won`t Fix). Видимо придется вести реестр подобных казусов.

Спасибо всем за обсуждение
Нужно поразмыслить)

А я часто без требований работаю... Тяжело, конечно, но делать-то нечего... Было 1 раз мой репорт закрыли с комментарием "It works as required". Иногда прямо в процессе общения в баге выясняется, как данная функциональность должна работать. Я себе эту инфу сохраняю - вдруг ещё пригодится...

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

Аккуратный customer, когда создаёт очередную версию требований, ведёт учёт изменений... Это удобно: сразу видно, какая часть проекта притерпела изменения (и когда), а где всё осталось по прежнему...