Что считать багом?

Привет всем!

Захотелось мне как новичку что-нибудь простенькое протестить. Выбрал простенький сайтик без форм и приложений. Сразу возникло много вопросов. А это баг? А то баг?
К примеру, сайт Логики. Предпоследний пункт горизонтального меню переходя в активное состояние, по аналогии с остальными пунктами, должен изменять свой вид — иконка меняется и при наведении мышкой цвет текста не меняется. Но этого не происходит. Это баг?
Или если выбрать третий пункт горизонтального меню, то видно, что копирайт привязан к контенту — он подскочил вверх. Это некрасиво с точки зрения дизайна (по крайней мере я так считаю :)) Но это баг?
Еще пример. На странице вакансий есть маркированные списки. В опере и IE маркеры по разному отображаются — к этому нужно придираться?
А если на некоторых страницах вместо тире (—) дефисы (-)? Грамматические ашипки — это баги?
Я понимаю, что все, что я описал, — это незначительные и совсем не важные ошибки, но я все это считаю багами. Может я и не прав, может тестер не должен на это терять время и пусть этим занимаются верстальщики (хотя опечатки есть не только на сайтах, но и в программах). С другой стороны, тестеры отвечают за качество и если пропускать подобное, то сайт качественным не будет.

Как поступать? Может в разных компаниях по разному к этому относятся?

По книге Романа Савина "Тестирование dot COM" баг определяется:
а) по спецификации;
б) здравым смыслом;
в) каким-нибудь начальником. Тот, кто сможет подсказать.

А теперь личное мнение:
Я бы тоже посчитал вышеперечисленное недоработкой, ошибкой дизайнера / верстальщика.
Грамматические ошибки - баги. Однозначно. С трудом, но приучили наших программистов их исправлять сразу же, хотя бы в граф. интерфейсе. Про логи я уж умолчу :)

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

Ооо, какие глубокие философские вопросы для новичка! :)

Есть такая штука - common sence, она же "чувство здравого смысла". Так как не бывает всеобъемлющих требований, то чаще всего тестировщики руководствуются именно здравым смыслом для определения "что есть баг", а "что есть не баг".
К примеру, "предпоследний пункт не меняет свой вид в активном состоянии". Как я понимаю, это единственный пункт, у которого нет подпунктов в левом меню, отсюда и отличия в поведении. Но, НА МОЙ ВЗГЛЯД, это бага. Так говорит мне мой здравый смысл :)

Дальше - круче. Идём к "главному" в проекте, к примеру, аналитику, РМу, или ответственному UI-эксперту - кто там у нас будет главным в этом случае, неизвестно. И говорим: "это бага?". А он говорит "нет!". Что делать?

1) Прислушаться к его мнению, узнать, почему он считает такое поведение корректным - может, мы тоже увидим в нём логику?
2) Объяснить ему наше мнение: почему мы считаем, что это бага, чем это поведение негативно сказывается на пользователях?

И вот, мы его убедили!

Что дальше? Дальше, чтобы баг исправили, в голове РМ'а должно "замкнуть": "Стоимость исправления дефекта ниже, чем негатив, наносимый нам этим дефектом". А теперь подумаем, чем чревата эта ошибка? Боюсь, что ничем! Поэтому, исправлена она будет только если:

1) Верстальщика нечем занять
2) РМ - перфекционист
3) РМ не умеет приоритезировать

Заранее зная обстановку в компании, мы можем иногда даже решить не заводить такие баги... Но это уже ересь, не слушайте её пока что :)


Про третий пункт и копирайт я не поняла... Если вы про нижнюю строку (футер), то он всегда находится под телом и движется вверх/вниз в зависимости от наполнения, мне ЛИЧНО это кажется корректным... Можем поспорить, потренируемся ;)
Про списки - то же самое, убедите меня, что это бага? Я не вижу причин считать это дефектом...

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

Итого, несколько выводов:
1) Я из 4х ошибок согласна с 2мя, с другими нет. Кто-то может по-другому распределить свои предпочтения, потому что здравый смысл - понятие не объективное. Если нет конкретных стандартов, спецификаций, и требований, в соответствии с которыми что-то можно считать ошибкой, то требуется хорошенько подумать: каково влияние "ошибки"? В общем, надо учиться аргументировать некорректность поведения программы :)
2) Даже прийдя к согласию, что какое-либо поведение является ошибочным, нельзя утверждать, что "это необходимо исправть". Ситуации разные бывают ;)
3) Утверждение "если пропускать такое, сайт качественным не будет" в корне неверное, потому что прежде чем оценивать качество, надо определить его критерии. Заметят ли пользователи то, о чём вы говорите?
4) "Тестеры отвечают за качество" - ещё одно неверное утверждение :) Тестеры всячески способствуют выпуску продукта в соответствие с его целями. В числе целей может быть качество "perfect", может быть качество "good enough", а может быть только "срок - вчера, и главное чтоб открывался!!!". И какими бы ни были цели, наша задача - помочь их реализовать, а не ставить палки в колёса и вступая в ряды адептов quality school.

Romantik, можно я тему в общий форум перенесу? Мне кажется, многим будет интересно, не только нашим "рассыльщикам"? :)

Конечно можно перенести! Я там сначала и хотел написать. Спасибо большое за исчерпывающий ответ!
Сегодня продолжил чтение книги Савина Р. «Тестирование дот ком» и в третьей главе дошел до такого понятия как серьезность бага. Т.е. по книге, баг может быть:
С1 — критический;
С2 — значительный;
С3 — умеренный;
С4 — косметический.

Так вот приведенные мной баги имеют серьезность С4. Из книги:

«Косметическая проблемма — баги, связанные с содержанием веб-сайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).»

На счет футера спорить не буду. Уже понял, что это багом не назовешь. Мне просто не нравится, когда он скачет за контентом :) Хотя многие пытаются его прижать к низу страницы (можно ввести в гугле слово «футер» и посмотреть варианты поиска).

Теперь на счет маркеров. Я говорил о кроссбраузерности — свойстве сайта отображаться и работать во всех популярных браузерах идентично. Тоже не буду спорить. Может при разработке сайта кроссбраузерность не была одной из целей. А может это и не считается багом с точки зрения кроссбраузерной верстки.

На счет качества сайта. Я считаю, что солидная компания должна иметь соответсвующее лицо, в качестве которого может выступать веб-сайт. Мне, например, такие ошибки всегда бросаются в глаза и сразу возникают мысли о небрежности, неточности, невнимательности, о несерьезном отношении. Согласен, далеко не все обращают на это внимание. Но некоторые же обращают! :) В полиграфии есть четкие правила и требования к верстке и почему-то их придерживаются не смотря на то, обратит читатель внимание или нет.

Во всяком случае, тестировщику даются требования и спеки по каждому (хотя наверное и не по каждому) продукту и нужно опираться на них.

З.Ы. "срок - вчера, и главное чтоб открывался!!!"

>Во всяком случае, тестировщику даются требования и спеки по каждому (хотя наверное и не по каждому) продукту и нужно опираться на них.

:) У нас их вообще нет или есть, но мало, скорее требования, а не спецификация. Хотя "мы" и не показатель, разумеется, просто делюсь опытом. Плохо, конечно, но зато есть небольшой опыт, здравый смысл и помощь старших по цеху.

Сообщение отредактировал Stanislavsky: 17 августа 2011 - 14:39

«Косметическая проблемма — баги, связанные с содержанием веб-сайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).»

Уже могу заводить? :)

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

Хорошие мысли :) Осталось только согласовать это видение с владельцем компании и сайта :)

Хм..

Про

"Я считаю, что солидная компания должна иметь соответсвующее лицо, в качестве которого может выступать веб-сайт."

Вчера залезла на сайт отеля Милан, где конференция будет проходить.
Добралась до бронирования, выбрав русский язык:

https://secure.netbo...=.hotelmilan.ru

На страничке идет смесь русского и английского.
Причем весьма специфическая.
Например, есть день недели, начинающийся на "Ф" ( фрайди, видимо).

Ну вчера написала им злобное письмо.
По поводу того, что русский язык у нас государственный...

Да, баги. Да, плохо с русским языком.

Внимание вопрос.
Это косметическая проблема?

1. Наташ, хорошо расписываешь. Интересно читать
2. Фрося, вы привели ссылку не на сам отель Милан, а на систему бронирования, которая наверняка переводится через какой-нибудь онлайн-переводчик на лету. Да и сайт этот наверняка иностранный. Но это уже офтопик

1. Наташ, хорошо расписываешь. Интересно читать
2. Фрося, вы привели ссылку не на сам отель Милан, а на систему бронирования, которая наверняка переводится через какой-нибудь онлайн-переводчик на лету. Да и сайт этот наверняка иностранный. Но это уже офтопик

Возможно, я бестолково объяснила свою мысль.
Тут не оффтоп, а разнесение багов по критичности.

Насчет багов в контенте сайта.
Вот этот момент:
«Косметическая проблемма — баги, связанные с содержанием веб-сайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).»

В данном случае с отелем, мне, как пользователю, абсолютно пофик -- что это система бронирования, или нет. Чем и как переводили.
Иностранный сайт или нет.
Все это - внутренняя кухня разработчика сайта.

По приведенной классификации -- баги косметические, так? С 4-м уровнем серьезности (минимальным), так?

Но данные баги меня лично реально выбесили. И я абсолютно уверена, что подобные баги могут послужить причиной обращения в суд, к примеру. Или к написанию писем в (мэрию, Президенту, в газеты, ну куда еще фантазии хватит). Что скорее всего я и сделаю.
Со всеми вытекающими последствиями для отеля.

Поэтому баги в контенте и интерфейсе сайта относить к 4-му уровню серьезности абсолютно неправильно!

Romantik, Вы задали очень философский вопрос. На эту тему можно говорить годами и не прийти к единому мнению.
Например. Exception на странице - баг? Баг. Если Exception вылез - значит страница завалилась.
Один раз мои действия вызвали Exception. На что создатель фичи ответил: "всё было написано так, что подобные действия обязательно вызовут исключение. И исправить нельзя. Поэтому чинить не буду. Просто сюда, а потом сюда нажимать нельзя". Вот так баг стал не багом.
Это я к тому, что каждая ситуация уникальна.

Ох уж эти сайты и электронные системы. Люди решают все :)
Процедура, описанная на сайте конференции (http://it-conf.ru/ru/content/385.htm) проста, быстра и работает (ну я надеюсь).

Romantik, Вы задали очень философский вопрос. На эту тему можно говорить годами и не прийти к единому мнению.
Например. Exception на странице - баг? Баг. Если Exception вылез - значит страница завалилась.
Один раз мои действия вызвали Exception. На что создатель фичи ответил: "всё было написано так, что подобные действия обязательно вызовут исключение. И исправить нельзя. Поэтому чинить не буду. Просто сюда, а потом сюда нажимать нельзя". Вот так баг стал не багом.
Это я к тому, что каждая ситуация уникальна.

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

Желаю вам пореже общаться с такими людьми, которые почему-то считают себя программистами.

Romantik, Вы задали очень философский вопрос. На эту тему можно говорить годами и не прийти к единому мнению.
Например. Exception на странице - баг? Баг. Если Exception вылез - значит страница завалилась.
Один раз мои действия вызвали Exception. На что создатель фичи ответил: "всё было написано так, что подобные действия обязательно вызовут исключение. И исправить нельзя. Поэтому чинить не буду. Просто сюда, а потом сюда нажимать нельзя". Вот так баг стал не багом.
Это я к тому, что каждая ситуация уникальна.

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

Желаю вам пореже общаться с такими людьми, которые почему-то считают себя программистами.

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

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

Конечно, случаи разные бывают. Но из описания понятно, что баг не исчез, а остался. Меня-то это зацепило.
И сделать сообщение об ошибке, в случае если exception ожидаем ничего не стоит. Абсолютно. 5 минут фикс + 25 тестирование программистом, если конечно в программе вообще есть унифицированный механизм сообщения об ошибках.
Пользователю, в подавляющем большинстве случаев exception ничего не скажет, но сообщение вида "Ошибка возникла потому, что вы нажали сюда, а потом сюда. Так делать нельзя. Сначала надо нажать туда, а потом сюда" - скажет. И это решит проблему. Повторюсь. Это ничего не стоит и нормальный программист сможет легко найти путь исправления, и убедить руководителя, что 30 минут его времени будет потрачено не зря.

хорошая статья в тему:
http://habrahabr.ru/...testing/104952/