БЛОК 6. Работа с багами — 18. Что такое баг и как его находить
🧭 Введение: что именно изучаем в этой теме
Эта лекция про два первых шага:
как распознать баг и как его подтвердить фактами.
Подробное оформление bug report будет в следующих темах блока.
Для junior это важный старт:
если не уметь отличать баг от не-бага, в трекер попадет шум,
а реальные дефекты останутся без внимания.
💡 Совет:
В этой теме думай так: сначала найти, потом доказать, и только потом оформлять.
✅ Вывод:
Цель лекции — научиться видеть дефект и подтверждать его, а не просто "писать тикеты".
⚠️ Проблема -> решение
Проблема:
новички часто проверяют только happy path и пропускают баги в негативных сценариях, границах и ролях.
Еще одна проблема — есть подозрение на баг, но нет доказательств.
Решение:
использовать короткий, повторяемый алгоритм поиска:
expected -> проверка -> отклонение -> подтверждение -> факты.
🟢 Если совсем просто:
Сначала понимаем, как должно быть. Потом ищем, где не совпало. Потом подтверждаем это данными.
🎯 Как понять, что этап прошел успешно:
Ты можешь показать, что именно нарушено и на чем основано ожидание.
🛠️ Чем помогает и как работает
Системный поиск багов помогает:
- быстрее находить критичные проблемы;
- меньше спорить "баг это или нет";
- не тратить время команды на ложные репорты.
Как это работает:
- Шаг 1: определить expected behavior.
- Шаг 2: проверить happy + negative + boundary + edge.
- Шаг 3: зафиксировать отклонения.
- Шаг 4: подтвердить воспроизводимость.
- Шаг 5: собрать минимальный набор фактов.
✅ Вывод:
Хороший QA не ищет баги случайно, а работает по понятной схеме.
📚 Ключевые термины (простыми словами)
- Баг (bug) — отклонение фактического поведения от ожидаемого.
- Expected result — как система должна работать.
- Actual result — как система работает по факту.
- Reproducibility — можно ли повторить проблему.
- Severity — насколько тяжел сам дефект.
- Priority — насколько срочно его нужно чинить.
1. Что считать багом, а что нет
Главное правило:
баг всегда привязан к ожидаемому поведению.
🟢 Если совсем просто:
Если нарушено согласованное ожидание — это баг.
🎯 Как понять, что этап прошел успешно:
К каждому багу можно приложить источник ожидания.
Назначение:
Отделить дефекты от пожеланий и спорных трактовок.
Простыми словами:
"Мне не нравится" — это не баг.
"Нарушен AC/контракт" — это баг.
Для новичка:
Перед заведением бага задай себе вопрос:
"На что я опираюсь, когда говорю, что это ошибка?"
✅ Вывод:
Без источника expected поведения баг заводить рано.
2. Откуда QA берет expected behavior
Этот блок нужно знать наизусть.
Он защищает от ложных багов и споров.
🟢 Если совсем просто:
Expected не придумывают. Его берут из согласованных источников.
🎯 Как понять, что этап прошел успешно:
В баге есть ссылка на конкретное ожидание из одного из источников.
Источники expected:
- требования;
- acceptance criteria;
- макеты;
- API-контракт;
- бизнес-правила;
- согласованное поведение команды (agreed team behavior).
✅ Вывод:
Чем точнее источник expected, тем меньше споров по дефекту.
3. Баг может быть не только в коде
Для junior это важный сдвиг мышления.
Проблема может быть не только "разработчик сломал функцию".
🟢 Если совсем просто:
Баг может жить в коде, логике, тексте, данных, конфиге и даже в самом требовании.
🎯 Как понять, что этап прошел успешно:
При анализе дефекта ты проверяешь не только UI, но и контекст задачи.
Пример зон, где бывает баг:
- противоречивое или неполное AC;
- неверная бизнес-логика;
- некорректный текст ошибки;
- плохие тестовые/боевые данные;
- ошибка конфигурации окружения;
- сбой интеграции внешнего сервиса.
✅ Вывод:
QA проверяет систему целиком, а не только "кнопки на экране".
4. Где чаще всего искать баги
Когда "всё выглядит нормально", помогают вопросы-провокаторы.
Они дают junior готовый паттерн поиска.
🟢 Если совсем просто:
Если не знаешь, где искать, проверяй ограничения, роли, повторы, сеть и порядок шагов.
🎯 Как понять, что этап прошел успешно:
Проверки выходят за пределы одного happy path.
Мини-набор вопросов для поиска багов:
- Что если поле пустое?
- Что если значение слишком длинное?
- Что если нажать кнопку дважды?
- Что если роль пользователя другая?
- Что если сеть медленная или нестабильная?
- Что если открыть ту же операцию в другой вкладке?
- Что если выполнить шаги в другом порядке?
✅ Вывод:
Эти вопросы помогают находить баги даже в "визуально нормальной" фиче.
5. Мини-чеклист "как искать баг"
Это рабочий чеклист перед созданием дефекта.
🟢 Если совсем просто:
Не отправляй баг, пока не прошел этот список.
🎯 Как понять, что этап прошел успешно:
По каждому пункту чеклиста есть ясный ответ.
Чеклист:
- Есть ли источник expected поведения?
- Воспроизводится ли проблема?
- Понятны ли шаги?
- Есть ли нужные test data?
- Зафиксировано ли окружение?
- Есть ли доказательства (скрин/видео/лог)?
- Это точно bug, а не improvement?
✅ Вывод:
Чеклист резко снижает количество шумных и спорных багов.
6. Найти баг и доказать баг — не одно и то же
Это ключевая мысль темы.
Найти баг недостаточно: его нужно доказать фактами.
🟢 Если совсем просто:
"Вижу проблему" -> это гипотеза.
"Есть шаги, expected/actual и воспроизводимость" -> это подтвержденный баг.
🎯 Как понять, что этап прошел успешно:
Другой человек может повторить проблему по твоему описанию.
Назначение:
Отделить наблюдение от доказанного дефекта.
Простыми словами:
QA ценен не только находкой, но и доказательной базой.
✅ Вывод:
Сильный QA не просто замечает проблему, а делает ее воспроизводимой для команды.
7. Finding bug vs Reporting bug (граница этой темы)
Чтобы не смешивать темы курса, фиксируем границу.
🟢 Если совсем просто:
Сейчас изучаем "как найти и подтвердить". Подробный "как оформлять" — следующая тема.
🎯 Как понять, что этап прошел успешно:
Ты умеешь собрать минимум данных для передачи, даже без углубления в полный шаблон bug report.
В этой лекции:
- как распознать баг;
- как подтвердить воспроизводимость;
- какие данные собрать сразу.
В следующей лекции:
- как структурно оформить bug report;
- как писать title и steps;
- как выбирать severity/priority в контексте triage.
✅ Вывод:
Разделение "finding" и "reporting" делает курс логичным и легче для новичка.
8. Severity и Priority (базовое различие)
Эти термины путают почти все новички.
Ниже короткая рабочая формула.
🟢 Если совсем просто:
Severity = насколько тяжёл дефект сам по себе.
Priority = насколько срочно его чинить.
🎯 Как понять, что этап прошел успешно:
Ты можешь объяснить, почему баг high severity, но не highest priority, и наоборот.
Сравнение:
| Параметр | Что означает | Кто чаще влияет |
|---|---|---|
| Severity | Техническая/пользовательская тяжесть дефекта | QA + разработка |
| Priority | Срочность исправления в плане релиза | QA + PM/lead |
✅ Вывод:
Severity и priority связаны, но это разные решения.
9. Ложные баги: откуда берутся
Ложные баги — частая проблема раннего junior.
Они создают шум и перегружают трекер.
🟢 Если совсем просто:
Ложный баг чаще всего появляется из-за неверного контекста, а не из-за злого умысла QA.
🎯 Как понять, что этап прошел успешно:
Перед отправкой дефекта ты проверяешь типовые причины ложной тревоги.
Ложный баг часто возникает, когда:
- не поняли requirement;
- тестировали не той ролью;
- использовали неправильные данные;
- проверяли в неподходящем окружении;
- не учли out of scope.
✅ Вывод:
Проверка контекста перед созданием бага экономит часы работы команде.
📌 Must-know факты
- Баг = подтвержденное отклонение от expected поведения.
- Expected поведение берется из согласованных источников, а не "из головы".
- Баг может быть не только в коде, но и в требованиях, данных, конфиге и интеграциях.
- Даже если "всё выглядит нормально", баги часто находятся через вопросы-провокаторы.
- Найти баг мало, его нужно доказать фактами.
❗ Частые мифы
❌ Миф: Баг — это всегда ошибка разработчика в коде.
✅ Как правильно: Дефект может быть в требованиях, логике, данных, конфиге, тексте и интеграциях.
📎 Почему это важно: QA должен видеть всю систему, а не только UI.
❌ Миф: Если визуально всё работает, багов нет.
✅ Как правильно: Нужно проверять негативы, границы, роли, повторы и нестабильную сеть.
📎 Почему это важно: Критичные дефекты часто скрыты за "нормальным" экраном.
❌ Миф: Нашел проблему — этого достаточно.
✅ Как правильно: Проблему нужно подтвердить и доказать фактами.
📎 Почему это важно: Без воспроизводимости и данных баг не ускоряет исправление.
❌ Миф: Любое неудобство интерфейса — баг.
✅ Как правильно: Нужно отделять defect от improvement.
📎 Почему это важно: Это снижает шум в трекере и упрощает приоритизацию.
💬 Часто спрашивают на собеседованиях
❓ Вопрос: Что такое баг в QA-практике?
✅ Ответ: Это подтвержденное отклонение фактического поведения от ожидаемого по требованиям, AC, контракту или согласованным правилам.
❓ Вопрос: Как QA понимает, что ожидание корректно?
✅ Ответ: QA опирается на источники expected поведения: требования, AC, макеты, API-контракт, бизнес-правила и командные договоренности.
❓ Вопрос: Где искать баги, если всё выглядит нормально?
✅ Ответ: Проверять негативные и граничные случаи, роли, повторы действий, сетевые сбои, разные последовательности шагов и параллельные действия.
❓ Вопрос: В чем разница между severity и priority?
✅ Ответ: Severity показывает тяжесть дефекта, а priority — срочность его исправления в релизном плане.
❓ Вопрос: Почему "найти баг" и "доказать баг" — это разные вещи?
✅ Ответ: Находка — это гипотеза, а доказанный баг содержит воспроизводимость и факты, которые позволяют команде быстро повторить и исправить проблему.
🚨 Типичные ошибки
Ошибка 1: Проверяют только happy path
Было:
QA прошел успешный сценарий и остановился.
Стало:
QA добавил negative, boundary и edge проверки.
Объяснение:
Критичные дефекты чаще находятся вне happy path.
Ошибка 2: Нет источника expected
Было:
"Это выглядит неправильно".
Стало:
"Согласно AC-3 поведение должно быть X, но фактически Y".
Объяснение:
Без источника ожидания баг становится спорным.
Ошибка 3: Не проверена воспроизводимость
Было:
Проблема замечена один раз и сразу отправлена.
Стало:
Проверена повторяемость и зафиксирован repro rate.
Объяснение:
Так снижается риск "не воспроизводится".
Ошибка 4: Смешали bug и improvement
Было:
UX-пожелание отправили как blocker bug.
Стало:
Нарушения требований идут в defect, предложения — в improvement backlog.
Объяснение:
Это делает triage чище и быстрее.
Ошибка 5: Пропущен контекст окружения
Было:
В дефекте нет роли, браузера, build и данных.
Стало:
Контекст добавлен до отправки находки.
Объяснение:
Контекст напрямую влияет на воспроизводимость.
✅ Best Practices
- Перед поиском дефектов всегда фиксируй expected behavior.
- Используй вопросы-провокаторы, когда "всё выглядит нормально".
- Проходи мини-чеклист перед созданием бага.
- Всегда разделяй finding bug и reporting bug.
- Отделяй дефекты от улучшений и новых фич.
- Помни, что баг может быть не только в коде.
- Объясняй severity и priority раздельно и аргументированно.
🏁 Заключение
Тема "что такое баг и как его находить" — фундамент для junior QA.
Она учит не просто замечать проблемы, а проверять их системно и подтверждать фактами.
Если ты умеешь брать expected из правильных источников, искать по рисковым зонам и доказывать отклонение, ты уже работаешь как сильный практик, а не как случайный "кликер".