class="p1">Приоритет и критичность (серьезность) дефекта — это две ключевые характеристики, которые помогают определить важность дефекта и срочность (порядок) его исправления.
Критичность (серьезность) — указывает на то, насколько сильно дефект влияет на систему. Это способ оценки того, насколько серьезно отклонение текущего поведения системы от нормального (ожидаемого).
Уровни критичности:
— Критическая: дефект приводит к аварийному завершению работы приложения или потере данных. Например, уязвимость безопасности, позволяющая выполнять произвольный вредоносный код.
— Высокая: дефект серьезно влияет на функциональность приложения, но не приводит к сбою всей системы. Например, функция сохранения важного и часто используемого документа не работает.
— Средняя: дефект влияет на функциональность, но существуют обходные пути. Например, некорректно работает отображение всплывающих подсказок, но основная функциональность доступна.
— Низкая: дефект имеет минимальное влияние на пользовательский опыт или представляет собой малозначимый визуальный недостаток. Например, опечатка в тексте пользовательского интерфейса.
Обратите внимание, что критичность довольно легко определить, когда речь именно о сбоях в работе приложения. Однако есть дефекты, к примеру, безопасности и производительности, с которыми сделать это может быть сложней. Это связано с тем, что у каждой компании и проекта свое представление о том, какой уровень производительности приложения считать критичным. Не всем проектам важна очень высокая производительность и ее ухудшение. Также и с безопасностью: не все проекты нуждаются в поддержке самых передовых способов шифрования, многофакторных аутентификациях и подтверждении личности по сканированию лица.
Приоритет определяет скорость и порядок, с которыми команда разработки должна решить проблему. Он учитывает как серьезность ошибки, так и стратегическую важность ее исправления.
Уровни приоритета:
— Высокий: дефект требует немедленного исправления, поскольку блокирует разработку или выпуск продукта. Например, сбой при запуске приложения.
— Средний: исправление дефекта важно, но не критично для непосредственного выпуска продукта. Работу можно временно продолжать с этой ошибкой. Например, одна из второстепенных ветвей алгоритма по расчету цен на товары работает с ошибкой в вычислениях.
— Низкий: дефект нужно исправить после устранения всех высоких и средних приоритетов. Например, косметический дефект интерфейса пользователя, не влияющий на функциональность.
При этом бывают ситуации, когда дефект имеет низкий уровень критичности влияния на систему, но высокий приоритет исправления. К примеру, опечатка в тексте пользовательского соглашения, которая потенциально может принести огромные убытки, абсолютно не влияет на работу функционала, уровень безопасности и производительности приложения.
5. ДОКУМЕНТАЦИЯ ТЕСТИРОВАНИЯ
5.1. Checklist и Test Case
Test Case (тест-кейс) и Checklist (чек-лист) — это одни из документов, с которыми вы как QA инженер будете чаще всего сталкиваться. В них указано, какие проверки вы будете выполнять в ходе тестирования.
Пройденный чек-лист представляет собой гибкий документ с высоким уровнем абстракции, показывающий, какие важные аспекты были протестированы. Пройденный тест-кейс дает более точное понимание проверок конкретного аспекта системы.
Тест-кейсы и чек-листы пишут одни QA инженеры, а качество написанной документации такого вида на практике проверяют другие QA инженеры или аналитики (не часто). Однако аналитики в силу особенностей своей специализации не знают тонкостей действительного качественного тест-дизайна и скорее всего не сталкиваются с контролем большой системы множества тест-кейсов, ее внутренней согласованности, согласованности с матрицами покрытия требований и планами на будущие изменения. Поэтому желательно чтобы проверкой занимались другие QA инженеры.
5.1.1. Checklist
Checklist (чек-лист) — это список задач или пунктов, которые необходимо проверить, но без детального описания того, как это сделать. Его можно использовать на высоком уровне. В этом случае задача чек-листа — не упустить главные пункты проверок.
Пример
Их также можно использовать на низком уровне. В этом случае анализ входных значений и применение техник тест-дизайна можно выполнять прямо во время тестирования.
Пример
Преимущества чек-листа очевидны:
— Простота и широта применения.
— Написание проверок низкого уровня в таком виде позволяет не тратить время на документацию и заниматься непосредственно тестированием системы.
Недостатки чек-листа заключаются в следующем:
— Отсутствие конкретики на низком уровне тестирования требует от QA инженера навыков, соразмерных сложности задачи. И даже в таком случае есть заметный риск пропустить некоторые проверки.
— В случае любых вопросов к тому, как именно проводится тестирование функционала, нет четкого понимания, как и с какими данными его проводили или будут проводить.
5.1.2. Test Case
Test Case (тест-кейс) — это документ, направленный на проверку конкретного функционала или требования к системе с высоким уровнем подробностей.
Применение техник тест-дизайна порождает несколько наборов тестовых данных, которые можно описать одним или группой тест-кейсов. Каждый из них имеет определенные атрибуты:
— Название — оно должно быть коротким, но отражающим цель описанных в тест-кейсе проверок.
— Предварительные условия (могут быть пустыми) — описывают состояние всего приложения или его частей, а также необходимость выполнить предварительные шаги перед началом тестирования.
— Шаги — набор последовательных действий для получения ожидаемого отклика системы.
— Ожидаемый результат — состояние системы, которое должно получиться после выполнения шагов, обычно напрямую связано с конкретным требованием к приложению.
— Фактический результат (заполняется после прохождения тест-кейса) — фактическое состояние системы после выполнения шагов.
Пример
Фактический результат обычно отражается не полноценным описанием состояния системы, а статусами: «Успешно», «Заблокировано», «Неуспешно». Это связано с тем, что более подробное описание в случае неуспешного прохождения отражается в Bug Report.
Тест-кейс является достаточно сложным и одновременно важным документом для того, чтобы иметь критерии, по которым можно определить его качество. Глобально тест-кейсы неразрывно связаны с требованиями к системе и потому имеют схожие критерии качества.
Понимание уровня качества тест-кейсов на проекте на самом деле может сказать о многом. Во-первых, факт того, что на проекте отслеживают уровень качества, говорит о желании стремиться к эффективным проверкам или хотя бы стабильности в этом вопросе. Во-вторых, это означает, что кому-то на проекте важно иметь прозрачные и контролируемые проверки. В-третьих, это говорит о выстроенных вокруг этой потребности процессах и ответственных за это сотрудников компании. Однако понять то, насколько заботятся об уровне качества и какие процессы для этого выстроены, может быть сложно без погружения в контекст проекта.
Критерии качества тест-кейсов:
— Следование цели — документ должен указывать на определенную цель проверок, а все его атрибуты должны вести к выполнению этой цели.
— Точность — формулировки документа точно и не двусмысленно указывают на необходимость выполняемых действий, ожидаемый результат или объекты, использующиеся в документе.
— Единообразие — в тест-кейсе должны быть одинаковые формулировки и единый формат. Также стоит учитывать другие рекомендации, установленные на проекте.
— Непротиворечивость — все атрибуты документа не противоречат сами себе, то есть
