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

Последовательность этапов тестирования

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

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

Зачем эта статья. Жизненный цикл отвечает на вопрос "какие фазы проходит QA в релизе". Эта статья — "в каком порядке проверять технически" — сначала маленькие кусочки (unit), потом связи (integration), потом система целиком и приёмка (UAT). Порядок экономит время: дешёвые тесты ловят баги раньше дорогих.

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

Последовательность этапов тестирования​

Порядок тестирования — это заранее согласованная лестница проверок, а не хаотичное "где нашли — там и ткнули".

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

Быстрый ориентир по шагам:

  1. Unit-проверки на уровне логики.
  2. Интеграционные и API-проверки на уровне связей.
  3. Системные и E2E-сценарии на уровне пользовательских потоков.
  4. Приёмка и решение о релизе по фактам из отчётов.

Понятие порядка в контексте тестирования​

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

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

Симуляция действий пользователя​

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

Симуляция не ограничивается механическим повторением кликов или вводом данных. Она включает:

  • воспроизведение типовых пользовательских сценариев (use cases), описанных в техническом задании или пользовательских историях;
  • имитацию нестандартных, но возможных действий — например, отмена операции на полпути, переключение контекста, прерывание соединения;
  • моделирование поведения различных ролей (администратор, гость, сотрудник отдела продаж и т.д.), если система поддерживает многоуровневый доступ.

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

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

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

Проверка на ошибки​

Второй фундаментальный тезис порядка тестирования — проверка на ошибки, под которой понимается целенаправленная попытка заставить систему "сломаться" или выдать некорректный результат. Если симуляция действий пользователя оценивает поведение системы в штатных условиях, то проверка на ошибки фокусируется на её поведении в условиях стресса, аномалий и некорректного ввода.

Этот подход опирается на принцип: "всё, что может пойти не так — пойдёт не так" (закон Мерфи). Поэтому тестирование не ограничивается проверкой успешных сценариев. Необходимо также:

  • вводить данные, выходящие за пределы допустимых значений (например, отрицательная дата, слишком длинная строка, специальные символы в числовых полях);
  • моделировать отказы внешних зависимостей (отсутствие сети, недоступность базы данных, таймауты API);
  • проверять обработку исключений и корректность сообщений об ошибках;
  • тестировать граничные условия (boundary values), где даже незначительное изменение параметра может привести к резкому изменению поведения.

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

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

Инструментально такая проверка реализуется через:

  • тесты на граничные значения и эквивалентные классы (техники black-box тестирования);
  • фаззинг-тестирование (fuzz testing) — подача случайных или полуслучайных данных с целью вызвать сбой;
  • инъекционные тесты (SQL injection, XSS и пр.) в веб-приложениях;
  • chaos engineering — намеренное внесение сбоев в работающую систему для оценки её устойчивости.

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

Проверка на соответствие документации​

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

  • пользовательские договорённости, зафиксированные в user stories или acceptance criteria;
  • архитектурные решения, описанные в ADR (Architectural Decision Records);
  • стандарты оформления интерфейсов (UI/UX guidelines);
  • регламенты внутреннего и внешнего взаимодействия (API-контракты, протоколы обмена);
  • нормативные акты и комплаенс-требования (GDPR, HIPAA и др., если применимо).

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

Процедура проверки на соответствие включает:

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

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

Интеграция тезисов в единую стратегию тестирования​

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

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

В совокупности они формируют трёхмерное пространство тестирования:

  • по оси поведения — что делает пользователь;
  • по оси надёжности — как система реагирует на нарушения;
  • по оси соответствия — соответствует ли поведение системе требований.

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

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

Порядок тестирования не может быть оторван от модели жизненного цикла (Software Разработка Life Cycle, SDLC), в рамках которой реализуется проект. В классических моделях (водопадной, V-модели) порядок строго привязан к фазам — сначала проектирование, затем реализация, далее — модульное, интеграционное, системное и приёмочное тестирование. В таких моделях каждый этап тестирования чётко отделён от предыдущего и последующего, а результаты одного этапа служат входными данными для следующего.

В итеративных и инкрементальных моделях (Agile, DevOps) порядок приобретает циклический характер. Тестирование встраивается в каждый спринт или даже в каждый коммит. Здесь порядок определяется глубиной интеграции и уровнем абстракции проверяемого компонента:

  1. Unit-тестирование — проверка изолированных функций или методов. Здесь преобладает проверка на ошибки (тестирование граничных условий, исключений), а также верификация логики по спецификации (частный случай соответствия документации).
  2. Интеграционное тестирование — проверка взаимодействия компонентов. Возникает необходимость симуляции действий смежных модулей, а также проверки устойчивости к сбоям в цепочке вызовов.
  3. Системное тестирование — проверка всей системы как единого целого. В этом слое доминирует симуляция действий пользователя и проверка соответствия функциональным требованиям.
  4. Регрессионное и приёмочное тестирование — финальная верификация стабильности и готовности к эксплуатации. Здесь особенно важна проверка соответствия документации и бизнес-контексту.

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

Влияние типа системы на порядок тестирования​

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

  • Веб-приложения требуют особого внимания к симуляции пользовательских сценариев в различных браузерах и устройствах, а также к проверке на ошибки, связанные с сетевыми задержками, состоянием сессии и безопасностью (например, CSRF, XSS).
  • Встроенные системы и промышленное ПО делают акцент на проверке на ошибки в условиях аппаратных ограничений и временных дисциплин (real-time constraints). Здесь критична детерминированность реакции на исключительные ситуации.
  • Системы обработки данных (ETL, аналитические платформы) подчёркивают соответствие документации в части семантики данных, точности вычислений и целостности при трансформациях.
  • Распределённые системы (микросервисы, облачные архитектуры) требуют специфических подходов к симуляции отказов (Chaos Engineering), а также к верификации контрактов между сервисами как формы соответствия документации.

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

Роль документации в поддержании порядка​

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

Особую роль играет тестовая документация:

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

В контексте разработки образовательного или корпоративного программного обеспечения (например, на платформах BPM), где бизнес-логика часто формализована в виде графических моделей (BPML, BPMN), проверка на соответствие документации приобретает форму сверки поведения системы с визуальной моделью процесса. Это требует функционального тестирования и анализа семантической целостности между моделью и реализацией.

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

Содержание