В статье обсудим
Если бы все цифровые продукты работали идеально, тестировщики не были бы нужны. Но реальность такова, что ошибки случаются, и задача тестировщика — находить их и следить за их исправлением. Давайте разберемся, что такое дефект в тестировании, почему важно его отслеживать и как он влияет на разработку.
Что такое дефект (баг) и почему его важно устранять
Жизненный цикл дефекта (bug life cycle) — это путь, который проходит баг с момента, когда его заметили, и до полного устранения. Если тестировщик не умеет правильно фиксировать дефекты, они могут затеряться, не дойти до разработчика или остаться нерешенными. Это может привести к проблемам с продуктом, недовольству пользователей и финансовым потерям компании.
Дефект, баг, ошибка — в чем разница?
Часто эти термины используют как синонимы, но между ними есть небольшие различия.
- Ошибка (error) — это действие, которое привело к некорректной работе программы на этапе разработки.
- Дефект (defect, fault) — это отклонение программы от требований, которое обнаружили на этапе тестирования. Если код содержит ошибку и из-за нее программа ведет себя не так, как ожидалось, то это дефект.
- Баг (bug) — это фактически то же самое, что и дефект, но более популярное в IT-среде название.
Другими словами, ошибка разработчика приводит к появлению дефекта, а тестировщик находит этот дефект и заводит его как баг в баг-трекере.
Научитесь тестировать ПО и находить баги в системе. Приходите на курс по основам тестирования и войдите в профессию QA с нуля.
Зачем фиксировать и отслеживать дефекты?
Представьте, что тестировщик нашел баг, но просто сообщил о нем разработчику устно. Что может пойти не так? Да все что угодно.
- Разработчик забудет про баг или недооценит его важность.
- Исправление затянется, потому что никто не отслеживает его статус.
- Баг может повторяться в будущем, так как команда не зафиксировала его причины и решения.
Нормально оформленный баг-репорт в баг-трекере решает эти проблемы: он четко описывает проблему, фиксируется в системе и передается в работу.
Как дефекты влияют на продукт, бизнес и пользователей?
Дефекты в QA — это не просто небольшие ошибки в коде, а реальные проблемы, которые могут наделать беды в ПО и, как следствие, в бизнесе.
- Ухудшают пользовательский опыт. Например, если кнопка «Купить» на сайте не работает, пользователь не сможет оформить заказ.
- Наносят финансовый урон. Представьте баг в интернет-банке, который приводит к неверному списанию средств.
- Накладывают тень на репутацию компании. Ошибки в безопасности или частые сбои могут привести к потере доверия клиентов.
Где и как заводить дефект?
Когда тестировщик находит дефект, он должен зафиксировать его в баг-трекере — специальной системе для управления ошибками.
Популярные баг-трекеры
Есть много инструментов для работы с багами, но самые популярные вот эти.
Jira
Безусловный лидер среди баг-трекеров, особенно в крупных компаниях. Гибкость в настройке рабочих процессов делает ее мощным инструментом, но из-за обилия функций новичкам может быть сложно разобраться. Лицензия платная, что может быть минусом для небольших команд.
Bugzilla
Классика среди бесплатных баг-трекеров. Простая, надежная, но довольно устаревшая по интерфейсу. Если команде нужна базовая функциональность без лишних наворотов — хороший вариант. Однако кастомизация ограничена, и для сложных процессов ее может не хватить.
Redmine
Чуть больше, чем баг-трекер. Это полноценная система управления проектами, где можно вести задачи, баги и даже учет времени. Гибкий, с возможностью установки плагинов, но требует ручной настройки, а интерфейс не самый интуитивный. Хорош для тех, кто готов немного повозиться с настройками, чтобы ювелирно подстроить систему под себя.
Как видите, оформить баг-репорт не так уж сложно. В интерфейсе баг-трекеров уже предусмотрены нужные поля, а тестировщику только остается их корректно заполнить.
Как правильно описать дефект?
Хороший баг-репорт должен содержать следующие пункты.
- Название — кратко описывает суть проблемы. Например: «Не работает кнопка “Отправить” в форме регистрации».
- Окружение — версия браузера, операционная система, устройство и другие технические детали.
- Шаги для воспроизведения — подробное описание действий, которые привели к багу.
- Ожидаемый результат — как система должна работать в идеале.
- Фактический результат — что произошло на самом деле.
- Вложения — скриншоты, видео или логи, которые помогут разработчику понять проблему.
Этапы жизненного цикла дефекта
Как только дефект зафиксирован в баг-трекере, он проходит несколько этапов, пока не будет исправлен и закрыт. Этот процесс называется жизненным циклом дефекта.
Так выглядит жизненный цикл дефекта
Создание: кто и когда заводит баг?
Баг может завести тестировщик, разработчик или аналитик. Но обычно это делает тестировщик во время тестирования нового функционала.
Важно завести баг сразу после его обнаружения, чтобы информация была актуальной, а воспроизведение ошибки — максимально точным.
Назначение: кто отвечает за исправление?
После создания дефект получает статус Open и назначается на разработчика или тимлида. В этот момент возможны разные сценарии.
- Если баг действительно есть, разработчик берет его в работу.
- Если воспроизвести дефект не удается, он может быть переведен в статус Cannot Reproduce.
- Если баг дублирует уже зарегистрированную проблему, он помечается как Duplicate.
- Если ошибка признана несущественной или связанной с неправильным использованием системы, ее могут закрыть с резолюцией Won’t Fix.
Исправление: что делает разработчик?
Разработчик анализирует дефект, ищет его причину и вносит правки в код. После этого он отправляет исправление на проверку тестировщикам.
Если система настроена правильно, каждый коммит (изменение кода) фиксируется в баг-трекере, и тестировщик может видеть, когда исправление было загружено.
Проверка фикса: тестирование после исправления
Когда разработчик исправил баг, он переводит его в статус Resolved или Ready for Testing. Теперь тестировщик смотрит, на самом ли деле ошибка устранена.
Возможны три исхода.
- Баг исправлен. Тестировщик закрывает его, присвоив статус Closed.
- Баг все еще воспроизводится. Тестировщик переоткрывает его (Reopen) и отправляет обратно разработчику.
- Появился новый баг. Исправление могло привести к появлению другой ошибки, тогда заводится новый баг.
Закрытие: когда баг считается устраненным?
Баг можно закрыть, если:
- ошибка больше не воспроизводится,
- тестировщик убедился, что исправление не сломало другие части системы,
- баг признан неактуальным (например, если функционал был удален).
После закрытия дефекта его можно найти в системе для анализа, но он больше не требует внимания команды, и на этом жизненный цикл бага завершен.
Статусы дефекта в баг-трекерах
Каждый дефект в системе управления проходит через разные статусы, отражающие его текущее состояние.
Основные статусы: Open, In Progress, Resolved, Closed
- Open — баг зарегистрирован и ждет обработки.
- In Progress — разработчик работает над исправлением.
- Resolved — баг исправлен и ожидает проверки.
- Closed — баг проверен и закрыт.
Дополнительные статусы: Duplicate, Won’t Fix, Postponed, Cannot Reproduce
- Duplicate — этот баг уже зафиксирован в системе.
- Won’t Fix — исправлять баг не планируется (например, он не критичен).
- Postponed — исправление отложено на будущее.
- Cannot Reproduce — тестировщик или разработчик не смогли воспроизвести баг.
Названия статусов в цикле дефекта не так принципиальны: главное, чтобы все в команде понимали, что они означают. В разных баг-трекерах могут быть свои названия и логика работы статусов. Например, в Jira и Bugzilla можно добавлять кастомные статусы.
Резолюции дефекта и их значение
Помимо статусов, у дефекта в тестировании есть резолюция — это пояснение, почему баг получил тот или иной статус. Она особенно важна, если дефект не исправляется, чтобы команда понимала причину.
Fixed, Fixed Indirectly, Functions As Designed (FAD)
- Fixed — баг исправлен разработчиком.
- Fixed Indirectly — ошибка исчезла не из-за прямого исправления, а, например, после обновления зависимостей или переписывания части кода.
- Functions As Designed (FAD) — система работает так, как задумано, и найденное поведение не является багом.
Duplicate, Incomplete, Won’t Fix, Cannot Reproduce
- Duplicate — этот баг уже есть в системе, дубликаты закрывают.
- Incomplete — недостаточно данных для анализа, тестировщик не предоставил шаги воспроизведения или детали.
- Won’t Fix — команда решила не исправлять баг (например, он не критичен или устарел).
- Cannot Reproduce — тестировщик или разработчик не смогли воспроизвести баг, и без дополнительных данных его исправление невозможно.
Как правильно оформлять баг-репорты?
Хороший баг-репорт (описание дефекта в баг-трекере) помогает разработчику быстрее разобраться в проблеме и исправить ее без лишних вопросов. Здесь можно наглядно увидеть жизненный цикл ошибки и проследить действия команды.
Читайте подробнее о том, как правильно оформить баг-репорт, пошагово и с примерами.
Основные элементы баг-репорта
Каждый баг-репорт должен содержать следующие пункты.
Название — коротко, но понятно. Вместо «Ошибка в кнопке» лучше написать «Кнопка “Отправить” не работает в Chrome».
Окружение — версия браузера, ОС, устройство (если нужно). Например, Windows 10, Chrome 134.0.6998.88/89.
Шаги воспроизведения — четкий список действий, которые приводят к багу.
- Открываем страницу регистрации.
- Вводим данные в форму.
- Нажимаем «Отправить».
- Ничего не происходит.
Ожидаемый результат — как должно работать. Например, «После нажатия кнопки форма должна отправляться».
Фактический результат — что произошло на самом деле: «Кнопка не реагирует, в консоли ошибки».
Приоритет — насколько баг критичен.
- Blocker — система вообще не работает.
- Critical — важный функционал сломан.
- Major — значительная ошибка, но можно обойти.
- Minor — мелкий дефект, не влияющий на работу.
- Trivial — косметическая проблема, например, опечатка.
Вложения — скриншоты, видео, логи ошибок.
Пример хорошо оформленного баг-репорта
Пример баг-трекера в Jira
Часто задаваемые вопросы
Баг или фича? Как определить?
Если поведение системы кажется ошибочным, сначала проверьте требования или дизайн. Возможно, так задумано. Если информации нет, уточните у аналитика или разработчика. Ну а если сомнения остаются, просто заведите баг — пусть команда сама решает, исправлять его или гордиться.
Что делать, если разработчик не хочет исправлять дефект?
Объясните, почему этот баг важен: как он влияет на пользователей, бизнес или другие части системы. Если разработчик все равно отказывается, обсудите проблему с тимлидом или менеджером — возможно, баг недооценили, или вы его переоценили.
Какие ошибки чаще всего допускают новички?
Частая проблема — неполные или неточные шаги воспроизведения. Без четкого описания разработчику сложно понять, в чем ошибка. Также новички забывают прикладывать скриншоты, логи и другую информацию, которая помогает разобраться в баге. Еще одна ошибка — неправильная оценка приоритета: не все баги критичны, но и мелкие дефекты могут серьезно повлиять на пользовательский опыт. Наконец, важно проверять, есть ли такой баг в системе, чтобы не создавать дубликаты.
+77172972667