Как выглядит баги

Как выглядят природные баги (фото)

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

Многие интернет-пользователи делятся в соцсетях кадрами с редкими природными явлениями и объектами. Когда смотришь на них, удивляешься, как такое может существовать в реальности. Оцените сами:

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

Баг-репорт

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

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

Виды багов

• Функциональные. Возникают, когда фактический результат работы не соответствует ожиданиям: не получается опубликовать комментарий на сайте, добавить товар в корзину или открыть страницу.
• Визуальные. Это случаи, когда приложение выглядит иначе, чем задумано: кнопка накладывается на текст, не отображаются картинки или текст выходит за пределы окна.
• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).
• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.
• Дефекты безопасности. Случаи, когда из-за ошибки в коде данные пользователей (почты, пароли, фото, информация о платежах) могут быть доступны третьим лицам.

Профессия / 16 месяцев
Тестировщик-автоматизатор

Лучший выбор для быстрого старта в IT

Структура баг-репорта

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

Серьезность и приоритет багов

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

• S0 Trivial (Тривиальный) — баг не влияет на работу программы, поэтому для его исправления могут не выделить отдельную задачу, а исправить попутно при исправлении других, похожих ошибок. Например, при заполнении анкеты в поле «Дата рождения» по умолчанию отображается не актуальный год, а 1999-й.
• S1 Minor (Незначительный) — баг почти не нарушает логику процессов, поэтому с ним программа может нормально работать. Например, неудобная навигация в интерфейсе.
• S2 Major (Серьезный) — баг создает неудобства в использовании, но еще не нарушает функционал программы.
• S3 Critical (Критический) — баг мешает приложению выполнять основные функции: калькулятор расходов неправильно считает бюджет или в текстовом редакторе невозможно вводить текст.
• S4 Blocker (Блокирующий) — ситуация, когда программа не работает в принципе: сайт выдает «ошибку 404» или не запускается приложение.

Станьте тестировщиком – это лучший выбор для быстрого старта в IT

Приоритет — это срочность выполнения задачи. Всего выделяется три уровня приоритетов:

• P1 Высокий — исправляется в первую очередь, так как баг ломает работу приложения.
• P2 Средний — обязательный к исправлению баг после критического.
• P3 Низкий — не требует немедленного решения.

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

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

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.
• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.
• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.
• Закрыт (Closed) — баг устранен и больше не воспроизводится.

Кроме основных есть еще несколько статусов:

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».
• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.
• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

Как правильно писать баг-репорт

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

На что стоит обратить внимание при описании дефекта?

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

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

Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.

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

Тестировщик-автоматизатор

Как ворваться в IT, даже если вы не умеете программировать? Стать тестировщиком. Для старта достаточно базовых знаний ПК. А начать работать можно уже через 4 месяца обучения.

Статьи по теме:

Что такое баг и как с ним бороться

В современном мире nothing is perfect — ничто не безупречно. Мелочь, влияющая на фидбек от пользователя или существенная проблема, замедляющая разработку?

Практичний курс від skvot: Артменеджер.
Управляйте творчим процесом.

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

С технической точки зрения баг — это ошибка, возникающая при разработке программного обеспечения (ПО).

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

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

Професійний курс від skvot: PR basis.
Засвоєте основи PR та комунікації.

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

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

Алгоритм исправления бага выглядит следующим образом:

убедитесь, что тесты в финальной версии проекта проходят без ошибок;

Почему возникают баги?

С учетом статистики возникновение ошибок связано с написанием или изменением кода. И чаще всего это ответственность разработчика.

Експертний курс від skvot: Unreal Еngine: від інтерфейсу до запуску гри.
Запустіть свою гру з Unreal.

К вышеперечисленным причинам добавим следующие:

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

Давайте немного подробнее поговорим о каждой из причин, приведенных выше.

Невнимательность при написании кода

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

Пример: вся команда не могла понять, почему не работает текст, проверяли в поле значение Сontact . При проверке кода теста (с включенным spellchecker) обнаружили, что буква «С» написана кириллицей.

Програмний курс від robotdreams: С++ для GameDev.
Розробка ігор на високому рівні.

В примере ниже в missKey пропущена буква «s»:

В таких случаях на помощь придут:

Непонимание логики кода

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

Если возможности связаться с автором кода нет, можно задействовать тесты. Также брейншторм с менеджером проекта или QA — хорошая альтернатива.

Непонимание особенностей языка программирования

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

К примеру, для входного параметра value = 10 условие будет выполняться. Нужно добавить сравнение === .

Тесты

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

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

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

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

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

Автотестер должен уметь:

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

Отсутствие взаимодействия с ошибками

Чтобы познать дзен и научиться эффективно взаимодействовать с багами, нужно уметь обезопасить свой код от внешнего воздействия:

• проверять входящие параметры;
• обрабатывать исключения;
• применять паттерн Null-object.

Копирование чужих ошибок

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

Классификация багов: какими они бывают?

Существуют две главные классификации багов: по степени критичности и приоритетности.

По степени критичности можно выделить следующие баги:

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

По приоритетности выделяют баги:

• fix in release — можно исправить в новой версии продукта. Как правило, это баги, обнаруженные при тестировании нового функционала системы.
• must fix — срочно исправить. Часто это блокирующие баги, устраняющие выход новой версии в специальном сервисном пакете.
• fix if time — исправить, если позволяет время.
• never fix — никогда не исправлять, например, баги найдены в уже не поддерживаемом продукте.

Как избежать появления багов?

Можно ли избежать появления багов? Это практически невозможно. Любая ошибка — это опыт. Главное своевременно ее заметить и исправить.

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

Заключение

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

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

Как правильно оформить баг-репорт

При тестировании возникает необходимость документирования найденных дефектов. Это позволяет исправить их в кратчайшие сроки. Если кратко, то хороший баг-репорт позволяет:

• воспроизвести проблему;
• понять, в чем проблема, и какова ее важность.

Что такое баг, типы багов

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

Критичность и приоритет бага. Атрибуты баг-репорта

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

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

По критичности баги делят на:

S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

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

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:

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

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

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

Что такое баг репорт, его типичная структура

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

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

Состав баг репорта приведен в таблице:

Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Название тестируемого проекта

Компонент приложения (Component)

Название части или функции тестируемого продукта

Номер версии (Version)

Версия, на которой была найдена ошибка

Наиболее распространена пятиуровневая система критичности:

S1 Блокирующий (Blocker)

S2 Критический (Critical)

S3 Значительный (Major)

S4 Незначительный (Minor)

S5 Тривиальный (Trivial)

P1 Высокий (High)

P2 Средний (Medium)

Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:

Создатель баг репорта

Назначен на (Assigned To)

Имя сотрудника, назначенного на решение проблемы

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

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

Прикрепленный файл (Attachment)

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

Как правильно оформить баг-репорт

1. Для начала нужно убедиться, что найденный баг ещё не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам и\или полям. Если баг уже есть, следует обновить его описание.
2. Если баг не найден – нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
6. Указать полученный результат.
7. Указать версию ПО, также указать версию окружения.
8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т.д.

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

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

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

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

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

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

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

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

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

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

• Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
• Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
• Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
• Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
• Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
• Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
• Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
• Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
• Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен – он все так же потребует исправления, поэтому вновь открывается.
• Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.

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

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

Вместо заключения

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

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

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

Была ли статья полезной?