QA Engineer

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

Коротко, в чем разница?

— Ошибка — это неправильное действие или решение человека (не обязательно разработчика) на этапе разработки, которое потенциально может привести к дефекту.

— Дефект — это обнаруженный недостаток в программном продукте, который указывает на расхождение между фактическим и ожидаемым поведением программы.

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

4.10. Приоритетность и критичность

Приоритет и критичность (серьезность) дефекта — это две ключевые характеристики, которые помогают определить важность дефекта и срочность (порядок) его исправления.

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

Уровни критичности:

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

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

— Средняя: дефект влияет на функциональность, но существуют обходные пути. Например, некорректно работает отображение всплывающих подсказок, но основная функциональность доступна.

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

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

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

Уровни приоритета:

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

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

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

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

5. ДОКУМЕНТАЦИЯ ТЕСТИРОВАНИЯ

5.1. Checklist и Test Case

Test Case (тест-кейс) и Checklist (чек-лист) — это одни из документов, с которыми вы как QA инженер будете чаще всего сталкиваться. В них указано, какие проверки вы будете выполнять в ходе тестирования.

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

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

5.1.1. Checklist

Checklist (чек-лист) — это список задач или пунктов, которые необходимо проверить, но без детального описания того, как это сделать. Его можно использовать на высоком уровне. В этом случае задача чек-листа — не упустить главные пункты проверок.

Пример