Основные термины в тестировании ПО

Основные термины в тестировании ПО

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

Ошибка, дефект, отказ

Это три разных понятия, которые часто путают.

• Error (ошибка) — действие человека, которое привело к неверному результату. Например, разработчик неправильно понял требование или опечатался в коде.
• Defect / Bug (дефект, баг) — изъян в продукте, появившийся из-за ошибки. Это неправильная строка кода, неверная конфигурация, забытое условие.
• Failure (отказ) — внешнее проявление дефекта при работе системы. Это то, что видит пользователь: упавший запрос, странное число на экране, незагрузившаяся страница.

Цепочка такая: error → defect → failure. Не каждый дефект приводит к отказу (он может «спать» до определённых условий), но каждый отказ — следствие дефекта.

Тест-кейс, тест-сьют, тест-план

• Test Case (тест-кейс) — конкретный сценарий проверки: что подаём на вход, какие шаги выполняем, что должны увидеть на выходе.
• Test Suite (тест-сьют) — набор тест-кейсов, объединённых по смыслу. Например, «Регистрация пользователя» — это набор из 10-20 тест-кейсов.
• Test Plan (тест-план) — документ верхнего уровня, который описывает: что мы тестируем, чем, в какие сроки, какими ресурсами, что в скоупе, что вне скоупа, какие риски.

Иерархия: Test Plan → Test Suite → Test Case → Test Step.

Pre-condition, post-condition

• Pre-condition (предусловие) — что должно быть верно до начала теста. Например: «пользователь зарегистрирован», «в базе данных есть товар X».
• Post-condition (постусловие) — что должно быть верно после теста. Например: «в базе появилась запись о заказе», «пользователь получил email».

Хороший тест-кейс всегда явно описывает оба условия — иначе его невозможно повторно прогнать или поручить другому тестировщику.

Expected vs Actual result

• Expected result (ожидаемый результат) — что должно произойти, согласно требованиям.
• Actual result (фактический результат) — что реально произошло во время выполнения теста.

Расхождение между ними и есть основание для бага. В баг-репорте всегда указываются оба.

Severity и Priority

Двух разных характеристик бага, которые часто путают:

• Severity (серьёзность) — насколько серьёзно баг ломает систему технически. Например: «приложение крашится» — это critical, «опечатка в подсказке» — это minor. Серьёзность ставит обычно тестировщик.
• Priority (приоритет) — насколько срочно баг надо чинить с точки зрения бизнеса. Например, опечатка в логотипе главной страницы — низкая severity, но высокий priority перед релизом для прессы.

Можно встретить любые комбинации: high severity + low priority (краш на странице, которой никто не пользуется) или low severity + high priority (опечатка, которую увидит инвестор).

Smoke test, sanity test, regression

Будут отдельные уроки, но коротко:

• Smoke — «дым»: продукт хотя бы запускается? Базовые сценарии не падают?
• Sanity — «здравомыслие»: после конкретного фикса ведёт себя адекватно?
• Regression — «регресс»: старые фичи не сломались после изменений?

Test environment

Тестовое окружение — это среда, в которой выполняется тестирование: сервер, база данных, сторонние сервисы, версия кода. На проектах обычно есть несколько окружений: dev, test/QA, staging, production.

Coverage (покрытие)

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

• Requirements coverage — какой процент требований покрыт хотя бы одним тест-кейсом.
• Code coverage — какой процент кода исполняется при прогоне тестов (это уже больше про автотесты).

100% покрытия не означает «нет багов» — но низкое покрытие почти гарантированно означает, что баги есть.

Что мы запомним

• Error — действие, defect — изъян в продукте, failure — внешнее проявление.
• Test Plan — Suite — Case — Step: иерархия документации тестирования.
• Severity — про технику, priority — про бизнес. Это разные характеристики.
• Pre/post-conditions делают тест воспроизводимым.
• Покрытие — полезный, но не достаточный показатель качества.