В чем разница между issue и bug в тестировании?

Question

[Cherry]

На работе разработчики не раз мне говорят "это не bug, а issue" , я им утверждаю, что баг - это несоответствие. Если есть маленькая опечатка в тексте - это все равно баг, если программа выглядит не так, как должна выглядеть по спецификации, это баг. Мало того, любое несоответствие записывается в багтрекерной системе как баг.

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

Comments

[Dark Hole]

Называйте оба варианта фичей и будет вам счастье)))

[Дмитрий Земсков]

"это не bug, а issue" например, в тз написано, что программа должны в портретной ориентации быть, а разработчик сделал и в портретной и горизонтальной,
тогда это вообще фича!

[Cherry]

Дмитрий Земсков: баг - это несоответствие актуального поведения программы с ожидающим. (это каждый тестировщик знает). В тз приписано, что ориентация должна быть такой-то, а получаем другое, вот и несоответствие. А вы тестировщик?

Answer 1

[Александр]

Баг - это когда вместо скидки к цене делается надбавка. А ишью - это когда у цены со скидкой слишком много цифр после запятой и она не влазит в отведенный ей контрол.

Comments

[Дмитрий Евграфович]

А если цена со скидкой и слишком большим количеством цифр выравнивается по центру контейнера с overflow:hidden фиксированной длины и из-за этого пользователь не может увидеть итоговую цену?

Answer 2

[Сергей Блохин]

Issue — это боль пользователя, которую он описал.
Например, пользователь забыл пароль, а система восстановления пароля не работает.
Пользователь заводит Issue, т. е. проблему, которую QA должен воспроизвести и перевести в задачу для разработчиков.

Bug — это дефект, который был обнаружен QA в процессе тестирования.

Ещё раз.
Баг — такого слова нет, есть дефект.
Любое несоответствие между работающей системой и ТЗ — это дефект.

Issue — это проблема конечного пользователя.

Comments

[Cherry]

Спасибо за ответ!! Нашла еще такое:

Bug - Any problem in existing functionality, or missing functionality. Defect in code or requirement, error which is not designed to be.

Issue (Impediment) - Any problem which might block the development process, example : a third party driver you identified as dependency is not releasing on time, so it is an issue in your development process.

Task - Any work which is planned as part of development of your project, either as result of bug, or issue or requirements, including requirement analysis or development, or testing. etc.

[Cherry]

www.dotnetspider.com/tutorials/SoftwareTesting-Tut...

[Cherry]

С прочитанной статьи я поняла, что ишью это когда нет проблем в коде. Например, заказчик хотел портретную ориентацию, разработчик сделал и портретную и горизонтальную, но все же работает.
Даже не знаю, какой документ взять за пример "моим" разработчикам. А то все называют ишью, в том числе неправильно написанный текст (хотя в minor bug и включают грамматические ошибки)

[D']

Cherry: есть проблема в понимании слова "bug" между разработчиками и QA.
Для разработчика "bug" - это что-то из разряда "всёпиздецконецсвета". Всё остальное это не баг, а фича.

Answer 3

[xmoonlight]

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

Comments

[Cherry]

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

[xmoonlight]

Cherry: Валентина, еще раз давайте разберём на простом примере.
Вы заказали обычный чёрный фонарь с инструкцией (это Ваши требования или ТЗ).
Вам привезли товар и по факту вы получаете:
1. Фонарь светит красным - это баг.
2. Цвет корпуса фонаря зелёный (вместо ожидаемого чёрного) - это тоже баг.
3. Инструкция на жёлтой бумаге, вместо белой - это не баг.
Согласны?

[Cherry]

xmoonlight: для меня да, баг удобства) так как покупатель ожидает, что инструкция будет на белой бумаге, как всегда, а желтая вызывает подозрение о качестве продукции.
Так вы тестировщик?

[Cherry]

не баг удобства, а..другой тип..

[Cherry]

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

[xmoonlight]

Cherry:
Если функциональные требования теста НЕ соответствуют результатам тестирования, тогда - ЭТО БАГ!
Замечания тестера (любые проблемы, не включенные в тестирование) - ISSUE (проблема)
Всё ОСТАЛЬНОЕ - НЕ БАГ!
Если жёлтый текст выводится на белом фоне и нет явных указаний на то, что так не должно быть - это не баг, а это уже issue - ПРОБЛЕМА!
Она может быть трактована как ошибка интерфейса пользователя (BUG) и включена в стек последующих тестов для проверки цветовой корректности (или контраста) или нивелирована до статуса NOTICE (уведомление), т.е. как неважное отклонение от ожидаемого результата пользователем по согласованию с другими подразделениями разработки и тестирования.

Answer 4

[Twiddle]

На мой взгляд, Issue - это зафиксированный Bug, переданный QA-группой группе разработчиков. Я это так понимаю.

Answer 5

[Alexej Simakov]

Такая же разница как между проблемой (или изьяном) и программной ошибкой. К черту эти разводы по понятиям. Еще к тому же и английским.
Есть два вида изьянов, из-за одних заказчик не примет работу, а другие не смертельные. Все.
Не примет работу он если она не соответствует требованиям - раз, - это объективный критерий, и если он получил не то, что ожидал - два, - это субьективный критерий. Тестировщик должен понимать, что на кону стоит заказ, и клиент платит не за игру в слова, а за качественный результат. Задача QA быть глазами заказчика в его отстутсвие.
Для меня лично баг это проблема, которую можно устранить изменив код приложения. Хотя этимологически это неверно :)