Баг-репорт
Баг-репорт (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 месяца обучения.
Статьи по теме:
Серьезность и Приоритет Дефекта
Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как Atlassian JIRA. В нем, начиная с какой-то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей: Originally, JIRA did have both a Priority and a Severity field. The Severity field was removed for a number of reasons. Таким образом, те кто привык работать с JIRA не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования. Исходя из личного опыта, я настаиваю на разделении этих понятий, а точнее на использовании обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный:
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Градация Серьезности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам:
High -> Medium -> Low
Требования к количеству открытых багов
Хотим предложить вам следующий подход к определению требований к количеству открытых багов:
- Наличие открытых дефектов P1, P2 и S1, S2, считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.
- Наличие строго ограниченного количества открытых ошибок P3 и S3, S4, S5 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.
Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований — это пункт Критерии окончания тестирования в плане тестирования.
КЛАССИФИКАЦИЯ БАГОВ
Классификация багов по степени влияния на ПО
Баги — очень разные. Их различают по степени влияния
на систему — серьёзности (severity):
1. Блокирующий (Blocker), на жаргоне — «блокер». Ни один элемент системы не работает: никто не может ей пользоваться. На сайте интернет-магазина нельзя сделать покупку. Продукт не выполняет свою задачу.
2. Критический (Critical). Важная часть системы не работает: пользоваться можно, но вероятность сбоя — высокая. В интернет-магазине не работает кнопка «Купить» после авторизации в личном кабинете. Без авторизации всё работает — магазин ещё может принимать заказы.
3. Высокий (Major). Система работает, но не так, как нужно. Пользоваться можно, элементы активны, но выполняют не то, что задумано. В интернет-магазине по кнопке «Купить» выдают скидку 3% на покупку. Приятно, но это не то, что планировали маркетологи. Кнопка работает неправильно.
4. Низкий (Minor). С системой всё в порядке, но работать неудобно. Например, дефект в дизайне. В интернет-магазине в разделе «Товары» не работает вертикальная сортировка. Это не мешает пользователям делать заказ — ошибка не такая серьёзная.
5. Незначительный / Тривиальный (Trivial). Баг, который не влияет на работу программы. Например, ошибка в тексте.
Градация багов по приоритетности исправления
Вторая классификация — по скорости исправления, приоритету (priority). Чем выше приоритет, тем быстрее надо исправить дефект. Им часто пользуются, чтобы правильно передать задачи от тестировщиков — разработчикам.
1. Высокий приоритет (High). Срочно чинить! Без правок ПО работать не может. Пример: на сайте интернет-магазина нельзя сделать покупку.
2. Средний приоритет (Medium). Ошибка некритичная, но без починки ПО не будет работать, как надо. Пример: в разделе «Товары» не работает вертикальная сортировка.
3. Низкий приоритет (Low). Можно исправить, когда разобрались с критическими ошибками. Пример: раздел «Чайники» назван «Чайник».
Какие бывают баги в тестировании
Баг (bug) – это ошибка в коде или в работе программы. Разработчики описывают этим сленговым словом ситуацию, когда что-то работает неправильно, выдает неверный или непредсказуемый результат.
Не любую ошибку можно назвать багом. Этот термин обычно применяют, когда код работает, но некорректно. При этом программа запускается и даже что-то делает, в отличие от, например, синтаксической ошибки, из-за которой код попросту не запустится.
Программу с багами называют забагованной. А отладку кода – дебаггингом, то есть избавлением от багов.
Слово bug в переводе с английского означает «жук». Оно пришло в программирование из сленга инженеров, которые называли багами ошибки при работе электронных схем. А в 1947 году создательница первого компилятора Грейс Хоппер обнаружила в компьютере Mark II бабочку, закоротившую контакты. В журнале происшествий написали: «Первый случай, когда был найден настоящий баг». Так термин закрепился в компьютерной сфере.
Профессия / 16 месяцев
Тестировщик-автоматизатор
Лучший выбор для быстрого старта в IT
Где встречаются баги
В разработке и тестировании. Разработчики регулярно сталкиваются с багами: современные программные продукты – сложные, а в языках программирования много неочевидных вещей. Поэтому столкнуться с багами легко. Чаще всего они становятся следствием неверного употребления команд, неправильно реализованных алгоритмов или ошибок в дизайне программы. Часть багов находят еще при разработке, другие – на этапе тестирования или даже после выпуска продукта.
В готовом программном обеспечении. Даже уже выпущенные программы часто бывают не лишены багов. Некоторые из них очень известные, возникают у многих, даже имеют собственные имена. Есть и уникальные ошибки, которые встречаются однократно. Часто баги зависят от внешних параметров: например, в одной версии операционной системы программа работает корректно, а в другой – нет.
В играх. Отдельной категорией можно назвать баги в видеоиграх: ситуации, когда игровые сцены или персонажи работают не как надо. Примеров множество: двери, которые не могут открыться, внезапные вылеты игры при достижении определенного момента, персонажи, застрявшие в текстурах или зависшие на одном месте. Даже некоторые игры, которые считаются культовыми, на этапе выхода были очень забагованными.
На сайтах. Современные сайты такие гибкие и функциональные благодаря скриптам, написанным на языках программирования. В браузере работает JavaScript, на сервере языки могут быть разными: PHP, Python, Ruby и другие. Баг может возникнуть и на стороне сервера, и в клиентской части сайта – иногда его замечают только после выпуска в продакшн. Есть даже понятие bug bounty: вознаграждение, которое компания выплачивает пользователю, нашедшему критичный баг в информационной безопасности.
Кто сталкивается с багами
В широком смысле встретить баг может любой человек, который пользуется компьютером или смартфоном. Ведь и в готовом ПО ошибки не исключены. В более узком – баги находят разработчики, они же занимаются их исправлением.
Если команда разработки пропустила ошибку, ее ищут на следующем этапе – тестировании. Тестировщики пытаются неочевидными способами воспользоваться программой, чтобы отыскать скрытые ошибки. Найденные баги описываются в специальном отчете – он называется баг-репорт. Отчет тестировщики отправляют разработчикам, чтобы те исправили ошибки.
Станьте тестировщиком – это лучший выбор для быстрого старта в IT
Из-за чего возникают баги
Мы выяснили, что такое баг. Теперь поговорим о причинах, из-за которых они появляются.
- Первая и наиболее распространенная причина – ошибка разработчика. В IT-среде есть шутка: «Кто же победит: человек, венец природы… или крохотная забытая скобочка?». Маленькие недочеты могут быть очень критичными. Если поставить плюс вместо минуса в простейшем математическом вычислении, то получится совершенно другой результат.
- Иногда причиной багов становится незнание. Например, разработчик был не в курсе специфического поведения какой-нибудь конструкции в языке, поэтому воспользовался ею не совсем корректно.
- Часто баги возникают, если в команде программистов нет слаженности. Один не понимает, что написал другой, правит код по своему усмотрению и получает некорректное поведение программы.
- Наконец, дизайн программы и архитектурные ошибки тоже могут быть причиной багов. Использование неоптимальных алгоритмов, ведущих к сбоям, неверный выбор инструментов – все это может привести к забагованности.
Ворнинги, вылеты, исключения: чем отличаются от багов
Ошибки бывают разными, и это не только баги. Вот с чем еще может столкнуться программист.
Предупреждение. Это не совсем ошибка. Это скорее сообщение о риске некорректной работы. Не все предупреждения действительно указывают на что-то опасное. Например, линтеры – программы для написания чистого кода – выдают предупреждения, если человек пишет в «неправильном» стиле. На сленге предупреждения называют ворнингами от английского warning.
Исключение. Exception, или исключение, – это встроенный механизм защиты от ошибок в языках программирования. Программа выдает сообщение, что что-то пошло не так. Условия для исключений пишут сами программисты. Например, ставят защиту на ввод: если пользователь введет строку вместо числа, выбросится исключение.
Преимущество этого механизма в том, что он помогает обрабатывать проблемные ситуации еще до их появления и не допускать появления багов. Разработчик пишет, как должна вести себя программа, если столкнется с исключением. К примеру, в случае со строкой вместо числа можно прописать, чтобы программа сообщила пользователю об ошибке и попросила ввести данные в корректной форме.
Вылет. Так называют ситуацию, когда программа экстренно завершает работу из-за ошибки. Вылет может сопровождаться сообщением о сбое. Причины разные: начиная от ошибок в коде и заканчивая недостаточной мощностью компьютера, который не справляется с «тяжелой» программой.
Синтаксическая ошибка. Самый простой вариант: разработчик допустил опечатку в синтаксисе и неправильно написал какую-то конструкцию, поэтому программа не собралась. Запись оказалась неизвестна компилятору или интерпретатору. В таком случае среда программирования говорит разработчику о синтаксической ошибке и указывает, где ее искать.
Какими бывают баги
Разработчики классифицируют баги по нескольким категориям. Некоторые – скорее шуточные, другие обсуждаются всерьез. А у некоторых распространенных багов даже есть свои названия.
- Опечатка – простейший вариант. Разработчик случайно пишет не то, и вся программа работает неправильно.
- Бесконечный цикл – ситуация, когда условие для выхода из цикла никогда не наступает, и программа виснет.
- Переполнение буфера – явление, когда программе перестает хватать памяти, и она начинает пользоваться памятью за пределами выделенного ей количества.
- Состояние гонки – баг многопоточных приложений, когда несколько потоков одновременно обращаются к одному и тому же элементу и как бы «соревнуются» за доступ. Результат непредсказуем.
- Количественный баг – ошибка при работе с большим количеством действий, когда при многократных повторениях появляются баги. Например, большое количество данных распределяется неравномерно.
- Демонстрационный эффект – явление, когда программа работала нормально на этапе написания, но сломалась при демонстрации. Зачастую возникает из-за недостаточного тестирования и невнимательности: разработчик не учел какой-то сценарий.
Баги – это очень плохо?
Баги бывают забавными, не приносящими серьезного вреда. Некоторые из них, особенно игровые, порождают мемы и шутки. Но бывают и очень опасные баги, чреватые потерей денег или даже риском для жизни.
Например, баг в медицинском оборудовании может привести к трагедии. Баг в коде сайта – к утечке огромного бюджета: так было, когда блокчейн-компания Compound случайно отправила своим пользователям почти 90 миллионов долларов. А самый дорогой баг в истории – арифметическое переполнение в программной начинке ракеты-носителя «Арион-5», из-за которого ракета взорвалась в полете.
Конечно, критичность багов зависит от сферы. Если отрасль разработки связана с большими финансами или жизненно важным оборудованием, проверка качества кода в этой отрасли очень жесткая. Ведь цена ошибки очень велика.
Как избежать багов
Мы уже выяснили, что критичные баги несут опасность. Поэтому разработчики стараются не допускать их в готовом продукте:
- отлаживают программу еще на этапе создания. Хороший разработчик еще при написании кода учитывает возможные нештатные ситуации в его работе, проверяет его и пишет исключения;
- тестируют для любых ситуаций, в том числе нетривиальных. В свою очередь тестировщики находят неочевидные ситуации, в которых программа может сломаться, и сообщают о них;
- проводятюнит-тестированиедля каждого компонента. Это отдельное тестирование разных частей кода – юнитов. Оно помогает понять, корректно ли работают эти компоненты – это более глубокий уровень. Ведь ошибка в одном компоненте может вызвать баги во всей программе.
Для начинающего разработчика главное – внимательность, потому что частая причина багов – опечатки. А они вероятнее, если человек еще не привык писать код. Скрупулезность и внимание к деталям помогут если не избежать багов, то серьезно сократить их количество и быстро исправить те, что остались.
Тестировщик-автоматизатор
Как ворваться в IT, даже если вы не умеете программировать? Стать тестировщиком. Для старта достаточно базовых знаний ПК. А начать работать можно уже через 4 месяца обучения.
Статьи по теме: