Что такое баг и почему программы содержат ошибки

Зачем вам это знать?

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

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

Теория

Шаг 1. Что такое программа?

Прежде чем говорить об ошибках, разберёмся, что вообще такое программа.

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

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

Шаг 2. Что такое баг?

Баг (от английского bug — жук, насекомое) — это ошибка в программе, из-за которой она ведёт себя не так, как ожидается.

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

Формально баг можно описать так:

Баг = разница между тем, как программа ведёт себя на самом деле, и тем, как она должна себя вести.

Разберём на примере:

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

Баги не появляются сами по себе. У каждого бага есть причина. Давайте разберём основные из них.

Причина 1. Человеческая ошибка при написании кода

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

Посмотрите на простой пример. Представьте, что программа должна проверять: достиг ли пользователь 18 лет.

# Правильный вариант: пускать тех, кому 18 и больше
if age >= 18:
    print("Добро пожаловать!")

# Вариант с багом: пускать только тех, кому БОЛЬШЕ 18
# Человеку ровно 18 лет — он не пройдёт, хотя должен!
if age > 18:
    print("Добро пожаловать!")

Разница между >= (больше или равно) и > (строго больше) — один символ. Но именно из-за него 18-летние пользователи будут получать отказ. Это баг.

💡 Пояснение для новичков. Не пугайтесь кода выше — он просто иллюстрирует идею. age — это переменная (ячейка памяти, в которой хранится возраст пользователя). if — это условие: «если». print — вывести текст на экран. Смысл: «если возраст пользователя больше или равен 18, показать приветствие».

Причина 2. Непонимание требований

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

Представьте, что требование звучит так: «Скидка 10% предоставляется постоянным клиентам». Разработчик решает, что «постоянный» — это тот, кто сделал хотя бы 1 покупку. А заказчик имел в виду тех, кто сделал 5 и более покупок. Программа написана, но написана неверно — потому что люди поняли задачу по-разному.

Это очень распространённая причина багов. Её ещё называют ошибкой в требованиях.

Причина 3. Непредвиденные ситуации

Разработчик пишет программу и думает о «нормальных» сценариях: пользователь вводит своё имя, выбирает товар, платит. Но пользователи бывают непредсказуемы:

• Что, если в поле «Имя» кто-то введёт цифры?
• Что, если пользователь нажмёт кнопку «Оплатить» дважды за полсекунды?
• Что, если интернет пропадёт в момент оплаты?

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

Причина 4. Взаимодействие разных частей программы

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

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

Причина 5. Изменения в программе

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

Регрессия — это ситуация, когда после изменения программы что-то, что раньше работало, перестало работать.

Например: разработчик поправил корзину покупок — и случайно сломал форму регистрации. Раньше регистрация работала нормально, но теперь нет. Это баг-регрессия.

Шаг 4. Чем баг отличается от «фичи»?

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

Иногда сложно сразу понять: это баг или так задумано? Золотое правило:

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

Шаг 5. Насколько серьёзен баг? Понятие критичности

Не все баги одинаково опасны. Тестировщики оценивают критичность (или серьёзность) бага — насколько сильно он мешает работе программы.

Вот простая шкала:

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

Шаг 6. Почему баги невозможно устранить полностью?

Это важный философский момент в профессии тестировщика.

Существует известная идея в мире тестирования:

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

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

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

Пример: Разбор реального бага

Представьте, что вы тестируете форму регистрации на сайте. В ней есть поле «Возраст».

Сценарий: Что происходит, если ввести отрицательный возраст?

Вы вводите в поле «Возраст» значение -5 и нажимаете «Зарегистрироваться».

Ожидаемый результат: Появляется сообщение об ошибке: «Введите корректный возраст».

Фактический результат: Регистрация прошла успешно. В системе появился пользователь с возрастом -5 лет.

Это баг. Давайте разберём его по всем параметрам:

Название бага:  Форма регистрации принимает отрицательный возраст

Шаги для воспроизведения:
  1. Открыть страницу регистрации
  2. Заполнить все обязательные поля
  3. В поле "Возраст" ввести значение -5
  4. Нажать кнопку "Зарегистрироваться"

Ожидаемый результат:
  Появляется сообщение об ошибке.
  Регистрация не выполняется.

Фактический результат:
  Регистрация выполнена успешно.
  В системе создан пользователь с возрастом -5 лет.

Критичность: Средняя (Minor)
  Причина: функция регистрации работает,
  но данные в системе некорректны, что может вызвать
  проблемы в других частях программы.

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

Практика

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

Упражнение 1. Найдите баг в повседневной жизни

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

Опишите ситуацию по следующей схеме:

1. Какое приложение или сайт?
2. Что вы делали (шаги)?
3. Что вы ожидали увидеть?
4. Что произошло на самом деле?
5. Как бы вы оценили критичность этого бага: критический, высокий, средний или низкий? Почему?

Запишите ответы в тетрадь или текстовый файл.

Упражнение 2. Баг или фича?

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

Ситуация А. В интернет-магазине требование звучит так: «Пользователь может добавить не более 10 единиц одного товара в корзину». Вы пробуете добавить 11 — и получаете сообщение: «Максимальное количество — 10».

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

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

Упражнение 3. Определите критичность

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

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

Упражнение 4. Напишите описание бага

Представьте следующую ситуацию:

Вы тестируете калькулятор на сайте. Вы умножаете 0 на любое число — например, 0 × 999 — и вместо ответа 0 калькулятор показывает 999.

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

• Название бага
• Шаги для воспроизведения
• Ожидаемый результат
• Фактический результат
• Критичность (и обоснование)

Ключевые выводы

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

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