Ошибка баг как пишется

Русский

Морфологические и синтаксические свойства

баг

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 3a по классификации А. А. Зализняка).

Корень: -баг-.

Произношение

• МФА: ед. ч. [bak]  мн. ч. [ˈbaɡʲɪ]

омофоны: бак

Семантические свойства

Значение

1. комп. жарг. ошибка в компьютерной программе ◆ В программе найден баг. ◆ Это не баг, это фича
2. комп. жарг. запись в багтрекере ◆ Пометил баг 419594 как WONTFIX. Если у кого есть какие-нибудь возражения/предложения, то рекомендую писать на странице обсуждения бага… «Форум Mozilla Россия», 2008 г.

Синонимы

1. жарг.: глюк

Антонимы

Гиперонимы

1. ошибка, мутация

Гипонимы

Родственные слова

Этимология

Заимствование из англ. bug.

Фразеологизмы и устойчивые сочетания

Пословицы и поговорки

• это не баг, это фича

Перевод

Библиография

• Шагалова Е. Н. Словарь новейших иностранных слов (конец XX — начало XXI вв.): более 3000 слов и словосочетаний. — М. : АСТ: Астрель, 2010. — 943, [1] с. — (Biblio). — ISBN 978-5-17-061488-2, ISBN 978-5-17-061488-2.

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

Калмыцкий

Морфологические и синтаксические свойства

баг

Существительное.

Корень: —.

Произношение

Семантические свойства

Значение

1. группа ◆ Отсутствует пример употребления (см. рекомендации).
2. шайка
3. пучок
4. стая

Синонимы

Антонимы

Гиперонимы

Гипонимы

Родственные слова

Этимология

Происходит от ??

Фразеологизмы и устойчивые сочетания

Библиография

• Калмыцко-русский словарь. Москва. 1977

Для улучшения этой статьи желательно: Добавить описание морфемного состава с помощью {{морфо}} Добавить транскрипцию в секцию «Произношение» с помощью {{transcriptions}} Добавить пример словоупотребления для значения с помощью {{пример}} Добавить синонимы в секцию «Семантические свойства» Добавить гиперонимы в секцию «Семантические свойства» Добавить сведения об этимологии в секцию «Этимология»

Монгольский

Морфологические и синтаксические свойства

баг

Существительное.

Корень: —.

Произношение

Семантические свойства

Значение

1. команда ◆ Отсутствует пример употребления (см. рекомендации).
2. маска
3. баг, низовая административная единица в сельской местности

Синонимы

Антонимы

Гиперонимы

Гипонимы

Родственные слова

Этимология

Происходит от ??

Фразеологизмы и устойчивые сочетания

Библиография

• Большой академический монгольско-русский словарь. Москва. 2002

Для улучшения этой статьи желательно: Добавить описание морфемного состава с помощью {{морфо}} Добавить транскрипцию в секцию «Произношение» с помощью {{transcriptions}} Добавить пример словоупотребления для значения с помощью {{пример}} Добавить синонимы в секцию «Семантические свойства» Добавить гиперонимы в секцию «Семантические свойства» Добавить сведения об этимологии в секцию «Этимология»

Сербский

Морфологические и синтаксические свойства

баг
(bag)

Существительное, мужской род.

Корень: —.

Произношение

Семантические свойства

Значение

1. комп. баг, ошибка в программе ◆ Отсутствует пример употребления (см. рекомендации).
2. жучок, устройство для прослушки ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы

Антонимы

Гиперонимы

Гипонимы

Родственные слова

Этимология

Происходит от англ. bug «жук».

Фразеологизмы и устойчивые сочетания

Библиография

Тувинский

Морфологические и синтаксические свойства

баг

Существительное.

Корень: —.

Произношение

Семантические свойства

Значение

1. ремень ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы

Антонимы

Гиперонимы

Гипонимы

Родственные слова

Этимология

Происходит от ??

Фразеологизмы и устойчивые сочетания

Библиография

• Тувинско-русский словарь. Москва. 1968

Для улучшения этой статьи желательно: Добавить описание морфемного состава с помощью {{морфо}} Добавить транскрипцию в секцию «Произношение» с помощью {{transcriptions}} Добавить пример словоупотребления для значения с помощью {{пример}} Добавить синонимы в секцию «Семантические свойства» Добавить гиперонимы в секцию «Семантические свойства» Добавить сведения об этимологии в секцию «Этимология»

У этого термина существуют и другие значения, см. Ошибка.

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

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

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

Этимология термина «баг»[править | править вики-текст]

В значении неуловимой технической ошибки слово жучок (англ. bug) употреблялось задолго до появления компьютеров персоналом телеграфных и телефонных компаний в отношении неполадок с электрооборудованием и радиотехникой. В 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.

Во время Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой.

По одной из версий, в отношении программной ошибки этот термин впервые применила в 1946 году Грейс Хоппер, программировавшая в Гарвардском университете вычислительную машину Harvard Mark II (англ.)русск.. Проследив ошибку в работе программы до электромеханического реле машины, она нашла мотылька, застрявшего между контактами. Извлечённое насекомое было вклеено скотчем в технический дневник с сопроводительной надписью: «Первый реальный случай обнаружения жучка» (англ. First actual case of bug being found)^[2].

Значение и классификация ошибок программного обеспечения[править | править вики-текст]

В зависимости от этапа разработки ПО, на котором выявляется ошибка выделяют:

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

По размеру:

• Showstoppers;
• Серьёзные;
• Незначительные баги;

По времени появления:

• Постоянно, при каждом запуске;
• Иногда («плавающий» тип);
• Только на машине у клиента (зависит от локальных настроек у клиента);

По месту и направлению:

• Ошибки пользовательского интерфейса;
• Системы обработки ошибок;
• Ошибки, связанные с граничными условиями;
• Ошибки вычислений;
• Ошибки управления потоком;
• Ошибки обработки или интерпретации данных;
• При состоянии гонки;
• Повышение нагрузки;
• Ошибки контроля версии и индентификаторов;
• Ошибки тестирования;

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

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

Разновидности[править | править вики-текст]

• Борбаг — легко обнаруживаемый стабильный баг
• Гейзенбаг — сложно обнаруживаемый, периодически исчезающий и меняющий свойства баг при попытке его обнаружения
• Мандельбаг — баг с очень сложным, хаотичным, поведением
• Шрёдинбаг — критическая ошибка, которая не проявляется пока кто-нибудь на неё не наткнется в исходном коде, после чего программа совершенно перестает работать

Поиск и исправление ошибок[править | править вики-текст]

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

Отчёты об ошибках[править | править вики-текст]

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

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

Последствия[править | править вики-текст]

• Катастрофа Ariane 5 (4 июня 1996) — один из самых дорогостоящих компьютерных багов в истории.
• Ошибки в программном обеспечении медицинского ускорителя Therac-25 привели к превышению доз облучения нескольких людей.

См. также[править | править вики-текст]

• Отчет об ошибке
• Система отслеживания ошибок
• Фича
• GIGO

Примечания[править | править вики-текст]

Ссылки[править | править вики-текст]

• Уязвимости в исходных кодах, «Компьютерная газета». Продолжение: Уязвимости в исходных кодах. Перепечатка: 1 часть, 2 часть.
• 10 худших ошибок в программировании в истории человечества
• 2010 CWE/SANS Top 25 Most Dangerous Software Errors частичный перевод на русский 25 самых опасных ошибок при создании программ
• Ошибки, обнаруженные в Open Source проектах разработчиками PVS-Studio с помощью статического анализа. Можно найти полезные примеры при подготовки статей и презентаций.

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

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

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

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

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

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

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

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

Почему?)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь:

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

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

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

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

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

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

Баг в UX:

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

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

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

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

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

1. Стресс
2. Спешка
3. Усталость, болезнь
4. Непонимание задания
5. Отсутствие коммуникации
6. Невозможность сконцентрироваться
7. Некомпетентность
8. Чрезмерная сложность ПО
9. Отсутствие документации / информации
10. …

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

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

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

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

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

Нет, не все.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S4 | Blocker

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

Примеры:

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

S3 | Critical

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

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

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

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

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

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

Примеры: 

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

S2 | Major

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

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

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

Примеры:

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

S1 | Minor

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

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

Примеры:

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

S0 | Trivial

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

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

Примеры:

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

Типы багов

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

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

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

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

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

Примеры:

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

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

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

Примеры:

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

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

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

Примеры:

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

SEO (ошибка в seo)

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Серьезность

S1 (minor)

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

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

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

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

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

Здесь:

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

Источники

1. Баг (значения) // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Баг_(значения) (дата обращения: 28.10.2020).
2. Программная ошибка // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Программная_ошибка (дата обращения: 28.10.2020).
3. 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]
4. Куликов С. Тестирование программного обеспечения Базовый курс. — 3 изд. 2020. — 298 с.
5. Программа подготовки ISTQB Базового уровня 2018
   [https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_Syllabus_2018-RU.pdf]

FAQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Логические

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

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

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

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

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

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

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

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

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

Ресурсные

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

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

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

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

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

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

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

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

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

Выводы

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

//В конце команды забыли поставить точку с запятой (;)
int a = 5

int main()
{
   //Мы создаём две переменные, которые просто занимают память и никак не используются
   int a, b;
}

//Создаём константный массив символов 
const char * s = "Hello World";
//Если мы попытаемся перезаписать значение константы, компилятор выдаст ошибку
//Но с помощью указателей мы можем обойти её, поэтому программа успешно скомпилируется
//Однако во время работы она будет выдавать ошибку сегментации
* (char *) s = 'H';

int main()
{
   //Бесконечная рекурсия - одна из причин переполнения стека вызовов
   main();
}

class Program
{
   static void Main(string[] args)
   {
       Main(args);
   }
}

//Пробуем записать в переменную типа int значение, которое превышает лимит
//Константа INT_MAX находится в библиотеке climits
int a = INT_MAX + 1;

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

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

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

Программу с багами называют забагованной. А отладку кода – дебаггингом, то есть избавлением от багов.

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

Где встречаются баги

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

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

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

На сайтах. Современные сайты такие гибкие и функциональные благодаря скриптам, написанным на языках программирования. В браузере работает JavaScript, на сервере языки могут быть разными: PHP, Python, Ruby и другие. Баг может возникнуть и на стороне сервера, и в клиентской части сайта – иногда его замечают только после выпуска в продакшн. Есть даже понятие bug bounty: вознаграждение, которое компания выплачивает пользователю, нашедшему критичный баг в информационной безопасности.

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

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

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

Из-за чего возникают баги

Мы выяснили, что такое баг. Теперь поговорим о причинах, из-за которых они появляются.

• Первая и наиболее распространенная причина – ошибка разработчика. В IT-среде есть шутка: «Кто же победит: человек, венец природы… или крохотная забытая скобочка?». Маленькие недочеты могут быть очень критичными. Если поставить плюс вместо минуса в простейшем математическом вычислении, то получится совершенно другой результат.
• Иногда причиной багов становится незнание. Например, разработчик был не в курсе специфического поведения какой-нибудь конструкции в языке, поэтому воспользовался ею не совсем корректно.
• Часто баги возникают, если в команде программистов нет слаженности. Один не понимает, что написал другой, правит код по своему усмотрению и получает некорректное поведение программы.
• Наконец, дизайн программы и архитектурные ошибки тоже могут быть причиной багов. Использование неоптимальных алгоритмов, ведущих к сбоям, неверный выбор инструментов – все это может привести к забагованности.

Ворнинги, вылеты, исключения: чем отличаются от багов

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

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

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

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

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

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

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

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

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

Баги – это очень плохо?

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

Например, баг в медицинском оборудовании может привести к трагедии. Баг в коде сайта – к утечке огромного бюджета: так было, когда блокчейн-компания Compound случайно отправила своим пользователям почти 90 миллионов долларов. А самый дорогой баг в истории – арифметическое переполнение в программной начинке ракеты-носителя «Арион-5», из-за которого ракета взорвалась в полете.

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

Как избежать багов

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

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

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