Что такое "Настоящий баг"?

Что такое настоящий баг?

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

Как убедиться, что баг важен для заказчика

Давайте посмотрим на факторы, которые определяют, является ли важным для заказчика или нет.

Работает как задумано

Вы можете подумать, что нашли баг, но на самом деле это не баг, а просто то, как работает система, это некорректные ошибки. В uTest мы классифицируем такие ошибки как Working as Designed или WAD. Понимание продукта в первую очередь поможет вам избежать таких ошибок. Но не стоит слишком беспокоиться о WAD, так как отклонения по этой причине не влияют на ваши рейтинги. Ошибки WAD иногда могут быть сложными, даже для опытных тестеров. Просто используйте следущие суждения. Давайте сделаем это , посмотрев на некоторые примеры:

Пример 1: Вы тестируете сайт и не видите кнопки выхода , но в соответствии с инструкциями, кнопка выхода должна присутствовать на главной странице, поэтому вы сообщили об этом. Но кнопка выхода скрыта внутри выпадающего меню, которое вы не проверили. Так что это оказалось ошибкой WAD. Это будет хорошей обратной связью, чтобы сделать кнопку выхода легко доступной, но это не ошибка, так как разработчики намеренно поместили кнопку выхода внутри выпадающего меню.
Пример 2: Вы тестируете торговый сайт, сортируете товары по цене от низкой до высокой. Есть две цены на продукт, фактическая цена и цена со скидкой. Сайт сортирует пункты, используя фактическую цену, а не по цене со скидкой, так что на первый взгляд, вы можете подумать, что сортировка работает неправильно и можно сообщить об ошибке. Но сообщение об ошибке является неверным, так как сортировка работает в соответствии с дизайном. Сортировка по цене со скидкой является хорошим решением, но это не ошибка.

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

Пример: В области 'Out Of Scope' явно указано, что 'Страница справки' не входит в область тестирования. Таким образом, если вы сообщите об ошибке на странице справки, она будет отклонена.

Не сообщать о критериях В зависимости от тестового цика, у него могут быть требования к тому, какие типы багов могут быть зарепорчены. Информация по этому вопросу будет также приведена в разделе "Out Of Scope".

Пример: В разделе "Out Of Scope" указано, что визуальные ошибки и ошибки локализации не входят в область видимости. Поэтому, если вы сообщите о каких-либо визуальных ошибках и ошибках локализации, они будут отклонены.

Дубликаты

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

Известные ошибки

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

Следование инструкциям

Вы всегда должны следовать инструкциям при тестировании. Если вы не следуете инструкциям и сообщили о нужном для заказчика баге, он может быть отклонен по DNFI (Did not follow instructions).

Пример: Отказ от использования uTest прокси при необходимости его использовании и т.д.

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