Начинающие тестировщики могут путать эти параметры, но у них есть существенные отличия. Давайте разберемся в этом подробней.
Для начала рассмотрим каждый атрибут в отдельности.
Серьезность
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.
Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).
- S1 – Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее функциями становится невозможна.
- S2 – Критическая (Critical). Критическая ошибка, неправильно работающая бизнес-логика, проблема, приводящая в нерабочее состояние некоторую часть системы, но есть возможность для работы с тестируемой функцией, используя другие входные точки.
- S3 – Значительная (Major). Значительная ошибка, часть бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
- S4 – Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
- S5 – Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.
Давайте рассмотрим несколько примеров проблем и попробуем правильно определить их Серьезность. Чтобы было понятно, представим, что мы тестируем приложение по заказу такси.
1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.
Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.
У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.
Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.
Остаются Критическая и Блокирующая серьезности. В нашем случае Блокирующая подходит больше, так как часть функционала не работает и нет других возможностей найти такси. Следовательно, мы выставляем Блокирующую Серьезность.
2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.
Как вы могли понять, Серьезность относится к технической части приложения и указывает на то, как сильно ошибка влияет на работоспособность приложения.
Приоритет
Приоритет отличается от Серьезности тем, что указывает когда необходимо исправить ошибку.
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.
- P1 – Высокий (High) – требуется исправить в первую очередь.
- P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
- P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.
С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.
На первый взгляд можно подумать, что Приоритет и Серьезность одинаковы, ведь чем серьезней ошибка, тем быстрее её нужно исправить. Но, если глубже рассмотреть эти атрибуты, то можно найти различия.
Например, мы нашли опечатку в слове. Из названия видно, что это ошибка с Незначительной серьезностью и, вроде бы, ее не стоит исправлять в приоритете. Но если это слово находится на главном экране и является частью названия приложения, то, очевидно, что ее необходимо исправить как можно раньше.
Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:
Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:
________________________________
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
________________________________
Предыдущие статьи по оформлению баг-репорта:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/
Фундаментальная теория тестирования
Время на прочтение
15 мин
Количество просмотров 832K
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
- Для проверки соответствия требованиям.
- Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта.
- Обнаружение вариантов использования, которые не были предусмотрены при разработке. А также взгляд на продукт со стороны пользователя.
- Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Принципы тестирования
- Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия. - Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи). - Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше. - Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей. - Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. - Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
- Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.
Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
- проверка готовности ПО к релизу;
- проверка соответствия требований и качества данного проекта.
QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.
К задачам обеспечения качества относятся:
- проверка технических характеристик и требований к ПО;
- оценка рисков;
- планирование задач для улучшения качества продукции;
- подготовка документации, тестового окружения и данных;
- тестирование;
- анализ результатов тестирования, а также составление отчетов и других документов.
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
- Проектная документация — включает в себя всё, что относится к проекту в целом.
- Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.
Этапы тестирования:
- Анализ продукта
- Работа с требованиями
- Разработка стратегии тестирования и планирование процедур контроля качества
- Создание тестовой документации
- Тестирование прототипа
- Основное тестирование
- Стабилизация
- Эксплуатация
Стадии разработки ПО — этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широкого круга пользователей.
Программный продукт проходит следующие стадии:
- анализ требований к проекту;
- проектирование;
- реализация;
- тестирование продукта;
- внедрение и поддержка.
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Атрибуты требований:
- Корректность — точное описание разрабатываемого функционала.
- Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
- Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
- Недвусмысленность — требование должно содержать однозначные формулировки.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
- Атомарность — требование нельзя разбить на отдельные части без потери деталей.
- Модифицируемость — в каждое требование можно внести изменение.
- Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.
Дефект (bug) — отклонение фактического результата от ожидаемого.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
- Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
- Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
- Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
- Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
- Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
- Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
- Вложения (Attachments) — скриншоты, видео или лог-файлы.
- Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
- Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
- Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
- Окружение (Environment) – окружение, на котором воспроизвелся баг.
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
- Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. - Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование. - Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза. - Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве. - Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком
Градация Приоритета дефекта (Priority):
- P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее. - P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения. - P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.
Существует шесть базовых типов задач:
- Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
- Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
- История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
- Задача (task) — техническая задача, которую делает один из членов команды.
- Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
- Баг (bug) — задача, которая описывает ошибку в системе.
Тестовые среды
- Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
- Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
- Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
- Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
- Продакшн среда (Production Env) – среда, в которой работают пользователи.
Основные фазы тестирования
- Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
- Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
- Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
- Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
- Release: финальная версия программы, которая готова к использованию.
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
- Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
- Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
- Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
- Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
- Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
- Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
- Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
- Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
- Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
- Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
- Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
- Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
- Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
- Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
- Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
- Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
- Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
- Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
- Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
- Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
- Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Техники тест-дизайна
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
- Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
- Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
- Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
- Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
- Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
- Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
- Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
- тестирование, основанное на анализе внутренней структуры компонента или системы;
- тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
- Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.
Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
- тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
- тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
- Что необходимо протестировать?
- Как будет проводиться тестирование?
- Когда будет проводиться тестирование?
- Критерии начала тестирования.
- Критерии окончания тестирования.
Основные пункты тест плана:
- Идентификатор тест плана (Test plan identifier);
- Введение (Introduction);
- Объект тестирования (Test items);
- Функции, которые будут протестированы (Features to be tested;)
- Функции, которые не будут протестированы (Features not to be tested);
- Тестовые подходы (Approach);
- Критерии прохождения тестирования (Item pass/fail criteria);
- Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
- Результаты тестирования (Test deliverables);
- Задачи тестирования (Testing tasks);
- Ресурсы системы (Environmental needs);
- Обязанности (Responsibilities);
- Роли и ответственность (Staffing and training needs);
- Расписание (Schedule);
- Оценка рисков (Risks and contingencies);
- Согласования (Approvals).
Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
- Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
- Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
- Ожидаемый результат (Expected result) — что по факту должны получить.
Резюме
Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.
Баг Репорт. Дефект
Баг/дефект репорт — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Основные поля баг/дефект репорта
| Шапка | |
|
Короткое описание (Summary) |
Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. |
| Проект (Project) | Название тестируемого проекта |
| Компонент приложения (Component) | Название части или функции тестируемого продукта |
| Номер версии (Version) | Версия на которой была найдена ошибка |
| Важность (Severity) |
Наиболее распространена пяти уровневая система
(подробнее смотрите ниже в разделе Важность дефекта) |
| Приоритет (Priority) |
Приоритет дефекта:
(подробнее смотрите ниже в разделе Приоритет дефекта) |
| Статус (Status) | Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle) |
| Автор (Author) | Создатель баг репорта |
| Назначен на (Assigned To) | Имя сотрудника, назначенного на решение проблемы |
| Окружение | |
| ОС / Сервис Пак и т.д. / Браузера + версия / … | Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д. |
| … | |
| Описание | |
| Шаги воспроизведения (Steps to Reproduce) | Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. |
| Фактический Результат (Result) | Результат полученный после прохождения шагов к воспроизведению |
| Ожидаемый результат (Expected Result) | Ожидаемый правильный результат |
| Дополнения | |
| Прикрепленный файл (Attachment) | Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы |
Важность дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшее тестирование системы или ее ключевой функции становится недоступно. Решение проблемы необходимо для дальнейшей работы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дырка в системе безопасности, проблема, вызвавшая падение сервера или приводящее в нерабочее состояние некоторую часть системы, без возможности решения проблемы используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Приоритет дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам:
High -> Medium -> Low
Требования к количеству открытых дефектов
Наличие открытых ошибок с S1, S2, P1, P2 считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.
Наличие строго ограниченного количества открытых ошибок S3, S4, S5, P3 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.
Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований — План Тестирования пункт Критерии Окончания Тестирования.
Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Серьезность и Приоритет Дефекта
Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля.
Все знают такой баг-трекер, как 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 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.
Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований — это пункт Критерии окончания тестирования в плане тестирования.
Наверх
После обновления браузера Гугл Хром возникают проблемы при скачивании файлов. Отображается ошибка «Обнаружен вирус» Chrome. Как убрать в 2022 году, если старые способы уже не работают — узнайте из детальной инструкции для Windows 10 8 7. В конце поста будет видео с наглядной демонстрацией решений.
Гугл Хром блокирует скачивание файла — как отключить?
Самое интересное, что в самом обозревателе Вы не найдете никаких настроек, отвечающих за проверку загружаемого контента. Еще в 2018 году дефект устранялся очень просто — достаточно было проигнорировать предупреждение и возобновить загрузку.
Но теперь сделать это невозможно, поскольку в меню доступна только возможность удалить элемент и просмотреть информацию.
Справка Google указывает на ограничения со стороны операционной системы и ссылается на страницу поддержки Microsoft. Там найдете несколько решений. Вот самое эффективное:
- Нажмите на клавиатуре сочетание Win + R и в появившемся окне введите команду:
inetcpl.cpl
- Открываются Интернет-свойства. Следует перейти на вкладку «Безопасность» и сразу убрать опцию, отвечающую за включение защищенного режима. Далее кликаем по кнопке «Другой…» и в списке находим параметр «Запуск программ и небезопасных файлов». Устанавливаем значение «Включить», сохраняем внесенные изменения и перезагружаем компьютер:
В Windows 7 этого вполне достаточно. Но как убрать в Виндовс 10 ошибку «Обнаружен вирус» в Google Chrome, которая возникает при скачивании файлов?
- Необходимо в опциях Защитника (встроенного антивируса) отключить проверку в реальном времени. В области уведомления кликаем по значку «щит», в окне параметров безопасности слева выбираем раздел «Защита от вирусов и угроз». После этого идём по ссылке «Управление настройками»:
- Теперь просто ставим переключатель в положение «Выкл.», чтобы приложение не сканировало файлы при загрузке из сети Интернет:
Этого достаточно, чтобы ошибка «Обнаружен вирус» была устранена в Google Chrome 2022 года.
Файл может быть опасен — как отключить в Яндексе?
Убрать такое уведомление при загрузке в Yandex браузере можно перечисленными выше способами. Но если проблема не устранена, дополнительно следует «навести порядок» в функции Protect.
- Запускаем веб-обозреватель, в адресной строке вводим следующую ссылку:
browser://protect
- Оказываемся в разделе «Безопасность» и сразу обращаем внимание на опцию проверки запускаемых сайтов и загружаемых файлов. Снимаем отметку, закрываем программу и запускаем повторно:
Но не стоит забывать об антивирусах. Не только встроенный Windows 10 Defender может блокировать скачивание в Гугл Хроме и Яндексе, но и сторонние утилиты. При необходимости — следует также поискать в их параметрах соответствующие решения (онлайн-сканер, real-time protection и т.д.).
Видео
07.11.2019 13:28 11540
Евгений Верещака
Вам помогло? Поделитесь с друзьями — помогите и нам!
Многие пользователи Internet Explorer нередко сталкиваются с ситуацией, при которой браузер, подключаясь к тому или иному интернет-ресурсу, демонстрирует вместо запрашиваемой страницы предупреждение, связанное с ошибкой сертификата безопасности. Это предупреждение является следствием предпринятых разработчиками мер против повсеместно распространённого интернет-мошенничества. В подобных случаях браузер сравнивает отправленный веб-сайтом ключ безопасности с эталонным, и при их несоответствии блокирует пользователю доступ к странице.
Однако далеко не всегда ошибка сертификата может быть вызвана действиями мошенников — чаще всего она возникает по вполне «мирным» причинам. Этими причинами могут быть:
- вмешательство антивирусного программного обеспечения или брандмауэра, принимающего доверенный ключ за некорректный;
- ошибочно установленная системная дата и время, причём не обязательно на компьютере пользователя, но и на сервере, где расположен требуемый сайт. Поскольку каждый ключ безопасности действителен строго определённое время, такое временное несоответствие закономерно может вызывать ошибку безопасности;
- * открываемый сайт обладает доверенным, но уже неактуальным сертификатом.
В зависимости от причины возникновения ошибки пользователь может предпринять следующие действия.
Отказ от посещения веб-сайта
Рекомендуется в тех случаях, когда выданное браузером предупреждение полностью или частично оправдано: неизвестный сайт (переход на подобные сайты чаще всего осуществляется через выданные поисковой системой ссылки), веб-страница социальной сети (скорее всего, поддельная) или ресурс, предполагающий финансовое взаимодействие через платежные системы и банковские карты. Иными словами, любой сайт, предполагающий ввод в специальные формы данных учётной записи, реквизитов карты и т.д.
В подобных ситуациях целесообразно проверить адресную строку браузера на предмет шифрования по протоколу https: принадлежащие мошенникам сайты-клоны обычно используют защищённые протокол http, что неприемлемо для официальных веб-страниц.
Игнорирование ошибки сертификата
Допустимо использовать этот способ, если открывается веб-ресурс общеизвестен и является при этом доверенным (к примеру, Youtube, Google и т.д.). Последовательность действий довольно проста:
- во всплывающим уведомлении под адресной строкой нажать «Продолжить открытие этого веб-узла (не рекомендуется)»;
- обозреватель перейдёт на запрашиваемый сайт, но уведомление о сертификате безопасности в верхней части окна никуда не денется;
- проверка установленной системной даты.
Если ошибка возникает из-за некорректно настроенной системной даты, устранить её просто, выставив точную дату и время. Для этого нужно:
- В правом нижнем углу экрана кликнуть правой кнопкой мыши по часам (либо в Панели управления выбрать раздел «Дата и время»).
- В открывшемся окне перейти по ссылке «Изменение настроек даты и времени», затем при наличии несоответствий установить верные значения вручную.
Следует иметь в виду, что несоответствие даты и времени может быть вызвано и весьма банальной причиной: разряженной батарейкой системной платы. В этом случае батарейку необходимо заменить, однако у многих пользователей эта процедура по тем или иным причинам может вызвать затруднения, и в качестве решения можно воспользоваться автоматической синхронизацией.
Однако не стоит исключать и тот факт, что установка времени по серверам Windows не всегда срабатывает корректно, что связано с отменённым в России переходом на летнее время, поэтому более целесообразным способом решения проблемы будет именно замена элементы питания микросхемы BIOS.
Отключение информирования об ошибке
Способ, предполагающий полное доверие со стороны пользователя к посещаемым ресурсам. При наличии уверенности, что на веб-страницах отсутствует всё то, чем любят пользоваться интернет-злоумышленники (фиктивные страницы, редиректы, вирусы, спам-баннеры и т.д.), можно изменить настройки браузерных уведомлений.
Делается это так:
- В правой верхней части окна Internet Explorer нажмите на пиктограмму в виде шестерни, вызвав основное меню обозревателя.
- Перейдите в пункт «Свойства обозревателя».
- В разделе «Дополнительно» отыщите подраздел «Параметры», где надо активировать отметку напротив пункта «Предупреждать о несоответствии адреса сертификата».
- Сохраните внесённые изменения нажатием кнопки «Применить», а следом «ОК».
Если речь идёт об организациях, в которых интернет-соединение управляется и контролируется серверными решениями Майкрософт, то процедура несколько сложнее.
- В «Панели управления» нужно открыть ссылку «Администрирование», а следом выбрать «Средство управления групповой политикой».
- Отметить имеющуюся или создать новую политику.
- В «Редакторе управления групповыми политиками» нужно отыскать раздел «Конфигурация пользователя», затем «Настройка» — «Параметры панели управления» — «Параметры обозревателя». Вызвав ПКМ контекстное меню, выбрать пункт «Создать», а следом браузер нужной версии.
- С правой стороны выбрать свойства элемента, а во вкладке «Дополнительные параметры связи» снять отметку со строки «Предупреждать о несоответствии адреса сертификата».
- Сохранить сделанные изменения и закрыть окно настроек.
- Далее следует воспользоваться консолью (команда «cmd»), чтобы сервер принял внесённые ранее поправки и обновил новые правила политики: в консоли набрать «gpupdate /force».
- Проделать операцию из предыдущего пункта на каждой из требуемых рабочих станций, после чего проверить работоспособность.
Загрузка файла сертификата в IE
В Internet Explorer специалистами Майкрософт была предусмотрена возможность добавления сертификатов вручную. Речь идёт, разумеется, о вполне безопасных ресурсах, возникновение ошибки на которых не связано с угрозами безопасности.
Для добавления ключа такого сертификата в браузер нужно, проигнорировав ошибку безопасности, перейти на соответствующий сайт и отыскать при наличии ссылку на загрузку ключа. (файлы типа *.cer, *pkcs, *.crt и др.). Загрузив сертификат, можно добавить его в браузер. Для этого требуется:
- В правом верхнем углу окна Internet Explorer нужно нажать на значок шестерёнки, вызывая таким способом основное меню обозревателя.
- Перейти в пункт «Свойства обозревателя».
- Во вкладке «Содержание» выбрать «Сертификаты», затем «Импорт».
- Откроется «Мастер импорта сертификатов», где нужно нажать «Далее».
- Кликнуть «Обзор», после чего перейти в папку, куда файлы сертификатов были загружены, и выбрать нужный.
- Определить место хранения ключей: автоматически (по выбору системы) или вручную, выбрав место хранения и название хранилища, после чего нажать кнопку «Далее».
- Когда процесс создания хранилища будет завершён, «Мастер импорта сертификатов»» отобразит финальное диалоговое окно, в котором будут отображены заданные пользователем параметры.
- После нажатия кнопки «Готово» сертификаты будут загружены в браузер, а также проверена их актуальность. Если не возникло никаких проблем, интеграция и настройка сертификатов будет завершена, что Мастер подтвердит сообщением «Импорт успешно выполнен».
В данном примере речь идет об объектных блокировках, которые могут быть установлены автоматически расширениями форм объектов либо программно с помощью метода Заблокировать().
Проверка в контексте объекта, через который и производилась сама блокировка, выполняется следующим образом:
Код 1C v 8.х
// Проверка блокировки данных объекта
Если Объект.Заблокирован() Тогда
// Объект заблокирован через данную переменную
Иначе
// Объект не заблокирован через данную переменную
КонецЕсли;
Следует отметить, что в случае если объект заблокирован через другую переменную (например, открытую форму объекта), то метод Заблокирован() вернет значение Ложь.
Блокировка данных объекта влияет только на возможность его блокировки, но не препятствует изменению данных в базе данных. Поэтому, прежде чем изменять данные объекта, следует убедиться, что эти данных не заблокированы. Для этого необходимо попытаться установить блокировку:
Код 1C v 8.х
// Попытка установки блокировки
Объект = Номенклатура.ПолучитьОбъект();
Попытка
Объект.Заблокировать();
Исключение
// Данные объекта уже заблокированы.
КонецПопытки;
Если попытка заблокировать объект была удачной, это означает, что объект ранее не был заблокирован.
Иногда при подключении в браузере Internet Explorer к защищённому веб-ресурсу отображается предупреждение об ошибке сертификата безопасности. Возникать эта неполадка может по разным причинам:
- некорректно установлены дата и время в системе (более позднее время, чем срок действительности ключа);
- антивирусная программа, фаервол принимает за ошибочный сертификат доверенный;
- в браузере Интернет Эксплорер открыт мошеннический сайт с фейковым ключом безопасности либо безопасный сайт, но с просроченным сертификатом.
Эта статья поможет вам устранить ошибки сертификатов Internet Explorer. В ней рассматриваются различные способы решения данной проблемы.
Игнорирование предупреждения
Если убрать ошибки защищённого протокола не представляется возможным, а сайт, который вы хотите открыть, относится к доверенным (например, YouTube, Yandex, Google), просто проигнорируйте уведомление:
1. На вкладке, которую заблокировал IE, клацните «Продолжить открытие этого веб-сайта… ».
2. Как только вы пройдёте по ссылке, веб-навигатор откроет содержимое страницы, но при этом предупреждение о неполадке всё равно будет отображаться в верхней панели.
Проверка даты и времени
Проверьте, правильно ли выполнена установка календаря и часов в системе:
1. Щёлкните по часам в трее (в правой части панели задач).
2. Если увидите ошибку, кликните «Изменение настроек… » и задайте правильные значения.
Отключение уведомления
Этот метод подходит лишь только в том случае, если вы работаете со знакомыми сайтами, в «чистоте» которых уверены на 100%. То есть знаете точно, что там нет вирусов, переадресаций и прочих хакерских уловок.
Чтобы полностью отключить функцию уведомления об ошибках сертификатов, в меню браузера сделайте следующее:
1. Кликните кнопку «шестерёнка», перейдите в раздел «Свойства браузера».
2. Клацните по вкладке «Дополнительно».
3. В поле «Параметры» кликом мышки уберите «галочку» возле надстройки «Предупреждать о несоответствии адреса сертификата».
4. Нажмите «Применить» и затем кнопку «OK».
Добавление сертификата
Если у вас есть возможность скачать файл-сертификат веб-ресурса или группы веб-ресурсов, которые вы не можете открыть в виду появления ошибки верификации ключа, проигнорируйте уведомления и загрузите его на компьютер (ссылка на скачивание, как правило, размещена в специальных разделах), а затем добавьте в IE. Файл с данными SSL сертификата может иметь расширение .pem, .cer, .crt,.pfx, .der, .pkcs.
Пошагово эта процедура выполняется следующим образом:
1. В меню выберите пункт «Свойства браузера».
2. Кликните вкладку «Содержание».
3. Нажмите кнопку «Сертификаты».
4. Чтобы добавить ключ-файл, в новом окне кликните «Импорт… »
5. В панели «Мастер… » щёлкните «Далее».
6. Щёлкните кнопку «Обзор». Чтобы установить сертификат, в системном окне кликом мышки выделите его (файл) и нажмите «Открыть».
7. Далее задайте настройки размещения ключа:
- клацните кнопку рядом со строкой «Поместить все сертификаты… »;
- в строке «Хранилище… » задайте значение «Доверенные корневые центры… ».
А потом нажмите «Далее».
8. По завершении процедуры отобразятся параметры импорта. Кликните в этом окне «Готово».
9. Если сделали всё правильно и добавленный ключ действительный, появится сообщение «Импорт успешно выполнен».
Каждый из рассмотренных способов целесообразно применять в зависимости от конкретной ситуации — причины возникновения ошибки верификации протокола. Но помните, что незнакомые сайты с подобными неполадками, в особенности те которые предлагают выполнять всевозможные платёжные операции, лучше обходить стороной.
- Серьезность
- Приоритет
- Глобальный приоритет
- Высокий приоритет и низкая серьезность
- Высокая серьезность и низкий приоритет
Для отслеживания багов в программах используются различные инструменты. В крупных компаниях эти инструменты объединяются в общую систему, которой пользуется много сотрудников. И все эти люди должны как-то ориентироваться в срочности работы над багами.
Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.
Каждый баг имеет атрибуты серьезности (Severity) и приоритета (Priority). На первый взгляд может показаться, что разницы между этими понятиями нет, но она все же есть. Серьезность больше касается технической стороны дела, а приоритет — организационной.
Серьезность (Severity) бага
Severity — это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.
Степень серьезности бага больше касается функциональности, поэтому она присваивается тестировщиком. Именно он чаще всего оценивает, насколько конкретная функция может влиять на общую работу тестируемого продукта.
Пример классификации серьезности багов:
- Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
- Critical. Критическая ошибка. Нарушает работу основного функционала. Баг проявляется постоянно и делает невозможным использование основных функций программы.
- Major. Существенный баг. Затрудняет работу основного функционала или делает невозможным использование дополнительных функций.
- Minor. Незначительный баг. На функционал системы влияет относительно мало, затрудняет использование дополнительных функций. Для обхода этого бага могут быть очевидные пути.
- Trivial. Тривиальный баг. Не влияет на функционал проекта, но ухудшает общее впечатление от работы с продуктом.
Приоритет (Priority) бага
Приоритет — атрибут, определяющий скорость устранения бага.
Приоритет бага сперва определяет инициатор, но в дальнейшем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.
Виды приоритетов:
- Top. Наивысший приоритет. Назначается экстренным ситуациям, которые очень отрицательно влияют на продукт или даже бизнес компании. Такие баги нужно устранять немедленно.
- High. Высокий приоритет. Назначается багам, которые должны быть устранены в первую очередь.
- Normal. Обычный приоритет, назначается по умолчанию. Эти баги устраняются во вторую очередь, в штатном порядке.
- Low. Низкий приоритет. Назначается багам, не влияющим на функционал. Исправление таких багов происходит в последнюю очередь, если есть время и ресурсы.
Также нужно упомянуть о частоте проявления бага.
Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.
Частота бывает:
- High. Высокая: с багом сталкиваются больше 80% пользователей.
- Medium. Средняя: баг обнаружат от 30% до 80% пользователей.
- Low. Низкая: баг проявляется у 10-30% пользователей.
- Very low. Незначительная: такой баг встретится меньше чем 10% пользователей.
Глобальный приоритет бага (Global Severity)
Для определения глобального приоритета необходимо определить частоту проявления бага. Частота влияет на приоритет, а приоритет и серьезность влияют на глобальный приоритет бага.
Таким образом, для определения глобального приоритета бага нужно:
- Определить серьезность бага.
- Отдельно от серьезности определить приоритет.
- Определить частоту (независимо от серьезности и приоритета).
- Рассчитать влияние частоты на изначально определенный приоритет.
Если частота у бага высокая, приоритет возрастает на одну позицию. Скажем, если изначально приоритет был Normal, но частота высокая, приоритет определяется как High.
Средняя частота бага меняет приоритет только с низкого на обычный.
Низкая или незначительная частота вообще не меняет приоритет бага.
Для определения глобального приоритета можно пользоваться следующей таблицей:
| Приоритет/Серьезность | Blocker | Critical | Minor | Trivial |
|---|---|---|---|---|
| High | Critical | Critical | Minor | Trivial |
| Medium | Critical | Critical | Minor | Trivial |
| Low | — | — | Trivial | Trivial |
Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.
Высокий приоритет и низкая серьезность
Такое сочетание бывает, когда баг на функционал влияет незначительно, но зато на пользовательский опыт влияет очень сильно. Также в эту категорию попадают баги, не влияющие на программу, но требующие исправления.
Вот пара примеров:
- Кнопки перекрывают друг друга. Они кликабельны, но визуальное впечатление портится.
- Логотип компании на главной странице содержит орфографическую ошибку. На функционал это вообще не влияет, но портит пользовательский опыт. Этот баг нужно исправить с высоким приоритетом, несмотря не то, что на продукт он влияет минимально.
Высокая серьезность и низкий приоритет
Такое сочетание бывает у багов, которые возникают в отдельных функциях программы. Эти баги не позволяют пользоваться системой, при этом обойти их невозможно. Но сами функции, содержащие эти дефекты, конечным потребителем используются редко.
Примеры:
- Домашняя страница сайта ужасно выглядит в старых браузерах. Перекрывается текст, не загружается логотип. Это мешает пользоваться продуктом, поэтому серьезность бага высокая. Но так как очень мало пользователей открывают сайт при помощи устаревшего браузера, такой баг получает низкий приоритет.
- Допустим, у нас есть приложение для банкинга. Оно правильно рассчитывает ежедневный, ежемесячный и ежеквартальный отчет, но при расчете годового возникают проблемы. Этот баг имеет высокую степень серьезности. Но если сейчас формирование годовой отчетности не актуально, такой дефект имеет низкий приоритет: его можно исправить в следующем релизе.
Итоги
Приоритет и серьезность багов — ключевые атрибуты, в соответствии с которыми определяется очередность исправления. Если неверно присвоить багу приоритет и серьезность, эффективность исправления ошибки сильно снизится. Это может нанести вред бизнесу и привести к финансовым потерям. Поэтому очень важно, чтобы и тестировщики, и разработчики понимали суть этих терминов и пользовались ими правильно.