Теория
Баг (от англ. bug - насекомое, жук; жарг. дефект, ошибка, сбой в аппаратуре, компьютерной программе) - выявленная ошибка в программе или в документации.
Википедия говорит:
«В программировании баг (англ. bug — жук) — жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат.»Зачастую можно услышать и употребление этого термина в женском роде, т.е. бага, но я предпочту этот вариант использования отмести и забыть про него, т.к. считаю режущим при произношение слух.
Из истории возникновения
По легенде, 9 сентября 1947 года учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле. Именно тогда Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник, с сопроводительной надписью: «First actual case of bug being found» (англ. «Первый фактический случай обнаружения жука»). Этот забавный факт положил начало использованию слова «debugging» в значении «отладка программы».
Слово «bug» в современном значении употреблялось задолго до этого. Так, в течение Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой. Но ещё в 1878 году Томас Эдисон писал: «Это повторялось снова и снова со всеми моими изобретениями. Первым шагом была интуиция, за ней следовала вспышка, затем возникали препятствия — и они исчезали, потом возникали Баги — так называются маленькие недочеты и трудности — и необходимы месяцы постоянного поиска, исследований и тяжелого труда до успеха или неудачи.»
Действительность
Многие рекомендуют использовать термин ошибка, но как быть в случае, если, например, сутью bug report’а, занесённого тестировщиком в систему отслеживания ошибок, является не отчёт об ошибке, а отчёт с дополнением?! Думаю, не стоит приравнивать определения термина баг к определению термина ошибка.
Существует и вариант определения, основанный на этапе нахождения, а именно баг - это ошибка в программе, выявленная при тестировании программы и в процессе ее использования. Но простите, как тогда называется ошибка найденная разработчиком в своём или чужом коде на этапе кодирования?! Проводя аналогию, можно сказать, что если повар до подачи на стол гостям обнаружил, что приготовленный им суп не вкусный, то этот суп не считается не вкусным.
Если же брать определение в виде баг - это когда фактический результат не равен ожидаемому результату, то на защиту этого варианта встаёт ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию» который гласит:
«8.3.6 .......отсюда можно сделать вывод, что всякое необъяснимое расхождение между фактическим и ожидаемым результатами и есть баг! Хотя в этом случае возникают вопросы, например «А если расхождение будет объяснимым, то уже не считается багом?»… наверно не стоит буквально понимать слово «необъяснимое», авторами видимо имеется ввиду не задокументированное расхождение, т.е. расхождение которое нельзя объяснить согласно ТЗ и прочей документации на систему. Многие специалисты также говорят: «Не всегда. Пользователь может ожидать от программы всего чего угодно, но это не значит, что если он не нашел этого значит это баг программы. Бывает и такое, что пользователь плохо умеет считать и ожидает, что результат будет 2+2=6, а ему выдает 4 . Разве это баг?». Осмелюсь возразить и в доказательство скажу, что любая система производится для кого-то и для каких-либо нужд, т.е. если систему производят для пользователей считающих, что 2+2=6, то в такой системе результат 4 будет являться багом. Из выше сказанного можно сделать вывод, что баг – это расхождение фактического поведения системы и описанного в ТЗ, АЗ, спецификации и т.д., т.е. верного, принятого верным...
в) результаты тестирования: гарантировать, что результаты тестирования корректны и что расхождения между фактическим и ожидаемым результатами объяснимы»
Что касается ожидаемого результата, то не стоит забывать и о «Вообще-то ожидаемый результат, это не результат, который ожидает пользователь, а результат описанного в документации действия, с описанным методом «появления» результата. Если ожидаемый результат противоречит логическому методу решения проблемы, то это баг документации. Т.е. если в документации написано 2+2=6, и метод получение заявлен арифметический результат двух слагаемых, то понятно, что это будет ошибка документации т.к. используя данный метод и слагаемые, примёненные в нем получается другой результат.»
Вы, наверное, скажите: «А если нет ни ТЗ, ни АЗ, ни спецификации, нет принятого верным поведения, и заказчика даже нет…». Если же нет заказчика или разработка ведётся для себя и точность действий системы не критична, то в этом случае при тестировании необходимо пользоваться логикой и тогда баг – это расхождение видения, понимания, подсказок логики тестировщика с реально работой системы. Если же заказчика нет, но систему планируется продавать, то суть определения термина баг будет ясна из цитаты «Всё же видимо рынок как-то изучался, технико-экономическое обоснование прикидывалось. И какое-то (пусть и не формализованное описание) есть. А уж если все готово, и настало время выходить на рынок - какой-то минимальный комплект документов делать придется. Где и будет описание - что продукт делает.»
Итог
Подводя итог всему вышесказанному и исходя из определения термина «качество», сформулированного Филиппом Крухтеном, звучащим так: «Качество - это соответствие продукта ожиданиям пользователя (заказчика)», смею обозначить наиболее приемлемое, по моему мнению, определение термина баг, звучащее так: «Баг - это когда фактический результат не равен ожиданиям пользователя (заказчика)». В подтверждении такого определения цитирую IEEE Std 829-1983
«Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств программного обеспечения.»Т.е. очевидно, что требуемые свойства - это ожидания пользователя, т.к. всякий продукт делается для кого-то. Но подведя аналогичный итог на форуме с обсуждением проблемы термина баг, я с толкнулся с возражениями выраженными в приведении примера:
«Пусть пользователь требует реализовать функцию тангенс, как известно tg(x)=sin(x)/cos(x). Чем мы и воспользуемся, реализуя сначала sin и cos. Как хорошие разработчики мы проводим модульное тестирование и проверяем функции sin и cos. Но как мы можем найти в них баг если пользователь не высказал и не обозначил другим способом свои ожидания по этим функциям? Никак. Аналогия с реальными системами понятна?»Но эти возражения, по моему мнению, не совсем отражают действительность, т.к. в приведённом примере функции синус и косинус должны работать так, чтобы удовлетворять конечному требованию... т.е. «если пользователь не высказал и не обозначил другим способом свои ожидания по этим функциям», то они должны работать так, чтобы результат операции sin(x)/cos(x) был равен именно tg(x), а не ctg(x) например.
Подискутировав ещё немного, я не то, чтобы поменял своё мнение об определении термина баг, но более чётко определил, по крайней мере для себя такой нюанс
«Баг - это собирательный термин. Это ошибка / дефект / проблема / отказ / сбой / неисправность / повреждение / несоответствие, в результате которого система возвращает некорректный или неожидаемый результат или ведет себя непредусмотренным образом»
Источники
