Перейти к основному содержимому

Классификация видов тестирования

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Тестировщику Разработчику Аналитику
Теория данных (раздел 3)

Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.

Зачем эта статья. Слов "тестирование" десятки — unit, regression, smoke, black-box… Здесь карта местности: по каким осям делят проверки и какие уровни (unit → E2E) существуют. После прочтения проще понимать коллег, последовательность этапов и карту уровней и практик (чтобы не путать уровни тестов с TDD/BDD).

Play ITЗагрузка интерактивного демо…

Классификация видов тестирования​

Классификация тестирования​

Тестирование классифицируют по доступу к коду (black/white/gray-box), по целям (функциональное / нефункциональное), по уровню (unit, integration, system, UAT) и по способу (ручное / автоматизированное). Ниже — самые нужные оси для старта.

Сводная карта осей классификации​

Одну проверку можно описать сразу по нескольким осям. Таблица ниже — краткая "шпаргалка" по типовым осям (в духе ISTQB и практики QA); детали — в разделах ниже.

ОсьВариантыКуда углубиться
Запуск кодастатическое (без run), динамическоеОсновы, white-box
Доступ к реализацииblack-, white-, gray-boxниже в этой статье
Автоматизацияручное, автоматизированноеАвтоматизация
Уровень архитектурыunit, integration, system, приёмкаКарта уровней, Последовательность этапов тестирования
Целифункциональное, нефункциональноеОсновы, Нагрузочное и стресс-тестирование производительности (нагрузка), Тестирование информационной безопасности (безопасность)
Степень формализацииad-hoc, чек-лист, тест-кейс, скриптДокументация
Момент в хронологииsmoke, sanity, регрессия, confirmationтаблица ниже в этой статье
Аудитория / стадияальфа, бета, UAT, контрактноеразделы приёмочного тестирования ниже
Природа приложениявеб, мобильное, API, desktopРучное тестирование веб-приложений, Особенности тестирования мобильных приложений, Тестирование и анализ API
NFR: i18n, l10n, a11yинтернационализация, локализация, доступность UIниже — usability и a11y
Участие пользователейтолько команда, внешние бета-тестерыальфа/бета ниже
Техники дизайнаEQ-классы, границы, pairwise, состоянияТест-дизайн
Упрощённая классификация для старта

Пять осей, которые стоит запомнить в первую очередь — статика/динамика, black/white/gray, ручное/авто, уровень (unit→system), функциональное/нефункциональное. Остальные уточняют контекст, когда вы уже выбираете конкретный набор проверок на спринт.

White-box, Black-box и Gray-box тестирование​

Black-box тестирование ("тестирование чёрного ящика") рассматривает систему как неделимую сущность, поведение которой определяется только входными данными и ожидаемыми выходными результатами. Внутренняя структура, алгоритмы и реализация остаются скрытыми от тестировщика. Такой подход характерен для системного и приёмочного тестирования, а также для большинства видов функционального тестирования. Основное преимущество — независимость от внутренней реализации при проверке по контракту: если поведение снаружи не изменилось, ручные сценарии и API-тесты по спецификации часто остаются актуальными. UI-автотесты, завязанные на вёрстку и селекторы, при рефакторинге интерфейса всё равно могут потребовать правок — это особенность уровня проверки.

В Black-box мы буквально, не знаем, что внутри. Тыкаем кнопки, смотрим результат, как пользователь.

White-box тестирование ("тестирование белого ящика") основано на знании внутренней архитектуры и исходного кода. Тестировщик проектирует сценарии, направленные на проверку конкретных путей выполнения, ветвлений, циклов, исключений и покрытия строк кода. Теория ветвлений и сложности — Алгоритмы — о разделе; углубление — white-box в 7.05. Этот тип тестирования применяется преимущественно на уровне модульного (unit) и интеграционного тестирования и часто реализуется самими разработчиками.

Развёрнутый разбор графа потока управления, basis path, потоков данных (DEF-USE) и связи с цикломатической сложностью — в статье White-box: потоки управления и данных (гл. 2.3 курса "экономика производства ПО").

White-box подразумевает, что мы видим код, проверяем все if-ы, циклы, как разработчик.

Gray-box тестирование представляет собой гибрид — тестировщик обладает частичной информацией о внутреннем устройстве системы (например, знает архитектурную схему или интерфейсы модулей), но не имеет доступа к полному коду. Такой подход часто используется при интеграционном тестировании или при тестировании API, где знание структуры данных и протоколов взаимодействия повышает эффективность проектирования тест-кейсов, но детали реализации остаются вне зоны ответственности тестировщика.

Gray-box, это когда мы что-то знаем (например, схему базы), но не весь код. Как аналитик или тестировщик с доступом к логам.

Уровни тестирования в жизненном цикле разработки​

Тестирование проводится на различных уровнях абстракции, каждый из которых соответствует определённой стадии сборки и интеграции программного продукта.

      /\
     / E2E \         <- мало сценариев: сквозной путь "как у пользователя"
    / system \      <- вся система по спецификации (часто через UI или API)
   /интеграц.\      <- связи модулей и сервисов
  /----------\
 /   unit     \    <- много, быстро, стабильно
/--------------\
E2E и system — не дубли, но пересекаются

System — "система в целом соответствует требованиям?" (можно проверять через API без браузера).

E2E — узкий сквозной сценарий от входа пользователя до результата (часто через UI).

На диаграмме верх условно подписан E2E — в книгах и на собесах оба уровня называют по-разному; подробнее — в E2E и системное тестирование.

Модульное (unit) тестирование​

  • Кто выполняет: разработчик.
  • Что проверяет — одну маленькую функцию, класс, метод.
  • Быстро, за секунды.

Модульное тестирование фокусируется на проверке отдельных компонентов — функций, методов, классов или модулей — в изоляции от остальной системы. Ключевые требования к unit-тестам определяются принципом FIRST:

  • Fast — выполняются быстро (обычно в миллисекундах);
  • Independent — не зависят друг от друга и могут запускаться в любом порядке;
  • Repeatable — дают одинаковые результаты при каждом запуске в одинаковых условиях;
  • Self-Validating — автоматически определяют успех или провал без ручного анализа;
  • Timely — пишутся своевременно, желательно до или параллельно с реализацией кода (в духе TDD).

Unit-тесты, как правило, реализуются разработчиками с использованием фреймворков, таких как JUnit (Java), pytest или unittest (Python), Jest, Mocha, Jasmine (JavaScript/TypeScript). Они обеспечивают базовую защиту от регрессий и служат документацией поведения кода.

Интеграционное тестирование​

  • Кто выполняет: часто вся команда, а то и обе команды интегрируемых систем.
  • Что проверяет: как модули общаются друг с другом, не сломался ли "договорняк" между сервисами.
  • REST API, SOAP, очереди, базы данных.

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

Для интеграционных тестов часто используют заглушки (stubs) и моки (mocks) — чтобы не дергать продакшен и ускорить прогон. Но там, где это возможно, команды поднимают реальные зависимости на тестовом стенде — контейнер с PostgreSQL (Testcontainers), локальный Kafka, mock-сервер внешнего API (WireMock). Так ловят ошибки "на стыке", которые unit-тест с моком не увидит. Подробнее — в интеграционном тестировании.

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

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

Интеграционное тестирование охватывает различные типы взаимодействия между компонентами системы:

  • Синхронная коммуникация подразумевает немедленный ответ получателя на запрос отправителя. Клиентское приложение отправляет запрос и ожидает ответ в течение определенного времени. Если сервер не отвечает вовремя, клиент получает ошибку таймаута. Этот тип взаимодействия характерен для REST API, где каждый HTTP-запрос ожидает немедленного ответа.
  • Асинхронная коммуникация позволяет отправителю продолжить выполнение задачи после отправки сообщения без ожидания немедленного ответа. Сообщение помещается в очередь или буфер, где оно хранится до тех пор, пока потребитель не будет готов его обработать. Брокеры сообщений выступают посредниками в этом процессе, управляя очередями и гарантируя доставку сообщений. RabbitMQ и Kafka являются популярными примерами таких систем. Асинхронный подход повышает отказоустойчивость системы и позволяет обрабатывать пиковые нагрузки без блокировки основных потоков.
  • Реактивная коммуникация строится на событиях, когда компоненты реагируют на изменения состояния других частей системы. При возникновении события подписанные компоненты получают уведомление и выполняют соответствующие действия. Этот паттерн обеспечивает слабую связанность компонентов и позволяет системе масштабироваться горизонтально. Каждый компонент знает только о событиях, которые его интересуют, и не зависит от конкретных источников событий.

Протоколы передачи данных определяют правила обмена информацией между компонентами:

  • SOAP использует XML-формат для структурирования сообщений и поддерживает строгие контракты через WSDL.
  • gRPC применяет бинарный формат Protocol Buffers для эффективной передачи данных и поддерживает множество языков программирования.
  • GraphQL позволяет клиентам запрашивать именно те данные, которые им нужны, уменьшая объем передаваемой информации и повышая гибкость взаимодействия.

Системное тестирование​

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

Системное тестирование охватывает как функциональные, так и нефункциональные аспекты и служит финальной верификацией перед передачей продукта на приёмку. На этом этапе применяются техники black-box тестирования, а тест-кейсы проектируются на основе спецификаций и пользовательских сценариев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступность (Accessibility) и доступность системы (Availability)​

В русском переводе оба термина часто звучат как "доступность", но в QA это разные оси:

Термин (EN)О чёмПримеры проверок
Accessibility (a11y)Удобство для людей с ограничениями и для "неидеальных" условийСкринридер, навигация с клавиатуры, контраст, субтитры к видео без наушников
AvailabilityСистема доступна для обращений пользователей и интеграцийUptime, SLA, истёкший SSL, "сайт лежит", деградация скорости

Accessibility-тестирование входит в семейство usability, но имеет свои стандарты (WCAG) и инструменты (axe, Lighthouse, NVDA/VoiceOver). Availability относят к надёжности и эксплуатации — см. нагрузочное тестирование и мониторинг в DevOps.

Интернационализация и локализация​

  • Интернационализация (i18n) — продукт изначально проектируют так, чтобы его можно было перевести без переписывания архитектуры (кодировки, форматы дат/валют, запас места под длинные строки).
  • Локализация (l10n) — адаптация уже i18n-ready продукта под конкретный язык и регион (тексты, валюта, правовые формулировки, цвета и символы в культуре).

Тестирование i18n проверяет, что смена локали не ломает логику (ввод на родном языке, RTL, длинные строки в UI). Тестирование l10n — что переводы, форматы и контент соответствуют целевому рынку. Подробнее про мобильные и веб-сценарии — в Особенности тестирования мобильных приложений и Ручное тестирование веб-приложений.

Приёмочное тестирование (UAT)​

  • Кто выполняет: заказчик или даже реальный пользователь.
  • Что проверяет: решена ли проблема, удобно ли пользоваться.
  • Если сказано "да", то подписываем акт и получаем деньги.

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

Можно выделить несколько видов приёмочного тестирования:

  • пользовательское;
  • эксплуатационное;
  • контрактное;
  • бизнес-приёмочное;
  • правовое;
  • альфа-тестирование;
  • бета-тестирование.

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

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

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

Пользовательское тестирование​

UAT — User Acceptance Testing.

  • Живые люди тыкают, ругаются на неудобства.
  • Проводят конечные пользователи или заказчик.
  • Проверяют бизнес-ценность.

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

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

Эксплуатационное тестирование​

OAT — Operational Acceptance Testing.

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

Эксплуатационное тестирование (OAT) фокусируется на проверке работоспособности системы в условиях, имитирующих её будущую производственную среду. Этот процесс включает оценку стабильности работы под нагрузкой, отказоустойчивости при сбоях оборудования или сети, а также способности системы восстанавливаться после аварийных ситуаций. Тестирование выполняется на инфраструктуре, идентичной той, где будет развернут продукт.

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

Контрактное тестирование​

CAT — Contract Acceptance Testing

  • Сверка с договором, всё ли выполнено согласно документации.
  • Проводит заказчик, юристы, технари.
  • Проверяют каждый пункт контракта, количества, показатели, SLA, гарантии, форматы.

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

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

Бизнес-приёмочное тестирование​

BATS — Business Acceptance Testing.

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

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

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

Правовое тестирование​

RAT — Regulatory Acceptance Testing.

  • Не нарушается ли закон? Не сливаются ли персональные данные?
  • Проводят юристы, compliance-отдел, аудиторы, иногда даже внешние эксперты.
  • Проверяют соответствие законам, отраслевым стандартам, регуляторным требованиям.

Правовое тестирование (RAT) проверяет соответствие программного обеспечения законодательным нормам, отраслевым стандартам и внутренним правилам безопасности данных. Этот вид проверки особенно актуален для систем, работающих с персональными данными, финансовой информацией или в регулируемых отраслях, таких как здравоохранение и банковский сектор. Тестирование охватывает вопросы лицензирования, защиты конфиденциальности и соблюдения этических норм.

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

Альфа-тестирование​

Суть - проведение внутри компании, до внешних пользователей. Либо в узком кругу.

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

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

Бета-тестирование​

Суть - отдаётся ограниченному кругу реальных юзеров с задачей "сломать".

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

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

Две оси — не путать альфа/бета и black/white box

Альфа и бета описывают стадию и аудиторию (внутри компании vs внешние пользователи, близость к релизу).

Black-, white- и gray-box описывают доступ тестировщика к реализации при проектировании проверок.

Бета-программа для пользователей обычно идёт как black-box по интерфейсу, но параллельно команда может гонять white-box автотесты и анализ кода.

Метка "бета-версия" не означает автоматически "только чёрный ящик".

ОсьПримеры значенийВопрос
Стадия / аудиторияальфа, бета, приёмка (UAT)Кто тестирует и насколько продукт "сырой"?
Доступ к реализацииblack, white, grayВидим ли код, схему БД, только UI/API?

Вспомогательные виды тестирования на уровне жизненного цикла​

На практике к "уровням" (unit, integration…) добавляют короткие прогоны по событию — после сборки, перед релизом, после фикса бага. Их легко перепутать; ниже — различия.

ВидКогдаЗачемОбъём
Smoke (дымовое)Сразу после новой сборки"Вообще заводится?" — логин, главная, один критичный APIМинуты
Sanity (санитарное)После точечного фикса или патча"Исправленная область и соседи не развалились?"Узкий набор
Регрессия (regression)Перед релизом, после крупных изменений"Старое не сломали?"От smoke до полного набора
Confirmation / retestПосле исправления конкретного бага"Этот дефект действительно закрыт?"Один кейс + близкие проверки

  • Дымовое тестирование (Smoke testing) — минимальный набор проверок, подтверждающий, что критически важные функции системы работоспособны после сборки. Не прошло smoke — глубокий регресс обычно откладывают: смысла мало, пока сборка "не дымит".

  • Санитарное тестирование (Sanity testing) — быстрая проверка затронутой зоны после небольшого изменения. Пример: починили валидацию email — прогоняем регистрацию и смежные поля, а не весь каталог на 500 кейсов.

  • Тестирование критического пути (Critical Path Testing) — фокус на сценариях, без которых система теряет основную ценность (оплата, авторизация, выдача отчёта). Обычно идёт после успешного smoke: проверяются типовые "счастливые" пути без углубления в редкие негативные ветки.

  • Расширенное тестирование (Extended Test) — прогон всей заявленной в требованиях функциональности, включая низкоприоритетные сценарии. Имеет смысл перед релизом или по матрице рисков, когда smoke и critical path уже зелёные.

  • Build Verification Test (BVT) — проверка конкретной сборки на работоспособность критичного ядра. По смыслу близко к smoke; на части проектов BVT глубже (не только "заводится", но и ключевые интеграции). Не прошли BVT/smoke — полный регресс обычно откладывают.

  • Регрессионное тестирование — повторное выполнение ранее успешных тестов после изменений. Бывает полным (весь набор) и выборочным (риск-ориентированный поднабор). Цель — поймать побочный эффект, а не перепроверить один исправленный баг (для этого — confirmation testing).

Степень формализации и свободное тестирование​

ПодходФормализацияКто и как
На основе тест-кейсовВысокаяШаги и ожидания заданы; прогон сравнивает факт с эталоном
Исследовательское (exploratory)СредняяТест-дизайн и прогон одновременно; нужны заметки, цель сессии, опыт
Свободное (ad-hoc)НизкаяБез кейсов и чек-листов; опираются на интуицию "здесь может сломаться"
Monkey testingМинимальнаяНамеренный хаос — случайные клики и данные, чтобы сломать UI или API

Ad-hoc часто практикуют бета-тестеры без методологии; exploratory ведут QA с техниками и отчётом о сессии. Monkey — отдельный приём для стресс-проверки устойчивости интерфейса, не замена регресса.

Регресс ≠ "перепроверка бага"

Confirmation testing (retest) — один (или несколько) кейсов по закрытому дефекту.

Regression — "не сломали ли мы что-то ещё". В Jira после фикса обычно делают и то, и другое, но называют по-разному.

Жизненный цикл дефекта​

Обычно существует трекер багов — Jira, YouTrack, Azure DevOps. Типичный цикл: "нашёл → завёл → подтвердили на триаже → исправили → проверили фикс → закрыли". Не каждый тикет — "косяк разработчика" — бывают уточнения требований, среда, дубликаты.

Для эффективного управления качеством важно различать три связанных, но не тождественных понятия:

  • Ошибка (Mistake) — это человеческое упущение, допущенное на этапе анализа, проектирования или кодирования. Ошибка является причиной.
  • Дефект (Defect/Bug) — следствие ошибки — некорректный фрагмент требования, архитектуры или кода, который ещё не проявил себя в работе системы. Дефект существует в артефактах проекта.
  • Сбой (Failure) — наблюдаемое отклонение от ожидаемого поведения во время выполнения программы. Сбой возникает тогда, когда дефект активируется при определённых условиях выполнения.

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

Дефект проходит определённый жизненный цикл:

  1. Обнаружение — тестировщик фиксирует несоответствие.
  2. Регистрация — создаётся отчёт (bug report) с описанием, шагами воспроизведения, окружением и приоритетом.
  3. Подтверждение/Триаж — команда решает, является ли это реальным дефектом и насколько он критичен.
  4. Назначение — дефект передаётся ответственному разработчику.
  5. Исправление — внесение изменений в код или документацию.
  6. Проверка исправления (confirmation testing / retest) — повторный прогон шагов из баг-репорта на сборке с фиксом; убеждаемся, что дефект устранён.
  7. Регрессия по области (при необходимости) — короткий набор смежных кейсов, чтобы фикс не сломал соседнюю логику.
  8. Закрытие — статус вроде Resolved / Verified / Closed.
Не путать с "верификацией" из основ

В основах тестирования верификация — "правильно ли собрали систему по требованиям" (review, статический анализ). Повторный прогон после фикса бага в трекере называют retest или confirmation testing, а не verification в смысле V&V.

На всех этапах важна точность формулировок, воспроизводимость и прозрачность — особенно в распределённых командах.

Влияние модели жизненного цикла разработки (SDLC) на тестирование​

Выбор модели разработки определяет, когда, как и в каком объёме проводится тестирование.

  • Водопадная модель предполагает последовательное выполнение фаз: требования → проектирование → реализация → тестирование → эксплуатация. В такой модели тестирование начинается только после завершения кодирования, что увеличивает стоимость исправления дефектов и снижает гибкость. Однако она подходит для проектов с чётко фиксированными и стабильными требованиями (например, в регулируемых отраслях).

  • V-Model — модификация водопада, где каждой фазе разработки сопоставляется соответствующая фаза тестирования (например, анализ требований ↔ приёмочное тестирование, проектирование системы ↔ системное тестирование). Это делает тестирование более структурированным и позволяет начать проектирование тестов уже на этапе анализа.

  • Итеративные и спиральные модели вводят цикличность — каждая итерация включает в себя свои подциклы анализа, проектирования, реализации и тестирования. Это позволяет выявлять дефекты раньше и корректировать курс проекта на основе обратной связи.

  • Agile (Scrum, Kanban) — наиболее распространённый современный подход, в котором тестирование интегрировано в каждый спринт. Тестировщики работают в тесной связке с разработчиками и аналитиками с самого начала итерации. Практики, такие как непрерывная интеграция (CI), тестирование на ранних этапах (shift-left testing) и автоматизация регрессионных проверок, становятся нормой. Здесь особенно важна культура совместной ответственности за качество ("Quality is everyone’s job").

Во всех современных подходах подчёркивается принцип раннего тестирования: чем раньше начат анализ требований и проектирование тестов, тем ниже стоимость исправления дефектов и выше общее качество продукта. Согласно исследованиям, исправление дефекта на этапе эксплуатации может быть в 10–100 раз дороже, чем на этапе проектирования.

Как быстро выбирать вид тестирования под задачу​

На практике помогает короткая матрица решений:

  • Если меняется чистая функция или бизнес-правило без внешних зависимостей — начинайте с unit.
  • Если меняется контракт API, SQL-запрос, очередь или интеграция со сторонним сервисом — нужен integration.
  • Если меняется пользовательский путь (регистрация, оплата, оформление) — добавляйте system/E2E.
  • Если фикс точечный — делайте retest + короткий regression по соседним зонам.
  • Если релиз крупный — комбинируйте smoke и риск-ориентированный регресс.

Такая схема помогает не спорить "что важнее", а подбирать проверки по типу риска.

Типовые анти-паттерны классификации​

  • Называть любой автотест "E2E", даже если это unit или integration.
  • Смешивать цель и уровень: "регрессия" — это событие прогона, а не уровень как unit/system.
  • Опираться только на coverage в процентах без проверки критичных бизнес-путей.
  • Делать "полный регресс" на каждый мелкий фикс вместо адекватного выборочного прогона.

Эти ошибки увеличивают стоимость тестирования и создают ложное ощущение контроля качества.

Как связать классификацию с планом релиза​

Рабочий минимум для команды:

  1. Зафиксировать уровни и типы тестов в стратегии тестирования.
  2. Прописать, какие проверки обязательны для merge и какие для релиза.
  3. Поддерживать актуальный набор smoke-кейсов по критическому пути.
  4. Проводить регулярный пересмотр набора регрессии по дефектам последних релизов.

Для полного цикла применяйте эту статью вместе с основами тестирования, жизненным циклом тестирования и порядком этапов.

Кейс выбора проверок для hotfix​

Сценарий: в продакшене нашли дефект в авторизации, нужен быстрый hotfix.

Оптимальный набор:

  • unit-тест на исправленную функцию валидации токена;
  • integration-тест на контракт с сервисом сессий;
  • confirmation тест по дефекту из баг-репорта;
  • короткий smoke по входу и критическому пользовательскому пути;
  • целевой регресс соседних сценариев (смена пароля, выход, продление сессии).

Такой набор даёт скорость и контроль риска без полного регресса всей системы.

Шаблон артефакта — матрица "изменение -> вид теста"​

Матрица выбора:
- Изменение бизнес-правила в сервисе -> Unit + Integration
- Изменение API-контракта -> Integration + Contract tests
- Изменение UI-формы -> UI manual + UI automation smoke
- Изменение критичного пользовательского пути -> System/E2E + regression
- Hotfix в прод -> Retest + target regression + smoke

Матрицу удобно закрепить в wiki команды и использовать на triage релизов.

Готовые поля для Jira и YouTrack​

Issue Type: Task
Summary: [QA PROCESS] Обновить матрицу "изменение -> вид теста"
Scope: модуль/продукт/команда
Change Types Covered:
- business logic
- API contract
- UI flow
- hotfix
Release Rules:
- обязательные тесты для merge
- обязательные тесты для release
DoD:
[ ] Матрица обновлена
[ ] Команда согласовала правила
[ ] Ссылка добавлена в release checklist

Пример заполнения:

Issue Type: Task
Summary: [QA PROCESS] Обновить матрицу тестов для auth-domain
Scope: auth-service, web-login, mobile-login
Change Types Covered:
- business logic
- API contract
- UI flow
- hotfix
Release Rules:
- merge: unit + integration обязательны
- release: smoke + target regression обязательны
DoD:
[x] Матрица обновлена
[x] Команда согласовала правила
[x] Ссылка добавлена в release checklist

Навигация по разделу "Тестирование"​

Содержание