Грамматическая ошибка это баг - Не ошибается лишь тот, кто ничего не делает!

#1

Romantik

Новый участник

Members
19 сообщений

Город:Одесса

Отправлено 17 августа 2011 — 00:44

Привет всем!

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

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

Наверх

#2

Stanislavsky

Stanislavsky

Новый участник

Members
15 сообщений

Отправлено 17 августа 2011 — 06:58

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

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

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

Наверх

#3

Natalya Rukol

Отправлено 17 августа 2011 — 07:05

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

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

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

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

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

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

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

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

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

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

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

Наверх

#4

Natalya Rukol

Отправлено 17 августа 2011 — 07:36

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

Наверх

#5

Romantik

Romantik

Новый участник

Members
19 сообщений

Город:Одесса

Отправлено 17 августа 2011 — 09:43

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

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

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

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

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

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

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

З.Ы. «срок — вчера, и главное чтоб открывался!!!» :good:

Наверх

#6

Stanislavsky

Stanislavsky

Новый участник

Members
15 сообщений

Отправлено 17 августа 2011 — 14:37

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

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

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

Наверх

#7

Natalya Rukol

Отправлено 18 августа 2011 — 05:43

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

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

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

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

Наверх

#8

Фрося

Фрося

ФИО:Радилова Елена Игоревна

Отправлено 18 августа 2011 — 06:53

Хм..

Про

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

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

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

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

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

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

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

Почему-то по пятницам особо остро хочется быть блондинкой….

Наверх

#9

Vasiliy

Vasiliy

ФИО:Касимов Василий
Город:Москва

Отправлено 18 августа 2011 — 07:34

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

Наверх

#10

Фрося

Фрося

ФИО:Радилова Елена Игоревна

Отправлено 18 августа 2011 — 08:14

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

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

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

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

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

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

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

Почему-то по пятницам особо остро хочется быть блондинкой….

Наверх

#11

notProgrammer

notProgrammer

Город:Харьков

Отправлено 18 августа 2011 — 15:12

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

— Как называется человек, который любит смотреть на страдания других?
— Программист.

У тестировщика всегда чётное количество синяков: если он наступил на грабли — обязан воспроизвести ошибку.
(bash.org)

Наверх

#12

LeshaL

LeshaL

ФИО:Алексей Лянгузов
Город:Saint-Petersburg

Отправлено 22 августа 2011 — 09:10

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

Наверх

#13

LeshaL

LeshaL

ФИО:Алексей Лянгузов
Город:Saint-Petersburg

Отправлено 22 августа 2011 — 09:19

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

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

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

Наверх

#14

notProgrammer

notProgrammer

Город:Харьков

Отправлено 23 августа 2011 — 12:14

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

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

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

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

— Как называется человек, который любит смотреть на страдания других?
— Программист.

Наверх

#15

LeshaL

LeshaL

ФИО:Алексей Лянгузов
Город:Saint-Petersburg

Отправлено 23 августа 2011 — 19:51

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

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

Наверх

#16

camelot

camelot

Новый участник

Moderators
24 сообщений

ФИО:Andrew

Отправлено 24 августа 2011 — 12:24

Наверх

Источник

Допустим такую ситуацию когда ты нашел баг в каком-то софте и у тебя сразу же постает вопрос че с этим делать. Конечно ты можешь подойти к разработчику и сказать о баге и описать на пальцах как его воспроизвести, но это плохая практика так как разработчик ПО может сидеть в другой комнате, офисе или даже в другой стране и количество багов может быть настолько велико что их можно не запомнить и потом упустить. И если отвлекать разработчика по каждому мелочному багу и если их поднакопилось то это совсем не кошерно выходит потеря времени и отрыв от задач разработчика – не лучшее решение. Поэтому возникает само собой адекватное решение — документирование найденных багов с возможностью общего доступа к ним. Обычно в it компаниях баги документируют в баг-трекинговых системах.

Существует различное множество баг-трекинговых систем, которые позволяют нам не только создавать задачи, менять их статусы но и создавать баг репорты. Самые распространенные на сегодняшний день это Redmine, Bugzilla, Mantis, JIRA

Пример того как выглядит список баг репортов в JIRA:

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

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

Основные Поля в Баг Репорте

ID

Это уникальный идентификатор найденного бага

Summary

Краткое и лаконичное описание бага отвечающее на вопрос Что произошло и при каких условиях.
К примеру так «Newly-created Admin user can’t sign in to admin panel»
То есть описание бага должно быть такое чтобы программисту его даже можно было не открывать а сразу искать в чем же баг. Но чаще попадаются все же сложные баги которые и требуют описания внутри дополнительных действий и разъяснений как же его воспроизвести и как на самом деле должно быть, так что только по summary описать сложно. Поэтому существуют следующие, приведенные ниже поля:

Preconditions

Здесь пишется обычно то что нужно сделать перед выполнением наших шагов воспроизведения. Возможно нужно создать специальную структуру или юзеров с разными ролями или шаблонов нужных для воспроизведения этого бага.
К примеру если суть бага у нас что админ не может залогиниться в админ панель с правильными данными НО не могут залогиниться только ново созданные, то есть старые админы заходят как обычно и все ок.
То в это поле следует написать что нужно создать нового админа юзера
Так как шаги создания этого админа это не суть это бага то это действие можно вынести в это поле.

Steps to Reproduce

Поле используется для описания шагов воспроизвидения при которых наш баг воспроизведется.
К примеру
1) Open login page of admin panel
2) Enter valid credentials into «Username» and «Password» text fields
3) Press Enter button
Т. е. в этом поле описываются детальные шаги до того момента когда мы увидим баг
После последнего шага мы должны увидеть тот результат который и является багом в данной ситуации

Actual Result

Здесь мы описываем что мы получили на последнем шаге пройдя по всем шагам
К примеру это может быть описано так:
«You have entered incorrect user or password» message is displayed on login page

Expected Result

В этом поле пишут что же должно быть как должен повести себя софт на последнем шаге воспроизведения шагов.
С первого раза кажется ну зачем поле ну и так же все очевидно, но бывают очень сложные баги, при которых все вроде бы работает, но поведение которых не соответствует поведению которые заявлены в требованиях или устно со слов продакт овнера. Поэтому поле важно и нужно для заполнения

Project

Это дробдаун лист с названиями проектов
Если у вас в компании больше чем 1 проект то просто выбери свой проект в котором был найден баг

Build number

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

Priority

Это поле служит для определения приоритета бага, обычно выставляется проджект менеджером или скрам мастером, таким образом определяя первоочередность исправления бага на фоне остальных найденных багов, проводя таким образом очередность исправления багов
Различают такие приоритеты:
High: Наивысший, первоочередной
Medium: Среднего приоритета
Low: Самой последней значимости

Severity

Это поле указывает на серьезность ошибки. Существуют несколько уровней серьезность ошибки таких как:
Blocker: Ставиться если баг блокирует дальнейшую работу приложения или блокирует дальнейшее тестирование, к примеру такой баг что если создать пользователя с существующим именем, то никаким пользователем из всей системы мы не можем залогиниться так как показывается SQL ошибка на главной странице и никуда нельзя больше перейти
Critical: Ставиться при значительном влиянии на поведение ПО и некорректности поведения программы, но не блокирующую работу приложения, к примеру баг такой что пользователь может войти в систему без введения пароля
Major: Ставиться при незначительном влиянии на поведение ПО, и некритическом для нашего проекта, к примеру такой баг что если количество записей в списке записей подсчитывается неверно
Minor: Ставиться если влияние на функционал и поведение ПО баг не производит, к примеру это может быть грамматическая ошибка в названии чего либо

Assignee

Здесь выбираешь программиста который будет исправлять баг, также поле может быть недоступно так как проджект менеджер решает кому из разработчиков его отправить исходя из загруженности разработчиков и серьезности бага

Reporter

Обычно заполняется автоматически именем того кто создает баг репорт

Status

Статус поле заполняется автоматически в открытый, потом может меняется разработчиком, тестировщиком или проджект менеджером в зависимости от того на какой стадии находится наш баг. На рисунке изображены возможные статусы:

Comments

В комментариях можно указать что баг проверен и указать в каком билде проверял
Также можно задавать вопросы, ассайня на продакт овнера уточняя некоторые спорные моменты или детали реализации или исправления бага

В дополнение

к этим полям обычно есть возможность аттачить логи или скриншоты для удобства воспроизведения и выявления программистом в каком месте баг

Источник

Как Вы думаете, какой навык тестировщика — самый важный?

Написание тест-кейсов?

Тест-анализ?

Может автоматизация тестирования?

Что-то из soft-skills?

Умение работать в команде?

Как насчет поиска багов?

Написание хороших баг репортов — это самый важный навык тестировщика!

Почему?)

Потому что хороший баг репорт это:

экономия времени и сохранение нервов разработчика (не нужно тратить время на “понимание” ошибки и раздражающие разговоры “это баг — нет, это не баг”)
радость для бизнеса (исправления делаются быстро, повышается качество продукта)
удовольствие для клиента (все мы хотим пользоваться качественными продуктами)

Ни один другой навык не приносит столько пользы, как этот)

Вы можете быть супер-аналитиком, находить по 100 багов за день, общаться и дружить со всеми разработчиками. Но, если Вы не умеете создавать баг репорты — баги не будут исправляться. А если баги не будут исправляться… Вы сами можете догадаться, что произойдет 🙂

Научиться писать качественные баг репорты — просто!

Каким образом и что для этого нужно?

Читайте в этой статье)

Что такое Баг / Дефект?

Перед тем, как начать разговор о баг репортах, стоит очень хорошо разобраться, что такое “баг”, ведь его мы и будем описывать 🙂

Слово “баг” — это технический жаргон [1] [2]. Оно используется в разговорах, статьях и приложениях (Jira, TestRail и т.п.)

Стандарты [3] и книги [4] используют другое название — “дефект”, оно более профессиональное.

Так как это не научная статья, мы будем использовать слово “баг”, как более распространенное и привычное 🙂

Существует несколько определений бага:

Баг — это изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [3]
Баг — это проблема, которая может приводить к отказу приложения или получению неправильных результатов, если ее не исправить. [ISO 24765, перевод]
Баг — это недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа [4]

Данные определения описывают баги в коде и их сложно применить к багам в требованиях, UI / UX и т.п.

На этапе проверки требований у нас нет компонента, системы (см. определение 1,3) или приложения (определение 2). У нас есть только текст, который их описывает, если он вообще существует 😂

Более универсальное и доступное определение приведено в книге [4]:

Баг — это отклонение фактического результата от ожидаемого результата.

Здесь:

фактический результат — это то, что мы “видим” или то, что произошло после проделанных действий
ожидаемый результат — это ожидания наблюдателя, которые он получил из требований, спецификаций, любой другой документации, личного опыта и здравого смысла

Давайте рассмотрим несколько примеров багов.

Баг в функционале:

Существует функция, которая возвращает сумму чисел.
Передав ей значения sum(2, 2) мы должны получить 4 (ожидаемый результат)
Предположим, функция возвращает значение, отличное от 4, например 5 (фактический результат)
фактический результат ≠ ожидаемому результату (5 ≠ 4), значит это баг в логике функции

Баг в требованиях:

У нас есть требование, в котором указано, что дата регистрации клиента на сайте должна равняться 02.04.20 (фактический результат)
Здравый смысл подсказывает, что датой регистрации должна быть “текущая дата в момент регистрации” (ожидаемый результат)
Фактический результат ≠ ожидаемому результату, значит это баг в требованиях

Баг в UX:

Предположим, Вы открываете меню сайта на мобильном устройстве. Меню находится справа и занимает 70% ширины экрана. Слева появляется черный фон
Вы нажимаете на черный фон — ничего не происходит.
Опыт подсказывает, что после клика на фон меню должно закрываться (ожидаемый результат), но по факту — ничего не происходит (фактический результат)
Фактический результат ≠ ожидаемому результату, значит это баг в UX

Откуда берутся баги?

Баги являются следствием ошибок.

В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам [4].

Причин возникновения ошибок множество [5]:

Стресс
Спешка
Усталость, болезнь
Непонимание задания
Отсутствие коммуникации
Невозможность сконцентрироваться
Некомпетентность
Чрезмерная сложность ПО
Отсутствие документации / информации
…

Ошибки делают все и делают их всегда.

Это неотъемлемая часть природы человека и ее невозможно изменить или обойти.

Лучшие спортсмены, ученые, инженеры, политики, актеры, музыканты — ошибаются. Бизнес-аналитики, разработчики, тестировщики, дизайнеры, администраторы, переводчики и т.п. — не исключение…

Заблуждение об отсутствии ошибок — это один из принципов тестирования.

Все ли баги нужно исправлять?

Нет, не все.

В идеальном мире — наверное да, но мы не знаем где он 🙂

Что мы знаем, так это то, что все люди ошибаются. Тестировщики тоже. Иногда Вы можете замечать вещи, которые багами не являются.

Это может происходить потому что вы:

Не знаете правильный ожидаемый результат (из-за плохой коммуникации / недостаточного описания требований / недостаточного опыта)
Допустили ошибку в ходе тестирования (например, перепутали порядок “шагов” проверки, или поменяли значение в базе данных не там, где нужно было)

Ситуация, когда Вы создаете “ложный” баг репорт — называется false-fail result [3].

Такие “моменты” характеризуют качество документации, качество подготовки к тестированию, качество проведения тестирования и анализируются QA (Вы ведь уже знаете, что QA ≠ тестирование?)

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

Вряд ли кто-то будет заниматься ошибкой, исправление которой стоит $1000 в то время как она затрагивает всего 0.002% пользователей, не приносящих ценности компании.

Zero bug policy — отличный процесс работы с багами при использовании гибкой разработки

Жизненный цикл бага

Каждый найденный баг всегда проходит через конкретные “этапы”, которые называются жизненный цикл бага.

Цикл, его этапы и переходы между ними сильно зависят от процесса тестирования и разработки, используемого в компании. Поэтому здесь приводится базовый процесс, этапы которого существуют в 99% случаев. Он прост для понимания, но помните, в реальном мире все немного сложнее 🙂

Не путайте жизненный цикл бага и жизненный цикл ПО — это не связанные вещи!

Жизненный цикл бага

Давайте рассмотрим каждый этап и переходы между ними подробнее.

Этапы жизненного цикла бага

1. Открыт (Open) — баг создан, оформлен и передан разработчику / команде разработки

2. В Работе (In Progress) — ведутся работы по исправлению

3. Исправлен (Ready for check) — баг исправлен и передан тестировщику на повторную проверку

4. Закрыт (Closed) — баг проверен и больше не воспроизводится

Переходы бага между этапами жизненного цикла

Переходы между этапами жизненного цикла пронумерованы в соответствии с нумерацией списка ниже.

1. Открыт — Закрыт. Если баг — это “не баг”, он может сразу быть закрыт, без промежуточных операций.

Иногда этот переход выносят в отдельный этап жизненного цикла, который называется Отклонен (Rejected). Он используется для анализа процесса тестирования или оценки работы тестировщиков / разработчиков.

На некоторых сайтах можно прочитать, что “баг отклоняется разработчиком, если он считает, что дефект не важен”.

Мы считаем, что это не верно, потому что мнение разработчика — субъективное. Теоретически, он может “отклонять” баг если:

Он не знает как исправить ошибку (из-за некомпетентности / низкой квалификации)
Он не хочет исправлять ошибку, потому что правка требует больших затрат времени и сил, а сегодня пятница (лень)
Он не понимает, в чем заключается ошибка(например, из-за плохого оформления баг репорта или отсутствия / незнания требования)

Если происходит отклонение бага, разработчик должен аргументированно описать, почему он не считает найденную неточность багом, а решение про исправление или закрытие должен принимать человек, который отвечает за качество (QA, PO, PM).

2. Открыт — В Работе. Баг подтвержден и передан разработчикам, которые начали работу над исправлением.

3. В Работе — Закрыт. Бывает, что в ходе исправления ошибки разработчик понимает, что это не ошибка, а что-то другое. (фича / неточность в требованиях, которую обсудили без тестировщиков и т.п.) В этом случае разработчик описывает, почему это не баг, и закрывает задачу.

Иногда этот переход выносят в отдельный этап жизненного цикла, Не Баг (Not A Bug). В таком случае задача возвращается тестировщикам, они ее пересматривают и либо закрывают, соглашаясь с разработчиком, либо исправляют описание и заново открывают.

Появление большого количества багов в статусе “Не Баг” говорит о проблемах в коммуникации и / или документации.

4. В Работе — Исправлен. Ошибку локализовали и исправили, она передана тестировщику.

5. Исправлен — Открыт. Тестировщик проверил исправление, баг все еще воспроизводится, то есть не исправлен. Он возвращается разработчику (возможно с указанием каких-то дополнительных деталей)

Этот переход может существовать как отдельный этап жизненного цикла бага — Переоткрыт (Reopened).

Появление большого количества багов в статусе “Переоткрыт” может говорить о проблемах в оформлении багов и использоваться для анализа качества работы тестировщиков.

6. Исправлен — Закрыт. Тестировщик проверил исправление, баг больше не воспроизводится.

7. Закрыт — Открыт. Если баг случайно закрыли, должна быть возможность его переоткрыть.

Не стоит переоткрывать закрытые баги, если они уже были исправлены, проверены и закрыты. Ситуация может возникать в ходе регрессионного тестирования.

Такой “операцией” Вы испортите аналитику и метрики + создадите путаницу в релизах и процессе работы и т.п.

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

Теперь, когда мы разобрались с багами, причинами их возникновения и жизненным циклом — мы можем переходить к рассмотрению баг репорта 🙂

Что такое баг репорт (bug report)?

Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]

Мы уже знаем, что такое баг, поэтому определение можно упростить.

Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.

Другие названия этого документа:

баг-репорт
отчет о дефекте
defect report

Зачем нужны баг репорты?

Почему баги нельзя исправлять сразу, зачем писать отчеты? Лишняя работа, только время тратить… — типичный менеджер, который не слышал о качестве

Написание баг репортов — чрезвычайно полезный процесс, потому что:

1. Происходит фиксации факта существования бага

Есть репорт — есть прецедент для реакции.
Нет репорта — никто ничего не будет делать.

Именно поэтому не стоит писать баги в скайп / чат / говорить лично и т.п.

Есть вероятность, что о нем забудут (и вы, в том числе) и не исправят.

Потом баг найдет либо заказчик в ходе приемочного тестирования, либо клиент — и вряд ли они будут этому рады… Вы тоже не будете рады, когда разработчик скажет, что он впервые это видит.

2. Баг репорт помогает разработчику

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

В докладе Егора Бугаенко Testing and Testers на TestCon 2020, именно об этом был 4-ый вопрос и объяснения, почему это важно. Рекомендую посмотреть 🙂

3. Появляется возможность приоритизации исправлений

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

4. Появляется возможность анализа ошибок

Имея информацию о найденных дефектах Вы можете определять первопричины их возникновения и вносить изменения в рабочие процессы, чтоб их предотвращать. (Привет QA)

5. Тестировщик содействует устранению бага

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

6. Появляется возможность контроля этапа исправления бага

Вы уже знаете, что до момента исправления, каждый баг проходит через определенные стадии жизненного цикла.

Наличие отчета о дефекте с изменяющимся статусом позволяет легко и быстро определять точное “положение” бага и контролировать его исправление.

7. Появляется возможность оценки качества продукта в текущий момент времени

Если в ходе тестирования было найдено 50 багов и все они были оформлены как баг репорты — вы, как менеджер, сможете оценивать готовность продукта, оценивать объем требуемых доработок, принимать решения о релизе и т.п.

Отчеты о дефектах дают командам очень полезную и важную информацию, которая необходима для контроля качества продукта.

Именно поэтому навык написания хороших отчетов критически важен для любого профессионала-тестировщика и его нужно освоить в совершенстве 😉

Атрибуты баг репорта

Баг репорт — это технический документ.

У него есть некий набор атрибутов (полей, параметров) для структуризации информации.

Атрибуты баг репорта можно разделить на 2 группы:

Основные — содержат обязательную информацию, которая должна присутствовать в описании каждого бага
Дополнительные — дают дополнительную информацию, которая помогает разработчику быстрее локализовать и найти ошибку

Основные поля

ID — уникальный идентификатор бага
Заголовок / Краткое описание / Тема / Summary / Title — четко и кратко описывает суть бага. Оформляется в виде одного предложения, состоящего из трех частей отвечающих на вопросы “Что? Где? Когда?”. Редко бывает, что ответ на вопрос “Где?” или “Когда?” может опускаться, если он не дает полезной информации. (примеры заголовков можно найти в разделе Серьезность)
Шаги к воспроизведению — четкое, последовательное описание шагов / действий, которые необходимо совершить, чтоб воспроизвести баг со всей необходимой информацией
Фактический результат — результат, который мы видим
Ожидаемый результат — результат, который мы хотели / ожидали увидеть
Серьезность — показывает, насколько серьезные последствия от дефекта с точки зрения влияния на систему (см. раздел Серьезность)

Дополнительные поля

Скриншот / видео — изображение / видео, которое четко и наглядно демонстрирует баг. Если видео или скриншот сделан качественно, его может быть достаточно для понимания сути ошибки и ее исправления
Требование — ссылка на требование, которое не соблюдено. Наличие этой информации в 99% случаев предотвращает разговор “баг — не баг” и испорченное настроение 🙂
Тип бага — для анализа “слабых” мест в ПО, баги могут разделять на типы (см. Тип бага)
Приоритет — очередь, в которой баг будет исправляться (Высокий -> Средний -> Низкий)
Дополнительные файлы — файлы, которые нужны для воспроизведения бага (файлы определенного размера, типа, логи и т.п.)
Окружение — информация об окружении, на котором воспроизводится баг (версия браузера, операционная система, размер экрана, тестовый сервер и т.п.)
Статус — текущий статус бага в его жизненном цикле (Открыт, В работе…)
Автор — человек, который создал баг (нужен для уточнения информации, если потребуется)
Исполнитель — человек, которые работает над багом в данный момент времени
Комментарии — обсуждение исправления ошибки
Версия — версия ПО, в которой был обнаружен баг
Версия исправления — версия ПО, в которую будет добавлено исправление бага

Серьезность бага (Bug Severity)

Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.

Приведенные ниже уровни — не стандартизированы и могут отличаться в разных компаниях.

S4 | Blocker

Блокирующий — баг описывает ситуации, когда ПО не работает в принципе.

Примеры:

Не открываются страницы сайта (показывается белый фон / 404 / 50Х ошибка)
Не запускается мобильное приложение после нажатия на иконку на рабочем столе
Зависает интерфейс приложения после нажатия на кнопку «купить» (кнопки перестают нажиматься, приложение невозможно свернуть и т.п.)

S3 | Critical

Критический — баг влияет на критический функционал или критические данные.

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

Примеры критических функций в разных приложениях:

Баннера на сайте Х (приведение новых клиентов на сайт Y с использованием баннеров — основная функция сайта Х)
Форма логина на сайте Y (без логина — клиент не может попасть на форму заказа и оформить его, а это одна из основных функция сайта Y)
Форма оплаты на сайте Y (без формы оплаты — клиент не сможет оплатить свой заказ — самый критический функционал сайта Y)

Помимо критического функционала, к критическим багам относятся:

“Дыры” в безопасности системы
Полная / частичная потеря работоспособности системы на ощутимый промежуток времени, вызванная падением сервера
Проблема, которую пользователь не сможет обойти своими силами
1. например, если открытое модальное окно можно закрыть только нажатием на крестик, и нажатие не срабатывает на iOS

Примеры:

Указана неправильная ссылка на баннере в сайдбаре на странице Х
Отсутствует ограничение максимальной длины вводимых в поле Name данных на странице Donate
Показывается сообщение о серверной ошибке (503) на странице /signin после попытки логина
Показывается сообщение NGINX 404 error на главной странице блога Y
Не закрывается меню сайта после нажатия на крестик / черный фон

S2 | Major

Серьезный — баг не влияет на критический функционал, но создает неудобства при использовании приложения / системы.

К этому уровню относятся баги, связанные с:

Некритическим функциональными требованиями
Некритическим нефункциональными требованиями
Серьезными визуальными отклонениями в дизайне

Примеры:

Не отображается плашка New на странице /order-details
Не отображаются OG / Twitter microdata на странице X
Неправильный порядок блоков “What we do?” и “How about now” на странице Х

S1 | Minor

Незначительный — баг не влияет на бизнес логику приложения.

Чаще всего к этому уровню относятся баги в реализации UI (верстке), отсутствие переводов и т.п.

Примеры:

Не отображается ссылка /free-page в блоке “Free Products” в футере
Не переносится на новую строку / Не обрезается текст ссылки “Our TOP 20 projects” в блоке «How it works?» на странице Х
Не соответствует макету цвет текста в блоке Contact в футере

S0 | Trivial

Тривиальный — баг никак не влияет на качество продукта.

Из-за того, что такие баги не влияют на качество продукта, преднамеренно их не исправляют (они не “окупаются”). Обычно, правку делают в ходе реализации смежной задачи.

Примеры:

Отсутствует точка в конце предложения “This is whatever“ на странице Х
Отображается не актуальный год в футере сайта Х

Типы багов

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

Используемые типы багов определяются в зависимости от направления, размера и сложности проекта.

Приведенные ниже типы багов относятся к WEB сайтам.

UI (ошибка в верстке)

Баг в верстке — следствие ошибки в разметке (HTML) или стилизации (CSS) элемента страницы в специфическом окружении.

Примеры:

Не отображается блок Х на странице Y (в дизайне блок есть, на странице — нет)
Неправильное расположение блока на странице X (в дизайне блок слева, на странице — справа)
Не переносится на новую строку / Не обрезается текст ссылки “Our TOP 20 projects” в блоке «How it works?» на странице Х

UX (ошибка в удобстве)

Баг в удобстве — неудобство / нелогичность работы с элементами / функционалом страницы.

Примеры:

Не получается с первого раза нажать на кнопку Х в футере на мобильном (очень маленькая зона клика, кнопку нужно сделать больше)
Удаляется заказ после нажатия на кнопку Х в модальном окне на странице Б (ожидаешь закрытия окна, а фактически удаляется заказ — UX путает)

Functional (ошибка в функционале)

Баг в функционале — несоответствие логики работы компонента заявленным функциональным требованиям.

Примеры:

Отображается неправильное количество ссылок в блоке Related Papers в sidebar
1. требование: выводить 5 ссылок
2. фактически: выводится 10 ссылок
Не происходит прокрутка страницы вверх после нажатия на кнопку To Top
1. требование: происходит прокрутка страницы вверх после нажатия на кнопку To Top
2. фактически: ничего не происходит
Не показалось сообщение об ошибке при вводе числа в поле Name
1. требование: допустимые символы для поля Name = буквы (обязательны) + пробелы (не обязательны). При вводе других символов — показываем сообщение об ошибке.
2. фактически: сообщение об ошибке не отображается
Не отображается модальное окно А после нажатия на кнопку Х
1. требование: после нажатия на кнопку X показывается окно А
2. фактически: после нажатия на кнопку X показывается окно С
Не отображается текст “Нет заказов” на профиле райтера, если количество заказов, назначенных райтеру = 0
1. требование: отображается текст “Нет заказов“, если количество заказов на профиле райтера = 0
2. фактически: не отображается текст “Нет заказов“, если количество заказов на профиле райтера = 0

SEO (ошибка в seo)

Баг в seo — ошибка, которая влияет на SEO (нарушение нефункциональных требований, касающихся seo).

Примеры:

Отображается неправильная структура заголовков блоков на странице Х
Найдены 4 ошибки на странице Х после проверки в w3c валидаторе
Указан неправильный title на странице Х
Закрыта для индексации страница Х
Отсутствует атрибут ALT на изображении Z на странице Х

Алгоритм создания баг репорта

Предположим, Вы нашли баг и приступаете к написанию баг репорта.

С чего начать?

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

Понять “суть” проблемы, а не ее проявление (если получится, но это требует технических знаний)
Воспроизвести дефект один-два раза (удостовериться, что он повторяется)
Проверить наличие найденного вами дефекта в системе управления дефектами (возможно, баг уже создали)
Написать заголовок (отвечает на вопросы “что? где? когда?”)
Написать основные поля отчета
Заполнить дополнительные поля отчета
Внимательно прочитать отчет. Убрать лишнее, добавить нужное!
Еще раз перечитать отчет! (самый важный пункт)
Сохранить отчет
Переназначить отчет либо проверяющему (если такой есть) либо разработчику (который будет исправлять ошибку)

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

Пример хорошего баг репорта (bug report example)

Предположим, в ходе исследовательского тестирования Вы заметили следующее:

Пример UI дефекта (скриншот из баг репорта)

И Вы хотите создать отчет о найденном баге (нет перевода текстов ошибок).

Итоговый вариант может выглядеть так:

Заголовок / Краткое описание / Тема / Summary / Title

Не переведены на украинский язык тексты ошибок (что?) на форме “Зворотний зв’язок” на странице https://itawards.ua/ua (где?) в UA версии сайта (когда?)

Скриншот / видео

Скриншот / ссылка на скриншот

Шаги к воспроизведению

Открыть страницу https://itawards.ua/ua
Проскролить к форме “Зворотний зв’язок”
Нажать на кнопку “Надіслати”
Обратить внимание на язык ошибок, которые появились под полями формы

Фактический результат

Отображаются ошибки на английском языке

Ожидаемый результат

Отображаются ошибки на украинском языке

Серьезность

S1 (minor)

Кто внимательно рассмотрел изображение с багом (или решил сам протестировать форму) — мог заметить еще несколько “странностей”.

Например, некоторые тексты ошибок содержат грамматические ошибки, атрибуты полей содержат свойство autocomplete, которое не работает в большинстве браузеров, а анимация на форме зависает при наведении на любой из прямоугольников.

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

The Devil is in details.

Пример баг репорта в Jira

Jira является одной из самых распространённых систем управления проектами в мире и очень часто используется в ИТ.

Так может выглядеть описанный выше баг репорт в Jira:

Пример баг репорта в Jira

Открыть полное изображение в новой вкладке

Здесь:

красным отмечены основные поля
синими отмечены дополнительные поля

Основные поля являются обязательными для заполнения при создании бага, без них задача просто не сохраниться 🙂

Ошибки при создании баг репорта

Создание хороших баг репортов требует определенных знаний, навыков и опыта.

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

Заголовок не отвечает на вопросы “Что? Где? Когда?”
Заголовок содержит лишнюю информацию (версии, окружения, учетные данные пользователей и т.п.)
Отсутствуют шаги для воспроизведения
Шаги для воспроизведения излишне детализированы
Отсутствует фактический и / или ожидаемый результат
Отсутствует ссылка на требование, которое проверялось (если такое есть)
Отсутствие скриншота / видеозаписи для UI/UX багов (сюда можно также добавить отсутствие выделения ошибки на скриншоте)
Грамматические ошибки / Техническая безграмотность / Использование “жаргона”

Знание типичных ошибок помогает проверять самого себя (можно создать чек-лист) и позволяет создавать более качественные отчеты без возвратов на доработку!

Резюме

В статье мы рассмотрели все, что нужно знать начинающему тестировщику о багах, баг репортах и их жизненном цикле.

Мы поняли, что баг репорты — это чрезвычайно важные документы, потому что именно они описывают найденные в процессе тестирования дефекты, исправление которых и повышает качество продукта.

И именно правильное и качественное оформление баг репортов является ключевым навыком тестировщика.

Если у вас есть вопросы или предложения — пишите нам в Телеграм!

Если вам интересно тестирования и Вы хотите получать актуальную информацию по этой теме — подписывайтесь на наш Tелеграм канал. У нас очень интересно: статьи, видео, тесты, опросы, нет спама 😉

Источники

Баг (значения) // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Баг_(значения) (дата обращения: 28.10.2020).
Программная ошибка // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Программная_ошибка (дата обращения: 28.10.2020).
ISTQB Глоссарий Терминов Тестирования 2.3 [https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB%20%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B8%CC%86%20%D0%A2%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%BE%D0%B2%20%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%202.3.pdf]
Куликов С. Тестирование программного обеспечения Базовый курс. — 3 изд. 2020. — 298 с.
Программа подготовки ISTQB Базового уровня 2018
[https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_Syllabus_2018-RU.pdf]

FAQ

Что такое баг?

Баг — это отклонение фактического результата от ожидаемого результата.

Здесь:
— фактический результат — это то, что мы “видим” или то, что произошло после проделанных действий
— ожидаемый результат — это ожидания наблюдателя, которые он получил из требований, спецификаций, любой другой документации, личного опыта и здравого смысла

Откуда берутся баги?

Баги являются следствием ошибок.

В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам.

Что такое баг репорт (bug report)?

Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.

Что такое Серьезность бага (Bug Severity)?

Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.

Источник

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Написание баг репорта

Баг репорт — это технический документ и в связи с этим хотим отметить, что язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.).

Требования к обязательным полям баг репорта

Отметим, что обязательными полями баг репорта являются: короткое описание (Bug Summary), серьезность (Severity), шаги к воспроизведению (Steps to reproduce), результат (Actual Result), ожидаемый результат (Expected Result). Ниже приведены требования и примеры по заполнению этих полей.

Короткое описание

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

Приложение зависает, при попытке сохранения текстового файла размером больше 50Мб.
Данные на форме «Профайл» не сохраняются после нажатия кнопки «Сохранить».

В дополнение предлагаем вам изучить Принцип «Где? Что? Когда?», описанный на страницах блога «QA Nest»:

«В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:

Где?: В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не предлога.

Что?: Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.

Когда?: В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Почему последовательность должна быть именно такой?
В таком виде незнакомые дефекты удобнее сортировать по summary как показывает практика (ведь, скорее всего, именно среди дефектов других инженеров будет производиться поиск дубликатов). Если вы другого мнения — придумайте свою последовательность, но она должна стать единой для всех без исключения членов проекта, иначе вы не добьетесь необходимого результата.»

Серьезность

В двух словах можно отметить, что если проблема найдена в ключевой функциональности приложения и после ее возникновения приложение становится полностью недоступно, и дальнейшая работа с ним невозможна, то она блокирующая. Обычно все блокирующие проблемы находятся во время первичной проверки новой версии продукта (Build Verification Test, Smoke Test), т.к. их наличие не позволяет полноценно проводить тестирование. Если же тестирование может быть продолжено, то серьезность данного дефекта будет критическая. На счет значительных, незначительных и тривиальных ошибок вопрос достаточно прозрачный и на наш взгляд не требует лишних объяснений.

Шаги к воспроизведению / Результат / Ожидаемый результат

Очень важно четко описать все шаги, с упоминаем всех вводимых данных (имени пользователя, данных для заполнения формы) и промежуточных результатов.

Например:

Шаги к воспроизведению
1. Войдите в системы: Пользователь Тестер1, пароль xxxXXX
—> Вход в систему осуществлен
2. Кликните линк Профайл
—> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени пользователя сохранено.

Основные ошибки при написании багов репортов

Недостаточность предоставленных данных
Не всегда одна и таже проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому настоятельно рекомендуется вносить все необходимые данные в баг репорт

Определение серьезности
Очень часто происходит либо завышение, либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы.

Язык описания
Часто при описании проблемы используются неправильная терминология или сложные речевые обороты, которые могут ввести в заблуждение человека, ответственного за решение проблемы.

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

Заполнение полей баг репорта

В описанной ниже таблице представлены основные поля баг репорта и роль работника, ответственного за заполнение данного поля. Красным цветом выделены обязательные для заполнения поля:

Поле	Ответственный за заполнение поля
Короткое описание (Summary)	Автор баг репорта (обычно это Тестировщик)
Проект (Project)	Автор баг репорта (обычно это Тестировщик)
Компонент приложения (Component)	Автор баг репорта (обычно это Тестировщик)
Номер версии (Version)	Автор баг репорта (обычно это Тестировщик)
Серьезность (Severity)	Автор баг репорта (обычно это Тестировщик), однако данный атрибут может быть изменен вышестоящим менеджером
Приоритет (Priority)	Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
Статус (Status)	Автор баг репорта (обычно это Тестировщик), но многие системы баг трекинга выставляют статус по умолчанию
Автор (Author)	Устанавливается по умолчанию, если нет, то указывается имя автора баг репорта
Назначен на (Assigned To)	Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
ОС / Сервис Пак и т.д. / Браузера + версия / …	Автор баг репорта (обычно это Тестировщик)
Шаги воспроизведения (Steps to Reproduce)	Автор баг репорта (обычно это Тестировщик)
Фактический Результат (Result)	Автор баг репорта (обычно это Тестировщик)
Ожидаемый результат (Expected Result)	Автор баг репорта (обычно это Тестировщик)
Прикрепленный файл (Attachment)	Автор баг репорта (обычно это Тестировщик), а также любой член командной группы, считающий, что прикрепленные данные помогут в исправлении бага

Наверх

В предыдущей статье мы узнали, как написать баг-репорт. Но многие компании работают на иностранном языке. Что делать, если написать репорт на английском нужно прямо сейчас, и вариант “идти учиться” не подходит?

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

Хорошая новость: эта статья поможет вам справиться.

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

Bug Summary – краткое описание
Severity – серьезность
Steps to reproduce – шаги к воспроизведению
Actual Result – результат
Expected Result – ожидаемый результат

Онлайн-переводчики не идеально справляются со слэнговыми выражениями или выражениями с разными вариантами перевода, которых достаточно в сфере тестирования, поэтому их тоже стоит запомнить и переводить отдельно. Например, “выбрать что-то” (поле, кнопку и т.д.) в тестировании будет “select”, а не “choose”, а “посмотреть на…” — это look at, а не see. Другие полезные глаголы:

Hover the mouse over… — навести мышь на…
Zoom in/out — приблизить/отдалить;
Scroll — пролистать с помощью мыши или скроллера;
Fill in the required fields — заполнить обязательные поля;
Spread — растянуть на сенсорном экране.

Помимо словарного запаса не менее важна и грамматика. Вот некоторые правила, которые помогут понять вас с первого раза.

Используйте повелительное наклонение в описании шагов воспроизведения. Избегайте использования “to”. В примере на картинке ниже — не to select, а просто select.
Избегайте окончания ing. Не going, а go to the basket.
Окончание “s” добавляется к глаголам, относящимся к местоимениям he, she, it. Например, the bug (it) appearS… Если местоимение — I, you, we, they, то окончание нулевое. Например, the bugs (THEY) appear_ …
Артикли a/the. “a” употребляется с исчисляемыми существительными в единственном числе. “the” — с с существительными единственного и множественного числа, обозначающих что-то конкретное, «то самое»; теми, которые уже упоминались в тексте ранее. Стоит отметить, что правила употребления артиклей куда обширнее, поэтому уместить все в этой статье невозможно. Для полного представления советуем почитать профильные уроки конкретно по артиклям.
Конструкция “when/after/before doing something” означает “во время/до/после выполнения чего-либо”. Например, the field cannot be selected after entering a date — “поле не может быть выбрано после введения даты”.

Конечно, эти пункты не охватывают все нюансы английского языка, и в работе вам не раз придется объяснять, что же вы все-таки имели в виду в вашем баг-репорте. А чтобы поскорее пройти эту стадию, советуем записаться на наш курс английского для тестировщиков, который стартует 1 ноября!

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

Ответ на топик «Распространенные ошибки при составлении баг-репортов».

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.

Снова воспроизвелась? Ура! А теперь минимизируйте количество шагов для воспроизведения, удостоверьтесь, что нет ничего лишнего.
Если используются какие-то входные данные, удостоверьтесь, что и они не содержат лишнего (действительно ли весь этот здоровенный кусок текста роняет редактор, а не один символ из него?).
Когда вы поняли, какие именно данные и какие ваши действия приводят к проблеме, кратко сформулируйте ее суть — придумайте заголовок баг-репорта. Опишите проблему настолько подробно и конкретно, насколько позволяет заголовок, при этом не увлекаясь его длиной
Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»
Пример «более хорошего» заголовка: «Редактор зависает при вставке текста, содержащего символ N, из буфера обмена по Ctrl+V»
Allenary: Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.

Старайтесь не писать фразы типа «я кликаю на ссылку», «я нажимаю кнопку» и им подобные. И заголовок, и описания шагов — это руководство к действию для тех, кто будет исправлять проблему, поэтому лучше формулировать как «кликнуть на ссылку», «нажать на кнопку».

Теперь откройте баг-трекер, начните заполнять форму баг-репорта.
Запишите заголовок.

В каких-то баг-трекерах поля «Подробное описание» и «Шаги для воспроизведения» различаются, в каких-то — нет.

Если поле «Подробное описание» есть, опишите в нем проблему более подробно — уточните те детали, которые пришлось опустить в заголовке. Если вы понимаете, в чем причина проблемы (используется устаревшая формула для расчетов, не учитывается какое-то значение и т.д.) — тоже пишите все здесь. Если не знаете — лучше не гадайте.
Если в форме записи об ошибке нет отдельного поля Affect version (версия продукта, в котором проявляется проблема), то укажите версию здесь.

«Шаги для воспроизведения» — основное поле для заполнения в баг-репорте.
Запишите шаги, которые вы определили. Как уже было сказано, шагов должно быть необходимо и достаточно для воспроизведения проблемы. Лишние не пишите. Необходимых тоже не пропускайте
После описания шагов обязательно напишите результат — что получилось.
Далее здесь же опишите ожидаемый результат, если это необходимо. Конечно, не стоит писать «Редактор не падает», но если, например, результаты расчетов не соответствуют ожидаемым, то это надо указывать.
Таким образом, описание шагов для воспроизведения должно выглядеть как-то так:

Шаги для воспроизведения:
1. Открыть…
2. Кликнуть…
3. Ввести в поле… значение N1
4. Ввести в поле… значение N2
4. Кликнуть кнопку Calculate

Результат:
В поле Result отображается V1.

Ожидаемый результат:
В поле Result отображается V2.

Если требуются исходные файлы, данные, дампы и пр. — сразу приаттачьте. Само собой, файлы должны содержать только информацию, необходимую для воспроизведения ошибки. Подчистите все лишнее.
Если проблема с визуальным отображением, то скриншот обязателен — можно будет понять ошибку и без воспроизведения шагов. Khizhnyak: На скриншотах лучше указывать место с ошибкой. Стрелочкой или просто полосой контрастного цвета. Здорово ускоряет «чтение» скриншота.

Но вставлять скриншоты в каждый баг-репорт совершенно не обязательно: пожалуйста, не плодите лишних сущностей. Если он ничем не поможет в воспроизведении проблемы — не тратьте время на его изготовление.

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

По остальным полям.
Severity, Priority.
Наличие этих полей и значения в этих полях отличаются от багтрекера к багтрекеру.
Severity — это критичность бага с точки зрения тестировщика: фича, опечатка в тексте, мелкая проблема, значительная проблема, падение продукта, блокирующая проблема и пр.
Priority — приоритет, с которым проблема должна быть исправлена.
Если есть оба поля, то тестировщик, как правило, выставляет только Severity, а Priority — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.

Environment — есть во всех баг-трекерах. Это программно-аппаратное окружение, в котором проявляется проблема.
Укажите версию операционной системы, наличие сервис-паков, разрядность.
Если ваш проект зависит от каких-то компонентов — их наличие и версии обязательно! .NET, JRE/JDK и прочие SDK.
Интерпретируемый язык? Версию интерпретатора — обязательно!
Для веб-проектов — браузер, установленные плагины, если это влияет на работу проекта. Если что-то не работает в одном браузере, то проверьте, работает ли в остальных.

В какой версии исправить, на кого назначить — зависит от политики внутри компании. Не знаете, что поставить? Спросите коллегу.

Статья дополнена правильными замечаниями из комментариев.

Пример того как выглядит список баг репортов в JIRA:

Основные Поля в Баг Репорте

ID

Это уникальный идентификатор найденного бага

Summary

Preconditions

Steps to Reproduce

Actual Result

Expected Result

Project

Build number

Priority

Severity

Assignee

Reporter

Обычно заполняется автоматически именем того кто создает баг репорт

Status

Comments

В дополнение

Зачем нужен хороший баг-репорт?

Если ваш отчет об ошибках (баг-репорт) составлен правильно, то шансы на быстрое исправление этих багов — выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Составление отчетов об ошибках — не что иное, как навык, и сейчас мы рассмотрим, как его сформировать.

«Смысл написания отчета о проблемах (баг-репорта) состоит в том, чтобы исправить эти проблемы» — Cem Kaner. Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима.

Это может повредить рабочему настрою тестировщиков, затронуть их профессиональную гордость, их эго.

Каковы качества хорошего баг-репорта в разработке программного обеспечения?

Любой может написать баг-репорт. Но не каждый может написать эффективный бар-репорт.

Вы должны уметь хорошо различать баг-репорт среднего качества и хороший баг-репорт. Как отличить хороший и плохой баг-репорты? Это очень просто, примените следующие характеристики и методы, чтобы качественно сообщить об ошибке.

Характеристики и методы включают в себя:

1) Наличие четко определенного номера ошибки:

Всегда присваивайте уникальный номер каждому сообщению об ошибке. Это, в свою очередь, поможет вам четко идентифицировать запись об ошибке. Если вы используете какой-либо инструмент автоматического формирования баг-репортов, то этот уникальный номер будет генерироваться автоматически каждый раз, когда вы делаете отчет.
Запишите номер и краткое описание каждой ошибки, о которой вы сообщили.

2) Воспроизводимость:

Если найденная вами ошибка не воспроизводима, то она никогда не будет исправлена.

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

3) Будьте конкретны:

Не пишите очерк о проблеме.

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

Эффективный баг-репортинг

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

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

Правильно составленный текст отчета про найденный баг очень важен для регистрации ошибки. Один из важных моментов, которые должен иметь в виду тестер, — это не использовать командный тон в отчете. Такой тон нарушает моральное состояние коллектива и создает нездоровые рабочие отношения. Используйте нейтральный тон.

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

Дубликаты ошибок — это постоянная проблема в цикле тестирования. Проверяйте весь список обнаруженных багов. Иногда разработчики могут знать о наличествующей проблеме и игнорировать ее в будущем выпуске. Используйте специальные инструменты, такие как Bugzilla, который автоматически ищет дубликаты ошибок. Тем не менее, лучше всего дополнительно вручную искать дубликаты ошибок.

Четко указывайте информацию об ошибке: «Как?» и «Где?». Отчет должен ясно показывать, как был выполнен тест и где именно произошел дефект. Читатель отчета должен легко воспроизвести ошибку и найти ее.

Имейте в виду, что цель написания баг-репорта — дать разработчику возможность визуализировать проблему. Он/она должен четко понимать суть дефекта, прочитав отчет об ошибке. Не забудьте предоставить всю необходимую информацию, которую ищет разработчик.

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

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

Следовательно, лучше всего разбить большие проблемы на отдельные баги. Это гарантирует, что каждая ошибка может быть обработана отдельно. Хорошо написанный баг-репорт помогает разработчику воспроизвести ошибку на своем терминале. Это помогает им также правильно диагностировать проблему.

Как сообщить об ошибке?

Используйте следующий простой шаблон баг-репорта:

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

Составитель отчета: Ваше имя и адрес электронной почты.

Продукт: В каком продукте вы нашли эту ошибку.

Версия: Версия продукта с ошибкой, если таковая имеется.

Компонент: Основные подмодули продукта.

Платформа:

Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.

Операционная система:

Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.

Приоритет:

Когда следует исправлять ошибку? Приоритет обычно устанавливается от P1 до P5. P1 следует понимать, как «исправить ошибку с наивысшим приоритетом» и P5 — «исправить, если позволяет время».

Серьезность ошибки:

Описывает влияние ошибки.

Типы Серьезности ошибки:

Блокировщик (Blocker): дальнейшая работа по тестированию невозможна.
Критическая (Critical): сбой приложения, потеря данных.
Major: серьезная потеря функциональности.
Minor: незначительная потеря функциональности.
Незначительная (Trivial): некоторые улучшения пользовательского интерфейса.
Улучшение (Enhancement): запрос новой функции или некоторого улучшения существующей.

Статус ошибки:

Когда вы регистрируете ошибку в любой системе отслеживания ошибок, то по умолчанию статус ошибки будет «Новый».

Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.

Назначить разработчику:

Если вы знаете, какой разработчик отвечает за тот конкретный модуль, в котором произошла ошибка, вы можете указать адрес электронной почты этого разработчика. В противном случае оставьте это поле пустым, так как это присвоит полю авторства ошибки значение владельца модуля, если менеджер не назначит ошибку разработчику.

URL:

URL страницы, на которой произошла ошибка.

Краткое резюме:

Добавьте краткое описание ошибки. Ориентируйтесь на 60 слов или меньше. Убедитесь, что составленное резюме отражает проблему и место, где она находится.

Описание:

Подробное описание ошибки.

Используйте следующие поля для поля описания:

Воспроизводимые шаги: ясно упомяните шаги для воспроизведения ошибки.
Ожидаемый результат: как приложение должно вести себя на вышеуказанных этапах.
Фактический результат: каков фактический результат выполнения вышеупомянутых шагов, то есть поведение ошибки.

Это важные шаги в отчете об ошибках. Вы также можете добавить «Тип отчета» как еще одно поле, которое будет описывать тип ошибки.

Видео курсы по схожей тематике:

Типы отчетов включают в себя:

1) Ошибка в коде
2) Ошибка проектирования
3) Новое предложение
4) Проблема с документацией
5) Аппаратная проблема

Важные фичи в вашем отчете об ошибках

Рассмотрим несколько составляющих отчета о найденном баге

Ниже приведены важные элементы баг-репорта:

1) Номер ошибки/идентификатор:

Номер ошибки или идентификационный номер (например, xyz007) значительно упрощает составление баг-репорта и поиск места ошибки. Разработчик может легко проверить, исправлена ли конкретная ошибка или нет. Это делает весь процесс тестирования и повторного тестирования более плавным и легким.

2) Наименование ошибки:

Заголовок ошибки читается чаще, чем любая другая часть баг-репорта. Стоит указать в нем всё о том, что входит в баг.

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

3) Приоритет:

В зависимости от серьезности ошибки, для нее может быть установлен приоритет. Ошибка может быть Blocker, Critical, Major, Minor, Trivial или предложением по улучшению функционала. Приоритет ошибки от P1 до P5 может быть задан так, чтобы важные из них просматривались первыми.

4) Платформа / Среда:

Указание конфигурации ОС и браузера необходимо для большей точности в баг-репорте. Это лучший способ сообщить о том, как можно воспроизвести ошибку.
Без точной платформы или среды приложение может вести себя по-другому, и ошибка на стороне тестировщика может не повторяться на стороне разработчика. Поэтому лучше четко указать среду, в которой была обнаружена ошибка.

5) Описание:

Правильное описание ошибки помогает разработчику понять ошибку. Оно описывает возникшую проблему. Плохое описание создаст путаницу и потратит время разработчиков и тестеров.

Необходимо четко сообщить об эффекте в описании. Всегда полезно использовать полные предложения. Рекомендуется описывать каждую проблему отдельно, а не разрушать их полностью. Не используйте такие термины, как «я думаю» или «я считаю».

6) Шаги для воспроизведения ошибки:

Хороший отчет об ошибке должен четко указывать шаги для воспроизведения. Шаги должны включать действия, которые вызывают ошибку. Не делайте общих заявлений. Будьте конкретны в следующих шагах.

Хороший пример правильно написанной пошаговой процедуры приведен ниже:

Последовательность шагов:

Выберите продукт wer05.
Нажмите на «Добавить в корзину».
Нажмите «Удалить», чтобы удалить продукт из корзины.

7) Ожидаемый и фактический результат:

Описание ошибки будет неполным без указания ожидаемых и фактических результатов. Необходимо обрисовать в общих чертах, каков результат теста и что ожидал бы пользователь в случае корректной работы программы. Читатель отчета должен знать, какой результат теста будет корректным. Ясно упомяните, что произошло во время теста и каков был результат.

Скриншот:

Одна картинка стоит тысячи слов. Сделайте скриншот с примером сбоя с соответствующими выделениями, чтобы указать дефект. Выделите неожиданные сообщения об ошибках светло-красным цветом. Это привлекает внимание к необходимой области.

Некоторые дополнительные советы, для написания хорошего баг-репорта

Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:

1) Немедленно сообщите о проблеме:

Если вы обнаружите какую-либо ошибку во время тестирования, не нужно ждать, чтобы написать подробный отчет об ошибке позже. Вместо этого напишите отчет об ошибке немедленно. Это обеспечит хорошее качество отчета и воспроизводимость шагов получения ошибках. Если вы решите написать отчет об ошибке позже, есть большие шансы пропустить важные детали в баг-репорте.

2) Воспроизведите ошибку три раза перед написанием баг-репорта:

Ваш баг должен быть воспроизводимым. Убедитесь, что ваши шаги достаточно четкие, чтобы воспроизвести ошибку без какой-либо двусмысленности. Если ваша ошибка не воспроизводима каждый раз, вы все равно можете подать ошибку, указав периодическую природу бага.

3) Протестируйте эту же ошибку на других похожих модулях:

Иногда разработчик использует один и тот же код для разных похожих модулей. Таким образом, вероятность того, что ошибка в одном модуле возникнет и в других подобных модулях, выше. Вы даже можете попытаться найти более серьезную версию найденной ошибки.

4) Составьте хорошее резюме ошибки:

Краткое описание ошибки поможет разработчикам быстро проанализировать природу ошибки. Низкое качество отчета излишне увеличит время разработки и тестирования. Правильно взаимодействуйте с вашим баг-репортом. Имейте в виду, что сводка об ошибках используется в качестве справочной информации для поиска ошибки в инвентаре ошибок.

5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:

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

Бесплатные вебинары по схожей тематике:

6) Не используйте оскорбительные выражения:

Приятно, что вы проделали хорошую работу и обнаружили ошибку, но не используете это для критики разработчика или нападок на какого-либо человека.

Заключение.

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

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

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

С нашей стороны для качественной подготовки тестировщиков, предлагаем вам ознакомиться с курсом подготовки специалиста-тестировщика на ITVDN — Quality Assurance

По материалам статьи

Источник

#статьи

27 апр 2021
13

Краш-курс по происхождению самых известных терминов цифрового мира.

Филолог, полиглот, IT-гик. В прошлом — преподаватель английского и литературы и рецензент Rolling Stone Russia. Ныне переводит для РБК и пишет о программировании и образовании для Skillbox.

Большинство IT-терминов пришло из английского языка. Но как они появились и почему эти английские слова в переводе означают вещи, которые никак не относятся к программированию и интернету?

Разбираемся, почему информацию хранят в облаке и как японское печенье с предсказаниями стало неотъемлемой частью рациона для большинства интернет-пользователей.

Баг (англ. bug — жук) — ошибка в программе.

Слово «баг» в значении «техническая неисправность» употребляли ещё в 1870-х. Тогда телеграфисты и телефонисты называли так помехи и неисправности в связи. Работники с большим трудом «ловили» и устраняли эти неполадки, которые надоедали, как назойливые жучки.

В значении «программная ошибка» слово впервые употребили в 1947 году. Инженеры, работавшие в Гарварде с компьютером Mark II, обнаружили в повреждённом компоненте машины сгоревшего мотылька, из-за которого и случилось замыкание. Насекомое извлекли и вклеили в журнал с символичной пометкой: «первый реальный случай обнаружения бага».

Тот самый вклеенный мотылёк и запись в журнале. Фото: Harvard University / IBM / National Museum of American History

Патч (англ. patch — накладка, заплата) — обновление или дополнение к программе.

Термин появился в эпоху перфокарт — главных носителей информации 1920–1950-х. Данные на них кодировали с помощью специальных отверстий. Чтобы изменить программу, приходилось накладывать заплатки на уже продырявленные места.

Патч на перфоленте первого программируемого компьютера — Mark I. Фото: ArnoldReinhold / Wikimedia Commons

Облачное хранилище данных, или просто облако (англ. cloud storage — облачное хранилище), — онлайн-хранилище данных.

Слово «облако» в значении «онлайн-хранилище» ещё в 1994 впервые использовали AT&T в рекламе нового сервиса PersonaLink Services. Тогда нужно было быстрее привлечь инвесторов и продвинуть проект в массы, поэтому разработчики использовали метафору, которая доступно объясняла принцип работы инновации: данные хранятся не у вас дома, а где-то там, в облаках. Кстати, рисунок хранилища на патенте тоже напоминает облако.

Патент на облачное хранилище данных. Изображение: US5485455A / Google Patents

Куки (англ. cookie — печенье) — информация, которую браузер сохраняет на компьютер, когда вы посещаете сайты.

Куки появились в IT-жаргоне благодаря печеньям с предсказаниями — кондитерским изделиям, внутри которых запекают записку с афоризмами и вариантами событий в будущем. Вопреки распространённому мнению, печенье в США завезли не китайские, а японские иммигранты. Позднее эти сладости «перекочевали» в сленг программистов: данные, которые сервер передаёт пользователю, стали называть cookies. Это слово очень ёмко и доступно объясняло принцип работы файлов, содержащих готовую, предсказуемую информацию.

Те самые cookies, о которых сайты предупреждают нас всё чаще и чаще. Фото: UngureanuCristi / Shutterstock

Спам (англ. spam — спам) — массовая рассылка сообщений.

История термина начинается в 1937-м. Тогда в США была основана торговая марка консервов SPAM, которая, по одной версии, расшифровывается как SPiced hAM, а по другой — как Shoulders of Pork and hAM. После Второй мировой войны SPAM вела агрессивную рекламную кампанию, чтобы сбыть залежавшуюся продукцию. Название торговой марки очень скоро стало нарицательным — им стали обозначать любую навязчивую рекламу.

В семидесятые слово популяризировали в комедийном скетче «Летающего цирка Монти Пайтона», который так и назвали — «Спам». В эпизоде официантка читает вслух меню — в нём все блюда, кроме одного, содержат консервы торговой марки SPAM. Словом вооружились тогдашние интернет-абьюзеры, чтобы мешать другим людям общаться в чатах. В результате спамом стали называть любые нежелательные письма и сообщения.

Спам, спам, спам, спам… Фото: Eduardo Unda-Sanzana / Wikimedia Commons

Робот (от чеш. robota — барщина, тяжёлая работа) — автоматизированное устройство, которое действует по определённой программе.

Любопытно, но одно из самых популярных слов IT-мира пришло не из английского, а из чешского языка. Термин «робот» ввёл писатель Карел Чапек. В 1920 он написал пьесу «Р.У.Р.» («Россумские универсальные роботы») — действие происходит на фабрике, где производят «искусственных людей». Писатель всё не мог придумать, как попроще назвать этих существ, поэтому обратился к брату, Йозефу Чапеку, который и предложил образовать неологизм от чешского слова robota.

Именно так выглядело первое художественное восстание роботов. Фото: Public Domain / Wikimedia Commons

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

На самом деле IT-индустрия никогда не противопоставлялась творчеству. Напротив, прокачанное образное мышление помогает стать первоклассным айтишником. Оно напрямую влияет на умение планировать и моделировать — важный навык программистов и инженеров.

Кроме того, метафоры позволяют лучше понимать абстрактные явления и решать проблемы, для которых ещё нет готовых алгоритмов. Художественность языка упрощает и само общение — ускоряет работу внутри коллектива. Иными словами, образный язык в IT-словаре — это вовсе не парадокс, а закономерность.

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

Участвовать

Школа дронов для всех
Учим программировать беспилотники и управлять ими.
Узнать больше

Ошибки в программах – дело обыденное. Приложения зависают, вылетают, перестают запускаться. В простейшем случае пользователь решает проблему переустановкой ПО или чисткой от «мусора». Разработчикам же нужно четко понимать, что такое баг, как исправить его и каким образом получить своевременную обратную связь от пользователей.

Что такое баг?

Термин «баг» (в переводе «жук») у программистов обозначает ситуацию, когда определенный код выдает неверный результат. Причины возникновения разные: ошибки в исходном коде, интерфейсе программы или некорректной работе компилятора. Обнаруживают их на этапе отладки или уже на стадии бета-тестирования, выпуска продукта на рынок.

Варианты ошибок:

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

Сложнее всего работать с компьютерными играми, в которых чаще используют термин «краш» (crash). Он означает критическую проблему при запуске или использовании программы. Когда говорят о багах, то чаще имеют в виду сбои графики, например, если игрок «проваливается в текстуры».

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Классификация багов

Точка зрения пользователей часто не совпадает с мнением программистов. Так, для первых всего лишь произошел сбой, «приложение перестало работать». Кодеру же предстоит головная боль с определением источника проблемы. Ведь ошибка в программе, вероятно, проявляется лишь на конкретном железе или при сочетании с другим софтом (часто с антивирусами).

Баги делят на категории в зависимости от их критичности:

незначительные ошибки,
серьезные ошибки,
showstopper.

Последние указывают на критическую программную или аппаратную проблему, из-за которой ПО теряет свою функциональность практически на 100%. Например, не удается авторизоваться через логин-пароль или перестала работать кнопка «Далее». Поэтому таким ошибкам отдают приоритет.

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

Есть вариант, когда проблема возникает только на машине конкретного клиента. Здесь приходится либо заказывать индивидуальную «работу над ошибками», либо менять компьютер. Потому что ПО для массового пользователя никто не будет редактировать из-за «одного». Только если наберется некая критическая масса одинаковых случаев.

Разновидности ошибок

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

Кодеры делят ошибки по сложности:

Борбаг (Bohr Bug) – «стабильная» ошибка, легко выявляемая еще на этапе отладки или при бета-тестировании, когда речь еще не идет о выпуске стабильной версии.
Гейзенбаг (Heisenbug) – периодически проявляющиеся, иногда надолго исчезающие баги с меняющимися свойствами, включая зависимость от программной среды, «железа».
Мандельбаг (Mandelbug) – ошибка с энтропийным поведением, почти с непредсказуемым результатом.
Шрединбаг (Schroedinbug) – критические баги, чаще приводящие к появлению возможности взлома, хотя внешне никак себя не проявляют.

Последняя категория ошибок – одна из основных причин регулярного обновления операционных систем Windows. Вроде бы пользователя все устраивает, а разработчик раз за разом выпускает новые пакеты исправлений. Наиболее известный баг, попортивший нервы многим кодерам, это «ошибка 2000 года» (Y2K Error). Про нее успешно забыли, но уроки извлекли.

Программисты различают и те ошибки, что мешают скомпилировать программу, и ворнинги. Вторая категория представляет собой лишь предупреждение о найденных «косяках» в коде, но они не мешают ни сборке ПО, ни последующей эксплуатации. Например, речь идет об отсутствии точки или точки запятой в синтаксисе, когда компилятор способен сам решить проблему.

Логические

Наиболее серьезная из ошибок. Такие баги приводят к изменению функционирования программы вопреки техническому заданию. К чему это приведет, никто не знает – могут записаться на диске «не те данные», некорректно измениться важные документы или предоставиться доступ к коммерческой информации без авторизации. Исправить их получится только при знании изначальной логики.

Синтаксические

Ошибки синтаксиса существуют на уровне конкретного языка программирования: C, Java, Python, Perl и т.д. Что на одной платформе работает максимум с ворнингами, для другой будет серьезной проблемой. Такие баги легко исправить на этапе компиляции, потому что инструмент не позволит «пройти дальше» некорректного участка кода.

Компиляционные

Ситуация происходит, когда код, написанный на языке высокого уровня, преобразуют в «простой», машиночитаемый. Причиной может служить как серьезная ошибка в синтаксисе, так и сбои в самом компиляторе. Такие баги устраняют на этапе разработки-отладки программ, потому что выпустить их даже для бета-тестирования не получится.

Среды выполнения

Так называемые ошибки Run-Time. Проявляются в скомпилированных программах, при запуске. Например, из-за нехватки ресурсов на машине, в результате аварийной ситуации (поломка памяти, носителя, устройств ввода-вывода). Такое происходит, если разработчик не учел реальных условий работы; придется вернуться к стадии проработки логики.

Арифметические

Одна из разновидностей логических ошибок. Происходят, когда программа при работе вычисляет массу переменных, но на каком-то этапе происходит непредвиденное. Например, деление на ноль или же приложение получает «бесконечный» результат. Изменить ситуацию получится только на уровне кода, внедренного в него алгоритма.

Ресурсные

Преимущественно к этой категории относят ошибки типа «переполнение буфера». Программист не учел необходимость очистки памяти перед размещением новых данных. Или интерфейс разработан без учета типовых разрешений экранов, и его элементы постоянно «съезжают», нарушается логика срабатывания кнопок и т.д. Исправить получится только переписыванием части кода.

Взаимодействия

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

Что такое исключение

Снизить риски появления непредвиденных ошибок позволяет внедрение в программу исключений. Это события, при возникновении которых начинается «неправильное» поведение. Такой механизм позволяет систематизировать обработку багов независимо от типа приложения, платформы и иных условий. И разработать единую систему реагирования, например, со стороны операционки.

Существуют программные и аппаратные исключения. Первые генерируются самой программой и ОС, под которой она запущена. К аппаратным относятся те, что создаются процессором. Например, деление на 0, переполнение буфера, обращение к невыделенной памяти. Исключениями кодеры охватывают наиболее серьезные, критические баги.

Как избежать ошибок?

Существует два эффективных способа избежать проблем еще на стадии разработки. Первый – это отладка при помощи специальных программ. Они отображают результаты выполнения в цифрах, которые объективно показывают кодеру, правильно ли был обработан следующий участок кода или нужно искать закравшуюся ошибку.

Второй способ представляет собой привлечение специальных людей, тестировщиков. Они помогут разобраться с работоспособностью интерфейса в различных ситуациях, на разных платформах. Это происходит максимально приближенно к реальным условиям. Поэтому любой серьезный продукт проходит такую стадию обязательно.

Выводы

Баги – сопутствующий фактор любой разработки. Большую их часть пользователь не видит, потому что устраняются они еще в «лаборатории», на этапе альфа-тестирования. В бета-версии попадают уже незначительные ошибки, например, связанные с конкретными «узкими» условиями эксплуатации. Редкие проблемы помогают решать краш-репорты – отчеты, отсылаемые производителю самой программой.

Ошибки в программировании – дело обычное, хоть и неприятное. В данной статье будет рассказано о том, какими бывают ошибки (баги), а также что собой представляют исключения.

Определение

Ошибка в программировании (или так называемый баг) – это ситуация у разработчиков, при которой определенный код вследствие обработки выдает неверный результат. Причин данному явлению множество: неисправность компилятора, сбои интерфейса, неточности и нарушения в программном коде.

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

Появляется сообщение об ошибке, но приложение продолжает функционировать.
ПО вылетает или зависает. Никаких предупреждений или предпосылок этому не было. Процедура осуществляется неожиданно для пользователя. Возможен вариант, при котором контент перезапускается самостоятельно и непредсказуемо.
Одно из событий, описанных ранее, сопровождается отправкой отчетов разработчикам.

Ошибки в программах могут привести соответствующее приложение в негодность, а также к непредсказуемым алгоритмам функционирования. Желательно обнаруживать баги на этапе ранней разработки или тестирования. Лишь в этом случае программист сможет оперативно и относительно недорого внести необходимые изменения в код для отладки ПО.

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.

Как классифицируют

Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:

Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

Последний вариант требует особого внимания со стороны программистов. Их стараются обнаружить и устранить в первую очередь. Критические ошибки могут отложить релиз исходной программы на неопределенный срок.

Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.

Иногда может получиться так, что ошибка возникает только на устройстве конкретного пользователя. В данном случае устранение неполадки требует индивидуального подхода. Иногда – полной замены компьютера. Связано это с тем, что никто не будет редактировать исходный код, когда он «глючит» только у одного пользователя.

Виды

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

Разработчики выделяют следующие типы ошибок по уровню сложности:

«Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
«Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
«Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
«Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.

Типы багов

Ошибки в программах бывают:

логическими;
синтаксическими;
взаимодействия;
компиляционные;
ресурсные;
арифметические;
среды выполнения.

Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.

Ошибки синтаксиса

Синтаксические баги распространены среди новичков. Они относятся к категории «самых безобидных». С данной категорией ошибок способны справиться компиляторы тех или иных языков. Соответствующие инструменты показывают, где допущена неточность. Остается лишь понять, как исправить ее.

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

Логические сбои обычного типа – самые сложные и неприятные. Их тяжелее всего обнаружить и исправить. С точки зрения языка программа может быть написана идеально, но работать неправильно. Подобное явление – следствие логической ошибки. Компиляторы их не обнаруживают.

Выше – пример логической ошибки в программе. Тут:

Происходит сравнение значения i с 15.
На экран выводится сообщение, если I = 15.
В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

Может показаться, что ошибка безобидная. В приведенном примере так и есть, но в более крупных программах такое явление приводит к серьезным последствиям.

Время выполнения

Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.

Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.

Ресурсные

Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

Взаимодействие

Подразумевается взаимодействие с аппаратным или программным окружением. Пример – ошибка при использовании веб-протоколов. Это приведет к тому, что облачный сервис не будет нормально функционировать. При постоянном возникновении соответствующей неполадки остается один путь – полностью переписывать «проблемный» участок кода, ответственный за соответствующий баг.

Исключения и как избежать багов

Исключение – событие, при возникновении которых начинается «неправильное» поведение программы. Механизм, необходимый для стабилизации обработки неполадок независимо от типа ПО, платформ и иных условий. Помогают разрабатывать единые концепции ответа на баги со стороны операционной системы или контента.

Исключения бывают:

Программными. Они генерируются приложением или ОС.
Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

Что такое баг

Баг – (от англ. bug – жук) это любая незапланированная ошибка в программе, которая могла возникнуть по самым разным причинам.

Как появляется баги

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

Как появилось слово баг и почему “жук” с английского языка

Почему именно так никто точно не знает. Есть занимательная версия про ученых Гарвардского университета произошедшая в 1945 году. Мол у них была поломка в вычислительной машине из-за которой устройство не корректно работало. Тогда ученые разобрали машину и выяснили что причиной поломки была бабочка, которая застряла между контактами проводов. Эту красивую историю все друг-другу пересказывают, ее можно даже услышать в университетах СНГ от какого-нибудь преподавателя.

Вообще, если покопаться в истории, то подобное упоминание этого слова в контексте “ошибки” можно встретить даже в дневниках Томаса Эдисона, а это было в 19 веке. Также, Standard Electrical Dictionar (стандартный словарь по электротехнике) в 1892 году включил слово bug в контексте “любая неисправность или неисправность в соединениях или работе электрических устройств”.

Скорее всего истина лежит где-то глубоко и надо копать в староанглийский фольклор, ведь словом “bug”, “boogy” дети (и даже взрослые) называли всякие сверхъестественные штуки. Эту информацию можно легко найти в словаре Merriam Webster, так как прямо из слова “bug” идут все необходимые ссылки.

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

Какие бывают баги

1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

Еще в 1878 году, Томас Альва Эдисон (да-да, тот самый!) в письмах к своему соратнику Пускасу писал: «It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached». Тем же словом, инженеры называли и сбои радарной электроники во время второй Мировой Войны. Конечно, более распространена история о том, что в 1946 году разработка компьютера Марк-2 (Mark-II) были приостановлена из-за сбоя его функционирования, вызванного попаданием мотылька между контактов. Трупик мотылька был извлечен и приклеен к отчету липкой лентой с комментарием «First actual case of bug being found.» («Первый реальный случай нахождения жучка»). Как нетрудно догадаться, примерно оттуда же «растут уши» и слова «дебаггер» (debugger) – буквально «избавитель от жучков».

2. Виды багов.
Простейший (не как инфузория-туфелька, а самый простой для понимания, модно сказать «классический») баг – это несоответствие между ожидаемым результатом (ОР) и фактическим результатом (ФР). Разберем это на примере:

Действия	Ожидаемый результат	Фактический результат
Ввести в ячейку выражение «=2+2*2» (без кавычек) и нажать ENTER	6	8 БАГ!!!!

(это, кстати, реальный баг старого Microsoft Excel – он не учитывал приоритета математических операций, по которому умножение имеет высший приоритет по сравнению со сложением)

Все просто. Ждем одно – получаем другое. Баг.
Я не буду перечислять все подвиды бага классического – от опечаток в данных и опечаток в коде до бесконечных циклов, от использования оператора присвоения вместо оператора проверки равенства до использования неинициализированной переменной, от состояния гонки (race condition) в мультипоточных приложения до переполнения буфера, и так далее, и тому подобное – все это достаточно обыденные и ясные явления. Обратимся к малознакомой экзотике.

2.1. Гейзенбаг (Heisenbug)
Баг, названный в честь Гейзенбергского Принципа неопределенности – концепции квантовой физики. Простым (хоть слово «просто» здесь и не очень применимо) примером подобного бага будет являться ошибка, проявляющаяся, когда программа запускается на исполнение в рабочей среде, но исчезающая, когда программу запускают в дебаггере.

2.2. Борбаг (Bohrbug)
Тип бага, названный так в честь атомной модели Бора. В противоположность Гейзенбагу, он проявляется постоянно при одном и том же стечении обстоятельств. Вопрос в том, что весь набор обстоятельств бывет невозможно (или очень трудно) отследить.

2.3. Мандельбаг (Mandelbug)
Назван в честь Бенуа Мандельброта, внесшего огромный вклад в теорию фракталов. Мандельбагами называют ошибки, чьи причины настолько сложны и неясны, что фактически кажутся хаотичными и не поддающимися описаниями. (ключевое слово «кажутся»). Подобное, может быть вызвано, например, медленной реакцией системы – то есть ошибка уже произошла, но об этом вы узнаете только через некоторое время, что сильно затруднит локализацию причин.

2.4. Шрединбаг (Schroedinbug)
Шрединбаг назван в честь известного парадокса с кошкой Шредингера (или эта несчастная животина – кот?). Он заключается в том, что кто-нибудь читает код программы (работающей уже некоторое время) и восклицает «Да этого не может быть! Она просто не может функционировать!», после чего программа прекращает свое функционирование пока данная ошибка не будет исправлена. Будучи, казалось бы, абсолютно фантастической, данная ошибка попадается в реальности – спросите знакомых ветеранов- разработчиков, они подтвердят. Хотя, конечно, последующий анализ, как правило, позволяет отнести ошибку к разделам 2.1, 2.2 или 2.3, это удается не всегда.

2.5. Фазы луны
На самом деле такой ошибки не существует – это популярная отговорка тех, кто не хочет (не имеет желания и/или времени) разбираться в сложных причинах возникновения ошибки. Тем не менее, в истории существует пара примеров, когда ошибки возникали буквально из-за фаз луны. Я не буду приводить здесь эти истории, надеясь, что никому из нас не придется работать со столь сложными устройствами. Тем не менее, в любом случае, хотелось бы предостеречь всех от неосторожных умозаключений и попросить быть более внимательными, настойчивыми и скрупулезными в своей работе.

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

2.7. Демонстрационный эффект.
Ну и конечно, известный всем, «эффект первого показа», не раз случавшийся и с вашим покорным слугой. Как только приходит пора показать, например, прекрасно функционировавший на тестовом стенде юнит, обязательно происходит что-то ужасное. Причны, как правило, тривиальны – пропуск «незначительных» тест-кейсов, невнимательность к деталям и неучтенные юз-кейсы. Опять же – будьте внимательней.

На этом я закончу краткий обзор багов, буду рад Вашим замечаниям и предложениям.

Вы, наверное, слышали это раньше: в программном обеспечении есть «баг», из-за которого что-то работает неправильно. Что такое компьютерный баг и откуда появился этот термин? Мы объясним.

Баг- это непреднамеренная ошибка в компьютерном программном обеспечении

«Компьютерный баг» или «программный баг» — это термин, обозначающий непреднамеренную ошибку программирования или дефект в компьютерном программном обеспечении или оборудовании. Баги возникают из-за человеческой ошибки в конструкции оборудования или где-то в цепочке программных инструментов, используемых для создания компьютерных приложений, прошивок или операционных систем.

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

В сегодняшнем мире ошибки в программном обеспечении — серьезное дело. Почти 20 лет назад Национальный институт стандартов и технологий подсчитал, что ошибки в программном обеспечении обходятся экономике США почти в 60 миллиардов долларов в год (около 0,6% ВВП в 2002 году), и с тех пор эта цифра, вероятно, увеличилась. Хотя точно количественно оценить негативные последствия ошибок сложно, легко представить, как неисправное программное обеспечение может повлиять на производительность. Это может даже подвергнуть опасности жизнь людей на транспорте или поставить под угрозу жизненно важную инфраструктуру, такую как электростанции.

Почему мы называем их багами

Термин «баг» появился еще до изобретения компьютеров, и мы точно не знаем, кто изначально придумал термин «баг» для обозначения инженерного дефекта. В письменных источниках историки проследили это до Томаса Эдисона не ранее 1870-х годов.

Эдисон использовал этот термин в своих личных заметках и переписке для обозначения сложной проблемы, которая требовала решения, или инженерного дефекта, который требовал исправления. Он даже пошутил о том, что этот термин имеет отношение к насекомым, написав в письме 1878 года:

«Вы были частично правы, я действительно обнаружил «баг» в своем аппарате, но не в самом телефоне. Он принадлежал к роду callbellum. Похоже, насекомое находит условия для своего существования во всех телефонных аппаратах».

Хотя некоторые считают, что примеры Эдисона означают, что он ввел термин «баг», но вполне возможно, что он произошел от кого-то еще раньше и что он просто популяризировал этот термин среди своих друзей и соратников-инженеров. Оксфордский словарь английского языка цитирует пример 1889 года, связанный с Эдисоном, который описывает ошибку как метафору насекомого, заползающего в элемент оборудования и вызывающего его неисправность, предполагая, что настоящая ошибка, делающая именно это, могло первоначально послужить источником этого термина, похожего на термин «ложка дегтя».

Отбросив на мгновение слово «баг», первым известным человеком в истории, который осознал, что программное обеспечение может работать неправильно из-за ошибок в программировании, была Ада Лавлейс. Она писала об этой проблеме еще в 1843 году в своем комментарии к аналитической машине Чарльза Бэббиджа.

«На это можно ответить, что процесс анализа в равной степени должен быть выполнен для того, чтобы снабдить аналитическую машину необходимыми оперативными данными; и в этом также может заключаться возможный источник ошибки. При условии, что реальный механизм безошибочен в своих процессах, карты могут отдавать ему неправильные приказы».

В этой цитате Лавлейс говорит о том, что настоящий вычислительный механизм не содержит ошибок в том, как он обрабатывает данные, но оговаривает, что данные, передаваемые ему людьми (как в то время запрограммированы на карточках), могут дать машине неправильные инструкции и таким образом дают неправильные результаты.

Бабочка Грейс Хоппер

На протяжении десятилетий книги, журналы и веб-сайты ошибочно сообщали, что термин «баг» был придуман легендарным компьютерным ученым Грейс Хоппер, когда моль влетела в реле компьютера Harvard Mark II и вызвала его неисправность. Как гласит история, она затем записала мотылька в журнал и сделала историческую заметку: «Первый реальный случай обнаружения бага».

Хотя в 1947 году в Mark II действительно залетела моль, она не была источником терминов «баг» или «дебаг», которые предшествовали инциденту. Кроме того, не совсем ясно, действительно ли моль привела к неисправности компьютера, или это была просто забавная находка, пока они исправляли другие дефекты. Хоппер сделала эту историю известной, рассказав ее в широко цитируемом интервью от ноября 1968 года.

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

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

Историки не знают, был ли это дневник Хоппер или кто на самом деле написал запись, но сегодня журнал Harvard Mark II находится в Национальном музее американской истории в Смитсоновском институте в Вашингтоне, округ Колумбия.

Хотя бабочка Mark II (назовем его «Марк») не была первой компьютерной ошибкой, она, тем не менее, остается физическим и культурным символом очень реальной и сложной проблемы, с которой борются все программисты.

Не следует путать с лагом.

В программировании баг (англ. bug — первичные значения: клоп, любое насекомое, вирус) — жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, «глючной», «глюкнутой», «забагованной», «бажной», «баг(а)нутой» (англ. unstable, buggy).

Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге также называют отчетом об ошибке или отчетом о проблеме (англ. bug report). Отчет о критической проблеме (англ. crash), вызывающей аварийное завершение программы, называют крэш-репортом (англ. crash report).

«Баги» локализуются и устраняются в процессе тестирования и отладки программы.

Багом также называют определённый вид маркера на индикаторах.

Этимология

Запись в тех.журнале

Широко распространена легенда, что 9 сентября 1945 года учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник, с сопроводительной надписью: «First actual case of bug being found» (рус. «первый реальный случай, когда был найден жук»). Считается, что этот забавный факт положил начало использованию слова «debugging» в значении «отладка программы», однако, скорее всего, фраза является каламбуром.

В действительности этот случай произошёл 9 сентября 1947, а не 1945, года. Слово «bug» в современном значении употреблялось задолго до этого персоналом телеграфных и телефонных компаний в отношении неполадок с электрооборудованием и радиотехникой. Во время Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой. В 1878 году Томас Эдисон писал:

Это повторялось снова и снова со всеми моими изобретениями. Первым шагом была интуиция, за ней следовала вспышка, затем возникали препятствия — и они исчезали, потом возникали Баги — так называются маленькие недочеты и трудности — и необходимы месяцы постоянного поиска, исследований и тяжелого труда до успеха или неудачи.^[1]

Оригинальный текст (англ.)

It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that «Bugs»—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.

Поиск и исправление ошибок

Для отладки программы (англ. debugging) разработчиками ПО используются специальные программы-отладчики (англ. debugger). Например, в операционной системе Windows можно использовать программу WinDbg из пакета Microsoft Debugging Tools for Windows. Для GNU/Linux и ряда других UNIX-подобных операционных систем существует отладчик GDB (GNU Debugger).

Отчёты об ошибках

Основная масса багов обычно отлаживается на этапе компиляции и тестирования программы. Однако некоторая часть ошибок всё же попадает в релиз и проявляется на компьютерах конечных пользователей в процессе эксплуатации ПО. Для повышения качества программного обеспечения пользуются специальными программами, цель которых — отловить ошибку в целевом приложении, собрать необходимую информацию об её симптомах и отправить отчёт по интернету к разработчикам данного ПО.

Например, в операционную систему Windows встроена утилита Dr. Watson, которая по умолчанию отлавливает ошибки в приложениях пользователя и отправляет отчёт на специальный Сервер компании Microsoft. Также в качестве примера можно привести аналогичные библиотеки Breakpad^[2] и CrashRpt^[3].

См. также

Отчет об ошибке
Система отслеживания ошибок
Фича
Борбаг — легко обнаруживаемый стабильный баг
Гейзенбаг — сложно обнаруживаемый, периодически исчезающий и меняющий свойства баг при попытке его обнаружения
Мандельбаг — баг с очень сложным, хаотичным, поведением
Шрёдинбаг — критическая ошибка, которая не проявляется пока кто-нибудь на неё не наткнется в исходном коде, после чего программа совершенно перестает работать
Бозебаг — большое скопление ошибок в определенном участке кода
Дзенбаг — не влияющая ни на что ошибка
Метабаг — грамматическая ошибка в комментарии
Фомбаг — (англ. Phase of the Moon bug) периодический баг, проявляющийся от времени выполнения (например: только по утрам, только 13-го числа)
Альфабаг — (англ. Alpha particle bug)(жарг. Полтергейц) баг который произошел единожды, и анализ кода говорит о том, что его не могло произойти без отказа аппаратных средств (например под влиянием альфа частиц, или электромагнитного излучения)
Фермабаг — сложно доказуемый баг, возникающий, как правило, только на машинах заказчика
Фермибаг — количественная характеристика бажности исходного кода, применяется когда плотность достигает одной-двух ошибок на строку кода
GIGO
Предлимитный синдром
Катастрофа Ariane 5 (4 июня 1996) — один из самых дорогостоящих компьютерных багов в истории.

Примечания

↑ Источник: Edison to Puskas, 13 ноября 1878, Edison papers, Edison National Laboratory, U.S. National Park Service, West Orange, N.J., цитируется по книге Томаса П. Хьюджеса (Thomas P. Hughes), American Genesis: A History of the American Genius for Invention, Penguin Books, 1989, стр.
↑ Breakpad. Google. Архивировано из первоисточника 3 февраля 2012. Проверено 11 августа 2009.
↑ CrashRpt. Архивировано из первоисточника 3 февраля 2012.

Ссылки

Уязвимости в исходных кодах, «Компьютерная газета». Продолжение: Уязвимости в исходных кодах. Перепечатка: 1 часть, 2 часть.
Что же такое баг?!
10 худших ошибок в программировании в истории человечества
2010 CWE/SANS Top 25 Most Dangerous Software Errors частичный перевод на русский 25 самых опасных ошибок при создании программ

Источник

#1 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #1" />

#4 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #4" /> Natalya Rukol

#5 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #5" /> Romantik

#7 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #7" /> Natalya Rukol

#8 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #8" /> Фрося

#11 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #11" /> notProgrammer

#12 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #12" /> LeshaL

#13 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #13" /> LeshaL

#14 <img decoding="async" src="https://software-testing.ru/forum/public/style_images/master/icon_share.png" title="Что считать багом?Ссылка на это сообщение #14" /> notProgrammer

Основные Поля в Баг Репорте

ID

Summary

Preconditions

Steps to Reproduce

Actual Result

Expected Result

Project

Build number

Priority

Severity

Assignee

Reporter

Status

Comments

В дополнение

Что такое Баг / Дефект?

Откуда берутся баги?

Все ли баги нужно исправлять?

Жизненный цикл бага

Этапы жизненного цикла бага

Переходы бага между этапами жизненного цикла

Что такое баг репорт (bug report)?

Зачем нужны баг репорты?

1. Происходит фиксации факта существования бага

2. Баг репорт помогает разработчику

3. Появляется возможность приоритизации исправлений

4. Появляется возможность анализа ошибок

5. Тестировщик содействует устранению бага

6. Появляется возможность контроля этапа исправления бага

7. Появляется возможность оценки качества продукта в текущий момент времени

Атрибуты баг репорта

Основные поля

Дополнительные поля

Серьезность бага (Bug Severity)

S4 | Blocker

S3 | Critical

S2 | Major

S1 | Minor

S0 | Trivial

Типы багов

UI (ошибка в верстке)

UX (ошибка в удобстве)

Functional (ошибка в функционале)

SEO (ошибка в seo)

Алгоритм создания баг репорта

Пример хорошего баг репорта (bug report example)

Пример баг репорта в Jira

Ошибки при создании баг репорта

Резюме

Источники

FAQ

Что такое баг?

Откуда берутся баги?

Что такое баг репорт (bug report)?

Что такое Серьезность бага (Bug Severity)?

Требования к обязательным полям баг репорта

Короткое описание

Серьезность

Шаги к воспроизведению / Результат / Ожидаемый результат

Основные ошибки при написании багов репортов

Заполнение полей баг репорта

Основные Поля в Баг Репорте

ID

Summary

Preconditions

Steps to Reproduce

Actual Result

Expected Result

Project

Build number

#1

#4

Natalya Rukol

#5

Romantik

#7

Natalya Rukol

#8

Фрося

#11

notProgrammer

#12

LeshaL

#13

LeshaL

#14

notProgrammer