Что такое баг Поговорим об ошибках в играх и программах


Содержание

Что такое баги и откуда они берутся?

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

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

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

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

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

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

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

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

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

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

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

Так, известно, что редактировать свои записи можно только в течение суток после их опубликования. Некий пользователь под ником «Мгновения Грядущего» опубликовал точные «предсказания» событий 2014 года, датированные первым декабря 2013 и снабженные картинками произошедших событий – Олимпиады в Сочи, Крымской Весны и т.д.

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

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

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

Баг репорт (bug report): оформление и пример

Баг репорт (bug report) – это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.

Bug report c определением в самом общем случае – это несоответствие требованиям или функциональным спецификациям (или здравому смыслу). То есть это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

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

Содержание

Определения понятия баг

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

  • «Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб): «Программная ошибка – ни что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов.»
  • «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах» (Роман Савин): «Итак, баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result). В соответствии с законом исключённого третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.»
  • Википедия. «В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект – это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.»
  • Сергей Мартыненко (блог «255 ступеней»). «Дефект – поведение программы, затрудняющее или делающее невозможным достижение целей пользователя или удовлетворение интересов участников. Подразумевает возможность исправления. При невозможности исправления переходит в разряд ограничения технологии.»

Мы будем использовать простое определение:

Дефект (баг, глюк, ошибка; defect, bug) – это несоответствие требованиям или функциональным спецификациям.

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

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

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

Управление инцидентами перед оформлением баг репорта

Инцидент (incident) — это любое событие, требующее исследования.

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

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

Если есть расхождения между фактическими и ожидаемыми результатами, то прежде чем делать send bug report (отправь баг репорт), баг должны быть зарегистрированы как инциденты.

Инцидент (Test Incident) – любое событие, наблюдение, найденное в рамках тестирования, требующее исследования. Инцидент может возникнуть:

  • В документации (требования, документы по разработке, тестовая документация, информация для пользователя);
  • Во время тестирования в тестируемой системе или в тестовом окружении или во время использования продукта;
  • В коде.

Виды инцидентов


Есть практика выделять два вида тестовых инцидентов: дефект и запрос на улучшение. Если давать определения этим понятиям, то можно назвать следующее

  • Дефект (Defect, Bug) – любое состояние тестируемой системы, которое не соответствует ожидаемому поведению, основанному на спецификациях к проекту, требований, проектной документации, пользовательской документации, стандартов и т.п., или исходя из чьего-либо восприятия, опыта и здравого смысла. Дефекты бывают разных классификаций в зависимости от вида тестирования. Например, функциональное тестирование, тестирование документации, тестирование производительности и т.п. Синонимы: ошибка, отклонение, недочет, аномалия, помеха, отказ, проблема.
  • Запрос на изменение (Improvement, Feature) – это любое предложение об усовершенствовании продукта или его отдельных свойств. Распространенные синонимы: Change Request, Issue, Enhancement, Usability.

back to menu ↑

Документирование инцидента

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

  • Отчет по инциденту (Incident Report) – документ, описывающий событие, которое произошло, во время тестирования, и которое необходимо исследовать.
  • Отчет о дефекте (Defect Report) – документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
  • Отчет о запросе на изменение (Improvement Report) – документ, описывающий предложение об усовершенствовании продукта. Включает в себя детальное описание предложения и обоснование внесения изменений в программное обеспечение.

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

Инструмент управления дефектами и инцидентами

Оформление баг репорта или отчета об инциденте удобно делать если есть специальный инструмент управления дефектами (Defect Management Tool, Bug or Issue Tracker Tool) – инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетности. Помимо стандартной функциональности, хороший инструмент управления дефектами должен иметь возможности:

  • поиска по критериям
  • сохранять историю изменений
  • гибкой настройки нотификаций.

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

Оформление баг репорта: основные принципы

Определения для понятия bug report мы навали выше, поэтому начнем с характеристик, которыми должен обладать отличный баг репорт. Качественное оформление баг репорта должно отвечать на следующие вопросы:

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

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

Цель баг репорта

Целью составления отчета о дефекте является ее исправление, поэтому не имеет смысла создавать отчеты ради отчетов. Чем больше хорошо задокументированных отчетов поступает от команды тестирования, тем больше доверия к тестированию. Целью отчёта об ошибке (bug-report) является:

  • Предоставить информацию о проблеме, ей свойствах и последствиях;
  • Приоритизировать проблему по важности и скорости устранения;
  • учета качества продукта (TRR, QRR);
  • Помочь программистам обнаружить и устранить источник проблемы.

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

И если подводить черту под смыслом написания баг репорта, то основная цель написания отчёта об ошибке – устранение ошибки.

Поэтому стоит помнить, что хороший тестировщик – не тот, кто написал за день 1000 бесполезных и бессмысленных отчётов, а тот, по чьим отчётам (вне зависимости от их количества) было исправлено большое количество ошибок.

Баг репорт: пример полей для заполнения (атрибуты)

Ниже предоставлен список основных полей отчета о дефекте. Будем перечислять возможные атрибуты, а также останавливаться и объяснять наиболее важные. Звездочками помечены обязательные поля для заполнения.

Название проекта * (Project) – официальное название проекта

Здесь, в принципе, все понятно и каких-либо дополнительных объяснений не нужно.

Уникальный номер отчета * (ID) – идентификатор отчета о дефекте

У каждого отчёта об ошибке должен быть уникальный идентификатор. Как правило, системы управления ошибками (bug tracking systems) позволяют формировать идентификатор в виде некоторого шаблона, например аббревиатура проекта + дата + порядковый номер

Либо, каким-нибудь другим видом, при этом ID, будет позволять идентифицировать баг.

Дата создания * (Created Date) – дата создания отчета

Опять-таки, здесь все предельно понятно.

Дата обновления (Update Date) – дата обновления (изменение, закрытие)

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

Краткое описание * (Summary, Title, Subject, Synopsis) – заголовок отчета

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


Например:

  • «Отсутствует логотип на странице приветствия, если пользователь является администратором».
  • «Невозможно открыть файл с именем длиннее 500 символов».
  • «Приложение виснет при попытке ввести пустой пароль на странице авторизации пользователей»

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

  • [EN] «Опечатка в сообщении о неверном логине/пароле на странице авторизации пользователей» – баг актуален для английской версии ПО.
  • [Opera] «Ошибка JavaScript при просмотре личных сообщений в профиле пользователя» – ошибка возникает только в браузере Opera.

Примечание:

  • Слова, что нельзя произносить… 
  • Плохая картинка, не работает, ошибка, неверное поведение…
  • Can’t reproduce

Текущий статус * (Status) – состояние инцидента

Набор статусов зависит от выбранного процесса разработки. Базовые статусы:

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

Резолюция (Resolution) – пояснение к статусу

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

  • Unresolved
  • Fixed
  • Won‘t Fix
  • Duplicate
  • Cannot Reproduce
  • Verified

Подробнее о резолюциях будет сказано в отдельной статье.

Приоритет (Priority) – свойство, указывающее на очередность выполнения задачи или устранения дефекта

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

  • High — наивысшая или (ASAP, as soon as possible). Присваивается ошибкам, наличие которых делает невозможным дальнейшую работу над проектом или передачу заказчику текущей версии проекта.
  • Major — Присваивается ошибкам, которые нужно исправить в самое ближайшее время.
  • Medium — Присваивается ошибкам, которые следует исправлять в порядке общей очереди.
  • Low — Присваивается ошибкам, которыми отделу разработки следует заниматься в последнюю очередь (когда и если на них останется время).

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

Илон Маск рекомендует:  Что такое код asp logextfileuriquery

Строгость (Severity) – техническая оценка инцидента

Набор степеней строгости дефектов завит от выбранного процесса разработки и договоренностей между участниками проекта. Базовый набор:

  • Критическая (critical). Это самые страшные ошибки, выражающиеся в крахе приложения или операционной системы, серьёзных повреждениях базы данных, падению веб-сервера или сервера приложений.
  • Высокая (major). Серьёзные ошибки, такие как: потеря данных пользователя, падение значительной части функциональности приложения, падение браузера или иного клиента и т.п.
  • Средняя (medium). Ошибки, затрагивающие небольшой набор функций приложения. Как правило, такие ошибки можно «обойти», т.е. выполнить требуемое действие иным способом, не приводящим к возникновению ошибки.
  • Низкая (minor). Ошибки, не мешающие непосредственно работе с приложением. Как правило, сюда относятся всевозможные косметические дефекты, опечатки и т.п.

Тип инцидента (Incident Type) *

Принято выделять два вида тестовых инцидентов:

  • дефект (Bug)
  • запрос на улучшение (Improvement).

Категория инцидента (Category)

Данное свойство отображает, к какой характеристике проекта относится инцидент. Базовый набор категорий:

  • Functional
  • Text
  • Design (баг репорт на косметический дефект)
  • Documentation
  • Performance
  • Technical

Компонент (ы) (Component)

Здесь отображается область объекта тестирования, к которой относится инцидент.

Версия приложения, для которой инцидент актуален (Affects Version)

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


(Fix Version)

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

Создатель отчета * (Reporter)

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

На кого назначен отчет (Assignee)

Здесь отражается имя сотрудника, назначенного на решение задачи.

Метки (Labels)

Метки используются для систематизации информации. В дальнейшем метки служат для сбора метрик, поиска дефектов и т.п.

Окружение (Environment)

Окружение, на котором найден дефект – операционная система, браузер, версия браузера, сервер и т.п. Если дефект воспроизводится на всех окружениях, то ставится соответствующий комментарий.

Описание * (Description)

Также чрезвычайно важный атрибут. Описание должно быть лаконичным и ясным, как и Summary, но в более развернутой форме. Если есть альтернативные шаги, то их также нужно указать. В описание можно оставлять любые полезные примечания – повторяемость, уточнения и т.п. Пример Description в баг репорте:

Если администратор заходит на страницу приветствия, то логотип пропадает.

Actual result: логотипа нет. (Реальный результат)

Expected result: логотип в правом верхнем углу. (Ожидаемый результат)

Requirement ID: #45 (пункт требований)

Reproduced on: Win10, IE11, 1200x800dpi (на чем воспроизводиться)

Workaround: Да, логотип отображается, если обновить страницу повторно

For more details, please, see attached files:

Как видно из примера Описание (Description) имеет набор атрибутов, которые входят в его состав, давайте некоторые поясним

Приложения (Attachments)

Любая информация, которая поможет воспроизвести ситуацию:

Воспроизводимость (reproducible, reproducibility)

Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда («sometimes»). Баги, воспроизводящиеся всегда, гораздо проще диагностировать.

Примечание:

Рекомендация: пройдитесь по своим шагам воспроизведения хотя бы 2-3 раза прежде, чем писать, что баг воспроизводится всегда.

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

Возможность «обойти баг» (workaround)

Это поле косвенно влияет на важность и срочность устранения ошибка. Если некое действие можно выполнить в обход сценария, приводящего к ошибке, поле принимает значение «да» («yes»), в противном случае – поле принимает значение «нет» («no»).

Шаги воспроизведения (steps to reproduce, STR)

Данная информация в отчёте об ошибке является крайне важной. Именно она позволяет разработчику быстро воспроизвести и устранить проблему. Это поле следует заполнять максимально подробно, т.к. будучи незнакомым с внутренней структурой приложения, тестировщик не может знать, какие из выполненных им действий наиболее существенны для диагностирования данной ошибки (steps в тест кейсе, в какой-то степени, похожи STR).

Несколько рекомендаций:

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

Пример:

  1. Open www.mysite.com
  2. Click on [Account] button
  3. Fill in sing-in form with admin/admin123
  4. Click on [Sing in] button – user is redirected on a greeting page, site logo is absent.

Дополнительная информация (additional info)


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

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

Симптом (symptom)

Это поле показывает, к какой категории относится ошибка. Наиболее широко распространённые симптомы:

  • Косметический дефект (cosmetic flaw) – опечатки, повреждённые картинки, не тот цвет, не тот размер, не там расположено и т.п. другими словами баг репорт на косметический дефект.
  • Повреждение/потеря данных (data corruption/loss) – в результате ошибки данные повреждаются или теряются.
  • Проблема в документации (documentation issue) – такой симптом присваивается ошибке, если она описывает проблему не в приложении, а в документации.
  • Некорректная операция (incorrect operation) – например: 2+2=5, или: хотим сохранить файл в c:/ , а он сохраняется в d:/
  • Проблема инсталляции (installation problem) – ошибки, возникающие на стадии установки или удаления приложения.
  • Ошибка локализации (localisation issue) – что-то не переведено или переведено неверно.
  • Нереализованная функциональность (missing feature) – например: приложение сохраняет файлы только в формате DOC, а должно ещё и в XML.
  • Низкая производительность (slow performance) – некоторые действия и/или условия работы приводят к тому, что приложение начинает «тормозить».
  • Крах системы (system crash) – приложение или операционная система или (веб-сервер / сервер приложений / СБД) виснет, перезагружается, «вываливается» (закрывается).
  • Неожиданное поведение (unexpected behavior) – например: комбинация клавиш Ctrl-O вызывает не открытие, а печать файла; в полях формы появляются странные значения по умолчанию. (Как правило связано с usability)
  • Недружественное поведение (unfriendly behavior) – например: на сайте есть голосование, пользователь выбирает вариант, нажимает «Проголосовать» и… его просят зарегистрироваться.
  • Расхождение с требованиям (variance from spec) – под этот симптом попадает почти любая ошибка, но рекомендуется писать его только тогда, когда к ошибке не подходит ничего из вышеперечисленного.
  • Предложение по улучшению (enhancement) – строго говоря, это – не баг, и во многих фирмах не принято его писать в список багов; имеется в виду, что приложение работает по требованиям, но можно улучшить его работу, если внести предлагаемые изменения.

Примечание: Может ли у ошибки быть сразу несколько симптомов? Да, может. Но выбирать лучше самый важный (наиболее показательный).

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

Вроде бы, мы рассмотрели наиболее распространенные атрибуты для bug report. Все из перечисленных полей(атрибутов) заполняются создателем отчета. Поле приоритет редактируется менеджером проекта.

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

Что такое баг? Поговорим об ошибках в играх и программах

Баг — жаргонное слово, употребляемое програмистами, обозначающее ошибку, просчет в программе. Дословно переводится с английского как «жук, мелкое насекомое».

История

Откуда этот «термин» произошел, достоверно не известно. Существуют две наиболее популярные версии. Первая отсылает нас к Томасу Эдисону, который заметил помехи в фонографе, и посчитал что они появились из-за заползшего туда таракана. Развинтив коробку устройства, изобретатель не нашел никакого таракана и понял, что баг находится в самом устройстве. Вторая версия утверждает что в 1945 году, гарвардские ученые тестировали электронную вычислительную машину Mark II Aiken Relay Calculator. Устройство работало некорректно, и когда его вскрыли, между контактами реле был найден мотылек. Насекомое было признано виновным в поломке, а в техническую книгу была внесена запись: «First actual case of bug being found». С тех пор, слово баг и приобрело значение «компьютерной ошибки.»

Классификация ошибок

Программисты делят баги на несколько категорий в зависимости от их характеристик.

Относительно своих размеров, баги делятся на три вида:

  • Незначительные ошибки.
  • Серьёзные ошибки.
  • Showstoppers.

В зависимости от фазы разработки ПО, во время которой обнаруживаются баги,их делят на:

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

Относительно частоты своего появления баги делятся на:

  • постоянные;
  • эпизодичные;
  • те, которые появляются только на машине клиента.

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

Баги также делятся на разновидности

  • Борбаг — легкообнаруживаемая, стабильная ошибка.
  • Гейзенбаг. Такую ошибку обнаружить довольно затруднительно. Она периодически исчезает, или меняет свойства.
  • Мандельбаг — ошибка с энтропийным, непредсказуемым поведением.
  • Шрединбаг — опасная критическая ошибка. Никак себя не показывает, до тех пор, пока программист на неё случайно не встретит её в исходном коде. Обычно, после обнаружения такого бага, программа перестает функционировать.

Самым известным багом современности считается, так называемая «Ошибка 2000 года», или Y2K Error. Экономные программисты XX века не закладывали в память первые две цифры даты, которые отвечали за значение текущего тысячелетия. Менялись только только последние две, отвечающие за десятилетия. Таким образом, при наступлении миллениума, дата на всех компьютерах должна была обновиться с 1999 на 1900. Такой баг сулил множество неприятностей и критических ошибок большинству программ, так как получалось, что время пошло назад. К счастью, программисты вовремя обнаружили опасность и устранили её.

Что такое баг? Поговорим об ошибках в играх и программах

Широко распространена легенда, что 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] .

Почему в играх есть баги?

Достаточно часто у игроков возникает резонный вопрос к разработчикам: откуда вообще берутся баги, если существуют ПТС, отделы QA и прочие инструменты, направленные на «отлов» ошибок.

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

Почему баги вообще существуют?

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

Что влияет на скорость устранения багов?

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

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

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

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

Илон Маск рекомендует:  Определение слова релиз, релиз-кандидат

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

Как так получается, что баги с ПТС все же переходят на основной сервер?

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

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

Почему некоторые ошибки и вовсе не возникают на ПТС?

Это достаточно сложный вопрос и одного ответа тут не может быть. Прежде всего, ПТС во многом отличается от других способов, простейший из которых — рабочая нагрузка сервера, которая становится причиной множества проблем в игре. Во-вторых, если ошибка непостоянная, то это означает, что она вызвана особыми условиями, которых нет у большинства игроков. Часто сложно найти то, что возникает в редких случаях на ПТС. В-третьих, баг может появляться в игровых режимах, которыми игроки не часто пользуются. Лучший пример – это изменения в оружии. Обновление обычно содержит 2 новых вида оружия, в то время как остальные пушки получают различные изменения в характеристиках. Очевидно, что большинство игроков рванет тестировать новое оружие, в то время как старое останется без внимания. Это один из возможных способов упустить ошибку.

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

У вас есть тестировщики? Почему постоянные игроки должны прилагать усилия для поиска ошибок?

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

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

Как обрабатываются сообщения об ошибках?

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

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

Значение слова &laquoбаг»

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

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

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

1. комп. жарг. ошибка в компьютерной программе

2. комп. жарг. запись в багтрекере

Баг I

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Когда-нибудь я тоже научусь различать смыслы слов.

В каком смысле употребляется прилагательное правильный в отрывке:


Конечно должно, но при не правильном подходе оно не будет выполнено так, как вы хотите.

Как правильно описывать похожие баги или один баг в разных браузерах

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

Однотипные баги в разных местах

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

Рассмотрим данные ситуации подробнее:

  1. При изменении локализации некоторые элементы не переведены.

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

  • Названия разделов «Women», «Dresses» и «T-Shirts» не переведены на главной странице сайта после переключения языка сайта на «Русский».
  • Текст баннеров «Excepteur occaecat», «3 Days sale» и «Only online summer» не переведен на главной странице сайта после переключения языка сайта на «Русский».

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

Например:

Summary: Курсор мыши не меняется на «Указатель» на главной странице сайта после наведения на кнопку «Обратная связь».

Description: Курсор мыши не меняется на «Указатель» на главной странице сайта после наведения на кнопку «Обратная связь». Дефект также воспроизводится для кнопок «Добавить в корзину» и «Избранное».

  1. Текст выходит за пределы отведенной области.

На скриншоте отчетливо видно, что текст кнопок «Toista panos» и «Toista panos x2» выходит за пределы отведенной области. В данном случае не стоит заводить отдельные отчеты об ошибках на каждый отдельный элемент. Лучше завести один баг-репорт, в котором перечислить найденные элементы с дефектами:

  • Текст кнопок «Toista panos» и «Toista panos x2» выходит за пределы отведенной области на экране «Table» после переключения языка на «Finnish».

Если дефект воспроизводится для нескольких языков, или для всех, кроме некоторых, то в таком случае их необходимо перечислить в поле «Подробное описание» (Description).

Например:

Summary: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.

Description: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen. The issue is reproduced with all languages, except English.

Также рассмотрим одну из типичных ошибок новичков.

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

  • Кнопка «Корзина» не выровнена по горизонтали и вертикали на главной странице сайта.

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

Что делать, если баг встретился в разных браузерах?

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

Необходимо просто перечислить все браузеры / устройства / ОС в одном баг-репорте, на которых воспроизводится баг в отдельном поле «Environment», если оно есть, либо в «Additional Info».

Пример:

Environment:
Safari 4.1.3
IE 11.435
Chrome 43.567 (56)

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

Пример:

Кнопка «Вход» не переведена и отображается как «Enter» на страницах «Регистрация», «Меню» и «Поиск». На остальных же – отображается переведенной. Если в шагах мы указали, как воспроизвести баг, скажем, для страницы «Search», тогда в «Additional Info» пишется:

The bug is also reproduced on the «Registration» and «Menu» pages.


Стоит понимать, что можно объединить несколько однотипных инцидентов в один, но чаще всего один баг-репорт должен сообщать об одном баге.

Освежим в памяти основные понятия при заведении бага:

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

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

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

Атрибуты бага в баг-трекере:

ID – это уникальный идентификатор бага в баг-трекере. Автоматически присваивается системой.

Summary – краткое и лаконичное описание бага, отвечающее на вопрос «Что произошло, где произошло и при каких условиях?».

Например: «The «404 Page not Found» error message is shown (что?) on the «Contact us» page (где?) after clicking the «Contact us» link (когда?)». То есть описание бага должно быть такое, чтобы программисту его даже можно было не открывать, а сразу искать в чем же баг. Но чаще попадаются все же сложные баги, которые и требуют описания внутри дополнительных действий и разъяснений, как же его воспроизвести и как на самом деле должно быть, так что только по Summary может быть трудно понять проблему. Поэтому существуют следующие, приведенные ниже, поля:

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

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

Так как шаги создания админа – не суть этого бага, то это действие можно вынести в Preconditions. Например: «A new admin account is created»

Steps to Reproduce – поле используется для описания шагов, необходимых для воспроизведения данного бага.

Например:

  1. Open the login page of admin panel.
  2. Enter valid credentials into the «Username» and «Password» text fields.
  3. Click the «Sign in» button.

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

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

The «You have entered incorrect user or password» message is displayed on the login page after entering valid credentials

Expected Result – правильное поведение системы после выполнения последнего шага.

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

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

В разных баг-трекерах приоритетность может определяться разными уровнями (от «Immediate» до «Low», или цифрами от 1 до 4), принцип от наивысшего приоритета к низшему. В некоторых трекерах может вовсе и не быть такого поля (например, Pivotal tracker).

Severity – указывает на серьезность ошибки с точки зрения влияния на работу ПО. Существуют несколько уровней серьезности ошибки, таких как:

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

Также, как и в случае с Priority, в разных трекерах уровни серьезности могут быть разными, но все они отражают вышеизложенную суть.

Следует отметить, что во многих случаях Severity бага будет примерно равен его Priority. Но это не всегда так.

Например:

  • Логотип компании на главной странице отображается неверно или не отображается вовсе. Такого рода дефект не оказывает никакого влияния на функционал сайта, но с точки зрения бизнеса, это очень серьезно. В итоге, имеем наинизшую серьезность и наивысший приоритет.
  • Отображается ошибка 404 при попытке перейти в один из разделов сайта. Казалось бы, необходимо устанавливать максимальные Severity и Priority, но менеджер проекта два дня назад сообщил, что в текущей итерации работ в том функционале не планируется, т.к. это не самый важный функционал и есть задачи более важные. В итоге, имеем Severity = Blocker, но Priority = Low.

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

Илон Маск рекомендует:  Что такое код mcrypt_create_iv

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

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

FAQ: отчет об ошибке. Как, что, зачем? Шаблоны баг-репортов

#1 ch_ip

  • Members

  • 1 097 сообщений
    • ФИО: Павел Абдюшев
    • Город: Москва

    Исходно к созданию данного FAQ послужил пост Sana в этой ветке форума:

    помогите, пожалуйста, найти/составить приближенный к идеалу отчет про ошибки (такой себе шаблон)

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

    что еще добавить/изменить? было бы не плохо посмотреть на пример

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

    Итак, подборка ссылок из интернета (дополнения приветствуются):
    Статьи

    • «Работа над ошибками малой кровью» — статья Джоэла Спольски с примером оформления дефекта и рассказом о его жизненном цикле.
    • Серия постов «Мысли о баг-репортах» Сергея Атрощенкова в его блоге. Очень подробно и с примерами как составлять заголовк бага, его описание и какую дополнительную информацию стоит прикреплять в виде аттачментов. На основе 4-х постов собрано краткое руководство в формате гуглодока.
    • Серия постов о баг-репортах в блоге «Про Тестинг» про стуктуру и жизненный цикл баг-репортов в таблицах и схемах. Разобраны основные поля, которые есть у отчета, кто их заполняет, распространенные ошибки при создании баг-репортов.
    • Статья «6. Написание запросов в системе отслеживания ошибок» из цикла «TOP 13 ошибок тестировщиков. Часть II. Управление ошибками » — в библиотеке software-testing.ru. Приведен шаблон баг-репорта с подробным описанием каждой части шаблона и градаций типа отчета и степени важности
    • Статья в блоге Алексея Лупана (не только про отчеты об ошибке, но и про тестовые задания и поиск работы. Must read для начинающих, тем более, что слог Алексея прекрасен и читается на одном дыхании)
    • Памятка составляющему отчет об ошибке — краткое пошаговое руководство к дейтсвия от момента нахождения ошибки до полного занесения в БТС (баг-трекинговая система)
    • Распространенные ошибки при составлении баг-репортов — разбор 7 ошибок на хабре (взгляд со стороны разработки)
    • И ответ Андрея Адеркина на статью о распостраненных ошибках с хабра — статья «Как правильно составлять баг-репорты» (ответ тестировщиков — достаточно кратко, есть примеры плохих/хороших заголовков, разница между severity и priority)
    • Почему не нужны эмоции в отчетах об ошибках — заметка по совету из книжки «Lessons Learned in Software Testing» (Cem Kaner, James Bach, Bret Pettichord) от Оли Киселевой.
    • Отчет об ошибке — небольшая статья с основами в блоге QA & ST — очень кратко, но все по делу. Как шпаргалка для экзамена собеседования
    • «Правильный багрепорт для всех и каждого»— статья Павла Буленко из блога «Not so critical» о том, почему нужны шаблоны отчетов с историей о том, как автор пришел к этому пониманию и какие выгоды получил.
    • Как эффективно сообщать об ошибках — прекрасное эссе Саймона Тэтхема — программиста: «В этом эссе я попытаюсь ясно сформулировать, что делает сообщение об ошибке хорошим. В идеале я хотел бы, чтобы все в мире прочитали этот очерк перед тем, как сообщать кому-либо об ошибках.»

    Доклады
    50. Прекрасный доклад Алексея Лянгузова на SQA Days «Грамотная работа с дефект-трекером — путь к успеху». Очень подробно о том, как именно писать ошибки (а вы знаете 4 способа написания заголовков?) и о том, что еще можно делать с БТС

    51. «Как заводить баги понятно всем» — доклад Казначеевой Анастасии на SQA Days-11
    52. Доклад Сергея Атрощенкова Отчеты об ошибках, или как просто встать на путь постоянного совершенствования с конференции confetQA

    Обсуждения на форумах:
    71. Обсуждение на этом форуме, как писать баг-репорты, для начинающего тестировщика с примерами шаблонов
    72. Ссылка на тему-рекламу семинара Сергея Мартыненко «Как описать дефект». Уже из программы семинара можно получить ряд вопросов, над которыми стоит задуматься
    73. Пример, почему не всегда надо заносить все дефекты в баг-трекер (хорошее обсуждение темы, все ли баги надо заносить в баг-трекер)
    74. Пример испльзования стандартных терминов при описании бага, чтобы его было легче найти (и не заводить дубликаты)
    75. Обсуждение добавления скриншотов к описанию ошибки на этом форуме
    76. Классификация полей в отчетах об ошибке (рекомендую прочитать все обсуждение. Полезно, несмотря на давность лет)
    77. Как правильно ловить баги — инструкция для бета-тестировщиков игр с описанием того, как заводить баг-репорт.
    78. Как правильно писать отчет об ошибке — объяснение на пальцах для блондинок
    79. Обсуждение описания ошибки про сообщение об ошибке. Очень интересное обсуждение с разными вариантами описания одного и того же бага, а также споров на тему, что надо включать в отчет об ошибке, а что нет.

    Другое

    • Пример баг-темплейта на сервисе по формированию шаблонов для баг-репортов для разных трекеров (Jira, Trac, Redmine, github)
    • Как правильно обращаться с багом в картинках. Спасибо Andy Glover (http://cartoontester.blogspot.com) —
    • Как правильно описывать баг — в картинках. Спасибо Andy Glover (http://cartoontester.blogspot.com)

    P.S. ключевые слова для поиска: Issue Document, bug report, defect report, issue report, отчет об ошибке, работа с багтрекером, описание бага, описание ошибки, шаблон бага, шаблон ошибки, bug template, issue template

    Сообщение отредактировал ch_ip: 18 Март 2015 — 07:33

    Какие баги находят тестировщики?

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

    11 месяцев назад

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

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

    Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет эксперт и руководитель отдела тестирования компании Inlingo Андрей Васильев.

    Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

    Итак, баги в играх можно условно классифицировать по следующим категориям:

    Баги, связанные с самой игрой:

    • Баги функциональности. Не работают или неправильно работают какие-то функции в игре. Например, при переходе в настройки приложения происходит аварийное завершение работы;
    • Баги интерфейса. Искажается графика, элементы не находятся на своих местах, текст не вписывается в отведенные ему рамки;
    • Баги локализации. Ошибки в текстах, присутствие непереведенных строк. Скажем, вместо перевода выводятся заглушки, вроде “russian_text_001”;
    • Баги производительности. Приложение на устройстве работает медленно. Например, во время анимации атаки персонажа FPS заметно «проседает» на устройствах high-end сегмента;
    • Баги логики и баланса. Выставленные настройки баланса и игровой логики не позволяют пройти игру или достигнуть нужных целей. К примеру, персонаж наносит урон в 100 единиц, вместо 150 обещанных в игре;
    • Технические баги. Игра неправильно работает в условиях нестабильного интернет-соединения, как вариант, приложение не может подключиться к серверу в 3G сетях;
    • Баги совместимости. Игра попросту не работает на совместимом устройстве или запускается с критическими ошибками.

    Потренируемся: какой это баг по классификациям? Если вы ответили: «Функциональный, низкоприоритетный, графический, затрагивающий команду разработки», то ура — вы тестировщик (нет)

    Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

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


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

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

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

    От чего зависит число багов в игре?

    Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

    1. В первую очередь это зависит от опытности команды разработки.
    2. На втором месте стоит техническая сложность проекта. Шансы появления багов прямо пропорциональны количеству кода и числу используемых библиотек.
    3. На третьем месте — количество возможностей в игре и разнообразие игрового процесса в целом.
    4. Серьёзная статья — это сетевой режим и пути взаимодействия игроков друг с другом. Для сетевого режима разработчики зачастую даже в играх, уже прошедших тестирование на этапе производства, запускают закрытые тестирования для настройки баланса и поиска неочевидных багов.
    5. Ну и конечно, прямая зависимость от эффективности тестирования именно на раннем этапе разработки. Дело в том, что чем больше багов будет найдено как можно раньше, тем меньше шансов, что эти баги позже приведут к появлению новых.

    Привязка выявляемого количества багов к жанрам

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

    Хороший пример того, как игроки испытывают игру на прочность. Skyrim в этом смысле рекордсмен.

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

    • Игры в жанре match-3. Здесь игрок ограничен только игровым полем и комбинациями фишек, бонусов и количеством игровых механик;
    • Игры в жанре h >

    COD WWII за принципиально новый эко-транспорт

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

    Ошибки дизайна уровней

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

    Ошибки обратной связи

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

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

    Ошибки игрового баланса

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

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

    А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

    Жизнь — это движение! А тестирование — это жизнь :)

    пятница, 29 мая 2015 г.

    Ошибка, дефект и сбой — чем отличаются

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

    Практика показывает, что нет

    Три года назад (кошмар, сколько времени прошло!) я была в летней школе тестировщиков. Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог.

    Алексей мог зачитать умные слова из справочника ISTQB, но предпочел рассказать историю. Три года прошло! Я помню историю до сих пор и могу назвать отличия без подглядывания в гугл :)

    Вступление от Алексея — придумал историю не сам. На одном из тренингов я задал этот вопрос. Девочки посовещались между собой и сказали: «Мы не можем объяснить это с точки зрения ПО, но можем на примере шитья». Я удивился и сказал: «Давайте!».

    Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья.


    Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом.

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

    Девочка опустила руку в карман, отпустила ключ. У-у-у-упс, ключ выпал на пол! Произошел сбой в системе — проявился ранее скрытый дефект.

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

    Такие дела!
    Надеюсь, эта история поможет вам запомнить разницу так же, как она помогла мне. И помните — не всегда надо зубрить, иногда достаточно придумать знакомую и понятную альтернативу :)

    А под конец немножко официоза — версия из ISTQB, которую мне любезно процитировали мои студенты. А ведь ради них я и пишу эти статьи!

    A human being can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or in a document. If a defect in code is executed, the system will fail to do what it should do (or do something it souldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.

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

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL