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

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

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

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.

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

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

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

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

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

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

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

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

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