Какие бывают баги в тестировании

Какие бывают баги в веб приложении? Про коды ошибок для начинающих тестировщиков. 2023

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

Далее ты узнаешь про:

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

Типы багов (Итог)

Баг — это проблема, связанная с программным обеспечением. Если что-то на веб-сайте или в приложении работает не так, как предполагалось, эта «ошибка» называется багом. Здесь на test IO мы различаем следующие типы багов:

Функциональные ошибки
Ошибки контента
Визуальные ошибки
Предложения по удобству использования

Функциональные баги Функциональные баги связаны с функциональностью части программного обеспечения, например, кнопка не отправляет форму, поиск не реагирует на ввод данных пользователем, происходит сбой приложения и т.д. Каждый раз, когда вы выполняете какое-либо действие, а веб-сайт/app реагирует не так, как вы ожидаете, это может быть функциональной проблемой.

Как определить, является ли поведение приложения функциональным багом:

• Попробуйте выяснить, спроектирована ли функция определенным образом или на самом деле она сломана. Протестируйте ее самостоятельно и в комбинации с другими функциями, чтобы выявить потенциальные различия.
• Подумайте о том, каковы могли быть намерения клиента, и подумайте о том, что продукт может просто работать так, как он был реализован.
  Найдите доказательства того, что что-то работает не так, как должно, и подтвердите свое утверждение.
• Пример: Функциональность веб-магазина работает иначе, чем в других известных Вам веб-магазинах. Это не означает, что функциональность нарушена. Клиенты могут реализовывать свои продукты как им заблагорассудится.
• Пример: Если вы утверждаете, что поле формы не валидируется и что это ошибка, пожалуйста, убедитесь, что есть какие-либо признаки того, что это поле предназначено для валидации. Вы можете предоставить это доказательство, показав, что в некоторых случаях поле является валидированным, но не в других. Если вы не предоставите никаких доказательств, это будет недоказанное утверждение.
• Проблема с визуализацией или контентом становится функциональной проблемой, когда она мешает функциональности, и поэтому о ней следует сообщать как о функциональной ошибке.
• Если часть функциональности последовательно работает одинаково в разных сценариях и без очевидных проблем, то, скорее всего, она такой задумана (не баг).

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

Низкий:

• Минимальное влияние на использование продукта.
• Продукт показывает непреднамеренное поведение, но на общее использование не влияет.
• Немногие пользователи, продукты или предметы затрагиваются.
• Функция/объект функциональности нарушена или недоступна, но легкая обходная мера решает проблему.

Высокий:

• Серьезное влияние на использование продукта, но основная функциональность не повреждена.
• Обращает на себя внимание большое количество пользователей, продуктов или предметов.
• Нетривиальная функциональность нарушена или недоступна, но легкий обходной путь не существует.
• Важная функциональность нарушена или недоступна, но есть обходной путь (следовательно, нет шоу-стоппера).
  Критический:

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

Баги контента Баги контента относятся к фактическому содержанию веб-сайтов или приложений: текст, ярлыки, картинки, видео, иконки, ссылки, данные и т.д. Следовательно, типичные баги контента:

• Неисправные ссылки или изображения (404s) (если только они не расположены в навигационном меню, заголовке, нижнем колонтитуле или в навигации , тогда они являются функциональными ошибками низкого качества).
• Дефектные переадресации в целом
• Пропущенный текст, например, в пустой подсказке.
• Пропущенное содержимое, например, пустая область содержимого
• Пропущенное содержимое, например, если 4 из 5 иконок имеют всплывающую подсказку, 1 не имеет
• Пропущенные переводы, например, какая-нибудь кнопка на английском веб-сайте с французскими ярлыками.
• Некоторые продукты отсутствуют в результатах поиска, но функция поиска работает сама по себе.
• Пропущенные данные
• Пожалуйста, обратите внимание, что орфографические ошибки не считаются ошибками контента на нашей платформе и не могут быть отправлены как таковые.

Визуальные баги Визуальные баги относятся к графическим интерфейсам веб-сайтов или приложений, например:

• Проблемы макетного фреймворка, такие как неправильно выровненные тексты/элементы.
• Проблема Responsive Design, например, элемент отображается на одном мобильном устройстве, а на другом нет.
• Тексты/элементы непреднамеренно перекрывают друг друга.
• Текст/элементы обрезаны

Изменение контеного или визуального бага на функциональный баг

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

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

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

Только одно сообщение должно быть отправлено по следующим вопросам контента: Некоторые изображения продуктов на нескольких страницах интернет-магазина повреждены, некоторые ссылки для скачивания PDF-руководств на нескольких страницах ведут на 404 страницы, некоторые описания продуктов написаны на другом языке, некоторые подсказки не содержат никакой информации, некоторые ссылки, принадлежащие к одной группе, повреждены и т.д.

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

Альтернативная классификация багов

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

Перелистывая материалы по классификациям багов, кажется, что оптимальный список находится вот в такой классификации (ниже мой любительский перевод) по типам:

• Комментарий — неадекватный/неправильный комментарий в коде;
• Ошибка компиляции — неправильная интерпретация формулировки или валидации в коде;
• Ошибка данных — неправильная организация/обновление данных;
• Ошибка базы данных — ошибка в схеме/дизайне базы;
• Отсутствующий дизайн — дизайнерские незадокументированные решения, которые из-за этого не соответствуют требованиям;
• Несоответствующий дизайн — отсутствующие уточнения, неточное или неполное описание дизайна;
• Неправильный дизайн — неправильный, неаккуратный дизайн;
• Непонятный дизайн — дизайнерские решения, непонятные пользователю/рецензенту. Использование двусмысленных слов;
• Упущенные условия границ — граничные условия неправильны/не заданы;
• Ошибки интерфейса — внутренняя/внешняя ошибка, которая отображается в интерфейсе, неправильные параметры, выравнивание, положение объектов или окна;
• Логические ошибки — отсутствующая, недостаточная, неуместная, неоднозначная функциональность исходного кода;
• Ошибка сообщения — отсутствие или неправильное сообщение об ошибке в исходном коде;
• Ошибка навигации — неправильно прописанная в коде навигация;
• Ошибка производительности — относится к производительности/оптимальности кода;
• Отсутствующие требования — явные/неявные требования пропущены или не задокументированы;
• Неадекватные требования — требования, которые нуждаются в доработке;
• Неправильные требования — описание требований не верное или не полное;
• Двусмысленные требования — непонятные рецензенту требования (включает двусмысленные слова — как, по типу, возможно, может быть и т.д.;
• Ошибка последовательности или времени — ошибка, которая возникает при неправильной последовательности в коде или неправильным/упущенным тайм-аутам;
• Стандарты — несоблюдение стандартов, требований;
• Системные ошибки — ошибки ОС, оборудования, недостаток памяти;
• Ошибки тест-планов, тест-кейсов — неправильные, двусмысленные, недостаточные, дублирующиеся, незаконченные тестовые случаи и скрипты;
• Типографические ошибки — грамматические, синтаксические и другие ошибки в документации и коде;
• Ошибки объявления переменных — неправильное объявление или использование переменных, несоответствие кода.

В общем, предлагаю рассмотреть баги в собственной альтернативной классификации по группам:

1. Логические — ошибки, нарушающие логику использования функционала. Это могут быть и ошибки кода, и ошибки логики использования приложения, и нарушения логического отображения данных, и описания функционала;
2. Технические — все ошибки кода, архитектуры и т.д.;
3. Комбинированные — ошибки, включающие в себя несколько групп;
4. Локализированные — ошибки, которые зависят от среды (например, от браузера или ОС);
5. Дизайнерские — все, что касается UI, usability;
6. Соотношения — нарушение связей между элементами, back-end и front-end (это могут быть ошибки маппинга на сайтах, неверно настроенные ключи в базах данных, несоответствие объектов;
7. Документации — ошибки любых документов.

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

Благодарю за внимание!

• тестирование
• баги
• классификация багов

• Тестирование IT-систем
• Тестирование веб-сервисов
• Тестирование мобильных приложений

Какие бывают баги в тестировании

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

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

Что мы рассмотрим:

1. Баг репорт – что это. Определение понятия
2. Оформление баг репорта и самые распространенные виды багов
3. Атрибуты баг репорта
4. Шаблон баг репорта
5. Баг репорт и тест кейс: их важность в работе тестировщика
6. Баг репорт – пример высокой квалификации специалиста

Баг репорт – что это. Определение понятия

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

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

Оформление баг репорта и самые распространенные виды багов

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

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

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

Атрибуты баг репорта

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

1.Серьезность бага – показывает уровень опасности ошибки для системы. Серьезность багов также имеет свою классификацию, где показатель S0 (Trivial) означает лишь небольшую ошибку, которая устраняется быстро, а S4 (Blocker) подразумевает под собой серьезный баг, который полностью блокирует систему софта, не давая ему работать.

Также выделяют уровни S1 (Minor), S2 (Major), S3 (Critical). Каждый из них так или иначе накладывает отпечаток на уровне и качестве функционирования продукта.

2. Приоритетность решения (устранения) бага. Данный показатель разделяется на три уровня приоритетности: High, Medium, Low.

Шаблон баг репорта

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

• Название: Краткое и понятное описание проблемы;
• Описание: Подробное описание обнаруженной ошибки;
• Ожидаемое поведение: Что ожидается увидеть в результате;
• Фактическое поведение: Что фактически наблюдается в программе;
• Шаги воспроизведения: Здесь важно прописать шаги для обнаружения бага разработчиком;
• Приоритет и серьезность: Уровень важности проблемы.
• Окружение: Операционная система, браузер (или другие среды), на которых обнаружена ошибка.

Давайте теперь рассмотрим краткий пример баг репорта.

Пример баг репорта от тестировщика

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

Пример заполнения баг репорта

1. Название: Некорректное отображение имени пользователя в профиле.

• Зайти в аккаунт пользователя;
• Перейти на страницу профиля;
• Обратить внимание на поле “Имя пользователя”;
• Отметить, что вместо имени отображаются случайные символы (см. скриншот во вложении).

3.Ожидаемое поведение: Поле “Имя пользователя” должно содержать имя пользователя, введенное при регистрации.

4. Фактическое поведение: Поле “Имя пользователя” отображает непонятные символы (см. скриншот).

5. Шаги воспроизведения: 100%.

6. Приоритет: Высокий.

7. Серьезность: Средняя.

• ОС: Windows 10
• Браузер: Google Chrome версии 91.0.4472.124 (64-бит)
• Аккаунт: тестовый пользователь

Баг репорт и тест кейс: их важность в работе тестировщика

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

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

Баг репорт – пример высокой квалификации специалиста

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

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

Часто задаваемые вопросы

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

Все зависит от уровня квалификации самого специалиста. В среднем на оформление баг репорта уходит не более 30 минут.

Конечно. Мы уделяем отдельное внимание оформлению всей технической документации и отчетности тестировщиками.