Привет! Назрел тут достаточно серьёзный вопрос.
А что, собственно, мы считаем багой? Вернее,
есть-ли в каклм-нибудь уважаемом месте (например MSDN)
точное определение бага? Поиск пока ничего не дал.
Здравствуйте, Maydyk, Вы писали:
M>Привет! Назрел тут достаточно серьёзный вопрос. M>А что, собственно, мы считаем багой? Вернее, M>есть-ли в каклм-нибудь уважаемом месте (например MSDN) M>точное определение бага? Поиск пока ничего не дал.
Здравствуйте, Maydyk, Вы писали:
M>Привет! Назрел тут достаточно серьёзный вопрос. M>А что, собственно, мы считаем багой? Вернее, M>есть-ли в каклм-нибудь уважаемом месте (например MSDN) M>точное определение бага? Поиск пока ничего не дал.
Мифология этого слова проистекает от первых машин, рассчитывавших артиллерийские траектории. Они работали на лампах и светились. Когда их впервые вывезли в поле, они перестали работать — на свет слетелась куча насекомых и позамыкала контакты.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Здравствуйте, Zar, Вы писали:
Zar>>"Бага" — сленговое слово.
ДМ>Ну а если я напишу bug, что-то изменится?
ДМ>На самом деле вопрос не шуточный.
Хочешь получить определение термина, хотя бы возьми на себя труд написать его. Я не знаю, что ТЫ подразумеваешь под словом bug. Может у тебя в микрокоде ошибка, а может в кристаловском отчёте, а мож в ДНК...
Возможно, я несколько неточно выразился. Речь идёт именно об ошибках в программе,
вернее, что именно считается ошибкой. Припоминается что "бага (ошибка) это несоответствие спецификации".
Опять-же MS постоянно использует этот термин, а что за ним стоит никто толком не знает.
O>Мифология этого слова проистекает от первых машин, рассчитывавших артиллерийские траектории. Они работали на лампах и светились. Когда их впервые вывезли в поле, они перестали работать — на свет слетелась куча насекомых и позамыкала контакты.
Угу, сказку про запись в журанале ремонтных работ я слышал.
Здравствуйте, Zar, Вы писали: Zar>Хочешь получить определение термина, хотя бы возьми на себя труд написать его. Я не знаю, что ТЫ подразумеваешь под словом bug. Может у тебя в микрокоде ошибка, а может в кристаловском отчёте, а мож в ДНК...
Меня больше всего интересует что под этим термином понимает MS.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Вы что, издеваетесь?
Каков вопрос...
ДМ>Возможно, я несколько неточно выразился. Речь идёт именно об ошибках в программе, ДМ>вернее, что именно считается ошибкой. Припоминается что "бага (ошибка) это несоответствие спецификации". ДМ>Опять-же MS постоянно использует этот термин, а что за ним стоит никто толком не знает.
Что значит никто не знает?
Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное.
Есть реальное поведение программы. (фича, англ. feature — особенность, свойство).
Если они не соответствуют друг другу, это ошибка, т.е. баг.
Если это поведение можно внести в спецификацию (объяснить заказчику, что так лучше, и нефиг рожу кривить) — это явление называется "перековать баги на фичи" (см. мой подоконник).
Здравствуйте, Денис Майдыковский, Вы писали:
O>>bug 1. сущ 1) насекомое ( особ. кровососущие ); личинка насекомых; жук ДМ>Вы что, издеваетесь?
Нет, это было вступление к лирическому отступлению
ДМ>Возможно, я несколько неточно выразился. Речь идёт именно об ошибках в программе, ДМ>вернее, что именно считается ошибкой. Припоминается что "бага (ошибка) это несоответствие спецификации". ДМ>Опять-же MS постоянно использует этот термин, а что за ним стоит никто толком не знает.
Вы хочите формализму? Их нет у меня. Давайте порассуждаем.
Есть ожидаемое поведение некоторой сущности. По какой причине именно это поведение ожидаемо — неважно. Это может быть синтаксис языка программирования, могут быть спецификации на ПО, может быть описание класса. Важно то, что есть определенная семантика, а наблюдаемое поведение отличается. Вот это и есть баг
Причем, заметь, баг может быть как в реализации, так и в описании ожидаемого поведение. Вобщем, баг — это несоответствии эксперимента теории
... << RSDN@Home 1.0 beta 3 | Сейчас четверг, 17:12, слушаю Limp Bizkit — Re-Arrange >>
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Денис Майдыковский, Вы писали:
К>Каков вопрос...
Ну извините.
К>Что значит никто не знает?
А где это написано?
К>Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное. К>Есть реальное поведение программы. (фича, англ. feature — особенность, свойство). К>Если они не соответствуют друг другу, это ошибка, т.е. баг.
Вот именно что спецификации, а не ожиданиям заказчика. Отсюда и вопрос.
Проблема, думаю, понятна. В спецификации поведение программы не определено, но,
как оказалось оно не соответсвует ожиданиям заказчика. И вот это называется
грозным словом bug. А стоит задача доказать обратное.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Меня больше всего интересует что под этим термином понимает MS.
Так что ж ты тогда на RSDN вопрос задаёшь, воду мутишь? Напиши на support@microsoft.com
Или задай вопрос: Что значит "Microsoft confirmed this to be a bug in product blah-blah-blah"?
Тебе тут же ответят честно и точно: Это значит, что
а) набралась определенная статистика таких проблем
б) MS поставил ее в очередь на рассмотрение важности
в) В зависимости от критичности, ожидать фикса стоит
— в след. Critical Update
— в след. Recommended Update
— в след. Service Pack
— как руки дойдут
— как Билл объявит месячник борьбы с тараканами
... << RSDN@Home 1.0 beta 3 | Сейчас четверг, 17:12, слушаю Limp Bizkit — Living it up >>
Здравствуйте, orangy, Вы писали:
O>Вы хочите формализму? Их нет у меня. Давайте порассуждаем.
Ох, хочу!
O>Есть ожидаемое поведение некоторой сущности. По какой причине именно это поведение ожидаемо — неважно. Это может быть синтаксис языка программирования, могут быть спецификации на ПО, может быть описание класса. Важно то, что есть определенная семантика, а наблюдаемое поведение отличается. Вот это и есть баг
Вот в данном случае очень важно, "По какой причине именно это поведение ожидаемо".
O>Причем, заметь, баг может быть как в реализации, так и в описании ожидаемого поведение. Вобщем, баг — это несоответствии эксперимента теории
Теоретически всё верно, а практически, надо с заказчиком взаимодействовать.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Вот именно что спецификации, а не ожиданиям заказчика. Отсюда и вопрос. ДМ>Проблема, думаю, понятна. В спецификации поведение программы не определено, но, ДМ>как оказалось оно не соответсвует ожиданиям заказчика. И вот это называется ДМ>грозным словом bug. А стоит задача доказать обратное.
Ага, наконец мы добрались до сути. Это просто вопрос контракта, не более того. Если у вас в контракте написано — делаем от и до по SRS — ну и делайте. Пофиг на ожидания. Подписано. Если нет — смотрите как договорились. К багам отношения не имеет.
... << RSDN@Home 1.0 beta 3 | Сейчас четверг, 17:12, слушаю Nickelback — Never Again >>
Здравствуйте, Денис Майдыковский, Вы писали:
К>>Что значит никто не знает? ДМ>А где это написано?
Не веришь в силу устной речи?
К>>Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное. К>>Есть реальное поведение программы. (фича, англ. feature — особенность, свойство). К>>Если они не соответствуют друг другу, это ошибка, т.е. баг.
ДМ>Вот именно что спецификации, а не ожиданиям заказчика. Отсюда и вопрос.
У заказчика в душе есть идеал: то, как должна работать программа.
Он этот идеал переносит в заказ, по мере своих умений.
Здесь тоже есть поле для ошибок: "сделать хотел грозу, а получил козу".
ДМ>Проблема, думаю, понятна. В спецификации поведение программы не определено, но, как оказалось оно не соответсвует ожиданиям заказчика. И вот это называется грозным словом bug. А стоит задача доказать обратное.
Можно придраться к бумажке, на которой было написано (уклончиво послать на).
Можно уточнить текст спецификации (исправить ошибку ).
К>Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное.
К>Есть реальное поведение программы. (фича, англ. feature — особенность, свойство).
К>Если они не соответствуют друг другу, это ошибка, т.е. баг.
Баг в чем? В программе или в спецификации?
Как известно фальшивая монета может содержать как меньше, так и больше золота по весу.
К>Если это поведение можно внести в спецификацию (объяснить заказчику, что так лучше, и нефиг рожу кривить) — это явление называется "перековать баги на фичи" (см. мой подоконник).
Т.е. доказать, что это баг в спецификации, а не в программе.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, Денис Майдыковский, Вы писали:
O>Ага, наконец мы добрались до сути. Это просто вопрос контракта, не более того. Если у вас в контракте написано — делаем от и до по SRS — ну и делайте. Пофиг на ожидания. Подписано. Если нет — смотрите как договорились. К багам отношения не имеет.
Тем не менее, хотелось-бы иметь ссылку на авторитетное определение слова "BUG".
Видно, не судьба...
К>>Есть спецификация. Например, описание того, как функция должна работать. Чего ждет заказчик. И тому подобное.
К>>Есть реальное поведение программы. (фича, англ. feature — особенность, свойство).
К>>Если они не соответствуют друг другу, это ошибка, т.е. баг.
Vi2>Баг в чем? В программе или в спецификации?
В конце концов, если посмотреть на это глазами заказчика, то ожидания + контракт + спецификация + проектная документация + сырцы + бинарники + плоды работы + удовольствие -- это один комплекс.
По большому счету, все равно, где ошибка. Если результат не соответствует потребности (даже не ожиданиям!), то это баг.
По большому счету, также все равно, кто отвечает за исправление (начиная от психиатра и кончая производителем дохлой материнской платы).
Если ошибки скомпенсированы и не проявились, то это просто уменьшает надежность комплекса.
Конечно, желательно с самого начала делать все от тебя зависящее качественно. Но можно и итерационно.
Vi2>Как известно фальшивая монета может содержать как меньше, так и больше золота по весу.
Да, и это известная проблема. Например, стоит ли считать багом, что ОС, помимо действительно нужных вещей, тащит при инсталляции пару гигов всяких прибамбасов.
К>>Если это поведение можно внести в спецификацию (объяснить заказчику, что так лучше, и нефиг рожу кривить) — это явление называется "перековать баги на фичи" (см. мой подоконник).
Vi2>Т.е. доказать, что это баг в спецификации, а не в программе.
Отчасти...
"В споре рождается истина, в ссоре она помирает".
Задача — не доказать, а прийти к конструктивному решению.
Может быть, отключить функциональность, а может — включить ее в спецификацию. Всякое бывает.
Перекуём баги на фичи!
