Функциональные баги
Что такое функциональные баги, как оценить их серьезность, и как отличить их от предложений для удобства использования?
Функциональные баги связаны с функциональной частью программного обеспечения. Примеры: Кнопка не отправляет форму, поиск не реагирует на ввод пользователя, происходит аварийное завершение работы приложения. Каждый раз, когда вы выполняете какое-либо действие веб-сайт/приложение не реагирует, как вы ожидали, это может быть функциональной проблемой. Ограниченная информация о продуктах наших клиентов и незнание особенностей их реализации затрудняют определение того, является ли наблюдаемое поведение преднамеренным или же на самом деле багом. Обоснованные догадки, основанные на опыте и анализе поведения продукта путем тестирования различных сценариев, могут помочь вам прийти к ответу.
Как определить, является ли поведение приложения функциональным багом:
- Постарайтесь выяснить, разработана ли функция определенным образом или же она действительно нарушена. Проверьте его самостоятельно и в сочетании с другими функциями, чтобы выявить потенциальные различия.
- Подумайте о том, какими могли быть намерения клиента, и подумайте, что продукт может просто работать так, как он был реализован.
- Найдите доказательства того, что что что-то работает не так, как должно. Подкрепите свои претензии.
- Пример: Функциональность интернет-магазина работает иначе, чем в других известных вам интернет-магазинах. Это не означает, что функциональность сломана. Клиент может реализовать свой продукт так, как ему заблагорассудится.
- Пример: Вы утверждаете, что поле формы не подтверждено и это баг. Имеются ли какие-либо признаки того, что они намеревались валидировать поле? Докажите, что в одних случаях поле подтверждено, а в других - нет. Если вы не предоставите доказательств, это будет недоказанное утверждение.
- Проблемы визуального или контентного характера становятся функциональной проблемой, когда они препятствуют функциональности, и поэтому о них следует сообщать как о функциональном баге.
- Функциональность последовательно работает одинаково в разных сценариях и без очевидных проблем? Тогда, вероятно, это не баг, и вы просто предлагаете внести изменения (предложение для удобного использования).
Оценка тяжести
Оценивая функциональную серьезность бага, необходимо учитывать несколько факторов: функциональное воздействие, обходной механизм, масштаб проблемы, потенциальная и заметная потеря продаж, сравнение с другими багами той же серьезности.
Простой подход заключается в том, чтобы посмотреть на функциональное воздействие бага. Подумайте о том, насколько тяжело то, что функция недоступна. Подчиненные функциональные возможности не будут препятствовать пользователям в достижении их цели, за исключением нарушенной основной функциональности. Спросите себя, насколько важна эта часть функциональности в контексте всего продукта.
Подумайте, сможете ли вы достичь своей цели с помощью альтернативного маршрута или опции, или же часть функциональности останется недоступной. Когда вы интуитивно и легко находите способ обойти баг, это так называемое обходное решение позволяет вам все еще достичь своей цели. Баг обходного пути получает более низкий уровень серьезности, чем эквивалентная баг без обходного пути. Наконец, когда нет обходного пути для испорченной основной функциональности, это шоустоппер.
Вопрос о том, сколько людей, продуктов или изделий затронуты функциональной проблемой, является определяющим фактором, определяющим масштаб проблемы. Например, не реагирует ли кнопка "Добавить в корзину" на все страницы информации о товаре в интернет-магазине или только на одну из них? Небольшая группа пользователей обеспокоена этой проблемой или все?
Оценка потенциальной потери продаж является вторичным подходом, поскольку часто можно только предположить, как люди могут отреагировать на баг. Тем не менее, учтите, насколько велик потенциальный убыток. Мир разнится, если цена на продукт будет отличаться на сотни центов или сотни долларов.
В конце концов, вы также можете сравнить ваш баг с тем, который уже одобрен тем же руководителем команды в этом тесте, чтобы выяснить, является ли ваш уровень тяжести подходящим.
У нас есть три уровня серьезности функциональных багов:
НИЗКИЙ:
• Минимальное влияние на использование продукта.
• Изделие ведет себя ненамеренно, однако это не влияет на его общее использование.
• Лишь немногие пользователи, продукты или предметы обеспокоены.
• Функция/часть функциональности сломана или недоступна, но простое обходное решение решает эту проблему.
ВЫСОКИЙ:
• Серьезное влияние на использование продукта, но основная функциональность остается нетронутой.
• Это касается большого числа пользователей, продуктов или предметов.
• Нетривиальная функциональность сломана или недоступна и не существует обходного пути.
• Важная функциональность сломана или недоступна, но есть обходной путь (следовательно, не демонстрационный).
КРИТИЧЕСКИЙ:
• Баг препятствует основной функциональности приложения или веб-сайта.
• Не позволяет пользователю продолжить основной процесс, например, процесс оформления заказа.
• Баг приводит к потенциальной и заметной потере продаж для компании, управляющей приложением или веб-сайтом.
Общие оценки
У нас есть список конкретных случаев с фиксированным уровнем тяжести. Вышеуказанная схема оценки не применяется к случаям, включенным в этот перечень. Поскольку список будет со временем обновляться, пожалуйста, регулярно проверяйте его.
Снижение степени тяжести для конкретных условий эксплуатации
В связи с тем, что некоторые версии браузеров и операционных систем устарели, а их доля на рынке сократилась, баги, возникающие только в малоактуальных средах, оцениваются с меньшей степенью серьезности. Такие условия как:
• IE 10 и ниже
• iOS 10 и ниже
• Android 5.0 и ниже
Степень тяжести снижается следующим образом:
• Критическое превращается в высокое (исключение: строгость остается критическим в экспресс-тестах).
• Высокий превращается в низкий
• Низкий остается Низким
Случайные баги
Случайные баги возникают, когда часть функциональности используется необычным образом. Функциональность не нарушается при использовании с типичными данными и типичными действиями пользователя. Вот несколько примеров:
• Мгновенные действия, такие как сведение приложения к минимуму после нажатия кнопки
• Повторное выполнение одних и тех же действий, например, открытие и закрытие меню.
• Любой баг, который возникает только после необычного набора действий.
Каждый случай должен оцениваться отдельно. Крайние случаи багов, которые актуальны для наших клиентов, пересылаются как "Low bugs". Нерелевантные случаи, на которые приходится большинство багов в крайних случаях, будут отклонены.
Принудительные баги
Принуждение к багу нетипичным поведением или специальными условиями, как правило, выходит за рамки нормы, так как такие баги не имеют отношения к нашим клиентам. Нетипичное поведение не отражает нормальное поведение пользователя. Примеры нетипичного поведения или особых условий:
• Нажатие на несколько элементов одновременно
• Случайное нажатие кнопки
• Быстрое нажатие на кнопку несколько раз
• Уменьшение размера окна до нестандартных размеров
• Полный объем оперативной памяти или внутренней памяти приводит к неожиданному поведению.
• Использование неофициальных, бета- или модифицированных версий операционной системы