Основы тестирования

Black-box проверяет поведение через интерфейс без знания внутренностей — фокус на требованиях. White-box проверяет с полным доступом к коду и структуре — фокус на путях и ветках. Grey-box сочетает оба: вы тестируете снаружи, но используете частичное знание внутренностей (БД, API) для более умных проверок.

Баг-репорт — это задокументированное описание дефекта, позволяющее другим воспроизвести и исправить его. Основные поля: чёткий заголовок/summary, окружение, предусловия, нумерованные шаги воспроизведения, ожидаемый результат против фактического, severity и priority, а также вложения (скриншоты, скринкасты, логи, стектрейсы). Пара ожидаемое-против-фактического — его сердце.

Severity — насколько сильно дефект влияет на работу системы (blocker, critical, major, minor) — техническая оценка, обычно выставляемая тестировщиком. Priority — насколько срочно его надо исправить — управленческая оценка, выставляемая лидом/менеджером по влиянию на бизнес. Они независимы: опечатка в логотипе может быть low severity, но high priority.

Smoke-тестирование — поверхностная широкая проверка, что критичные пути сборки работают и её есть смысл тестировать дальше; небольшой быстрый набор, запускаемый первым на каждой сборке. Regression-тестирование перепроверяет, что новые изменения не сломали существующую функциональность; оно шире и глубже. Smoke-кейсы отбирают по критичности — те немногие потоки, что обязаны работать; regression — по анализу влияния: области, которых изменение могло коснуться, плюс исторически хрупкие места. Для мелкого хотфикса хватит smoke вокруг правки.

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

Error (ошибка) — человеческое действие, дающее неверный результат, например разработчик неправильно понял требование. Эта ошибка вносит defect (дефект, fault) в код или документ. Когда дефектный код выполняется и ведёт себя неверно, наблюдаемый в эксплуатации результат — failure (сбой). Цепочка: error → defect → failure — причина-человек, статический изъян, эффект в рантайме.

Позитивное тестирование подаёт валидные данные и ожидаемые сценарии, чтобы убедиться, что система делает то, что должна («счастливый путь»). Негативное подаёт невалидные данные, неверные форматы и неожиданные действия, чтобы убедиться, что система корректно их отклоняет — показывает ошибку, когда должна, и не падает. Хорошая практика: сначала позитив, затем негатив.

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

Unit-тесты проверяют отдельный компонент в изоляции. Integration-тесты — взаимодействие между компонентами. System-тестирование валидирует весь интегрированный продукт по требованиям. Acceptance-тестирование подтверждает соответствие бизнес-нуждам и готовность к выпуску.

Функциональное тестирование проверяет, что система делает, по требованиям; нефункциональное — насколько хорошо она это делает (производительность, безопасность, удобство). Smoke — поверхностная проверка приёмки сборки; sanity — узкая проверка одной правки; regression перепроверяет существующие фичи после изменений.

Верификация проверяет, что продукт построен по спецификации — «правильно ли мы строим продукт?». Валидация проверяет, что продукт отвечает реальным потребностям и назначению пользователя — «тот ли продукт мы строим?». Верификация сверяет с требованиями/дизайном, валидация — с фактическими ожиданиями.

Дефект проходит New → Assigned → Open (в работе) → Fixed → Retest, затем Closed, если подтверждён. Если правка не прошла retest, он становится Reopened и снова входит в цикл исправления. Невалидные или дублирующие отчёты получают статус Rejected или Duplicate, а не исправляются.

Критерии приостановки временно останавливают тестирование, когда продолжать бессмысленно — блокирующий дефект, слишком много багов, нет доступов/сборок или изменились требования; тестирование возобновляется, когда блокер устранён. Критерии выхода (завершения) завершают тестирование на этом цикле: запланированные тесты пройдены, покрытие и риск приемлемы, не осталось открытых blocker/critical дефектов (или вышли время/бюджет).

SDLC — это общий жизненный цикл ПО: требования, проектирование, разработка, тестирование, развёртывание, сопровождение. STLC — вложенный в него цикл, специфичный для тестирования: анализ требований, планирование, дизайн тестов, настройка окружения, выполнение и закрытие. STLC идёт параллельно, а не после SDLC.

Семь: тестирование показывает наличие дефектов (но не их отсутствие); исчерпывающее тестирование невозможно; раннее тестирование экономит время и деньги; дефекты скапливаются; парадокс пестицида (повтор одних тестов перестаёт находить новые дефекты); тестирование зависит от контекста; заблуждение об отсутствии ошибок (система без багов бесполезна, если не отвечает нуждам пользователя).

QA — это процессно-ориентированная деятельность: предотвращает дефекты, улучшая весь процесс разработки. QC ориентирован на продукт и выявляет дефекты в готовом продукте. Тестирование — одна из техник QC: запуск продукта для поиска дефектов.

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

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

Shift-left сдвигает тестирование раньше по циклу — ревью требований, unit-тесты вместе с кодом, проверка каждой сборки — чтобы дефекты ловились, пока их дёшево чинить. Компромиссы: больше усилий на старте, потребность в тестируемом дизайне и давление на ещё нестабильные ранние спецификации.

Shift-right расширяет тестирование в продакшн — мониторинг, логирование, алерты, метрики пользователей — чтобы дефекты, всплывающие лишь под реальной нагрузкой, ловились быстро. Он дополняет shift-left, а не заменяет: shift-right ловит просочившиеся дефекты и возвращает их в жизненный цикл дефекта. Компромисс: он реагирует на проблемы, которые пользователи уже могли встретить.

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