6.08. Проектные артефакты QA

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Тестировщику Разработчику Аналитику

Проектные артефакты QA

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

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

Отсутствие или низкое качество QA-артефактов ведёт к неопределённости в понимании охвата тестирования, затрудняет воспроизведение ошибок, снижает прозрачность процесса и делает невозможным объективную оценку зрелости процессов тестирования. Особенно критично это в проектах, подчиняющихся стандартам ISO/IEC 12207, IEEE 829, GOST Р ИСО/МЭК 12207, а также отраслевым нормативам — например, в сфере здравоохранения (FDA 21 CFR Part 11), авионики (DO-178C), финансовых сервисов (PCI DSS, ГОСТ Р 57580) или государственных информационных систем (требования ФСТЭК и ФСБ РФ).

Понятие прослеживаемости как системообразующий принцип

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

Эта цепочка называется матрицей прослеживаемости требований (Requirements Traceability Matrix, RTM). В контексте QA она обеспечивает:
— полноту покрытия: проверку, что каждое требование проверяется хотя бы одним тестом;
— целесообразность тестирования: исключение избыточных или несвязанных с целями продукта тестов;
— анализ влияния изменений: при модификации требования быстро выявляются затронутые тесты и потенциальные регрессии;
— подотчётность: демонстрация аудиторам и заказчикам, что контроль качества проводился системно и без пробелов.

Прослеживаемость реализуется через явные ссылки (например, ID требования в поле «Требования» тест-кейса), и инструментальные средства: системы управления тестированием (TestRail, Zephyr, Xray), интегрированные платформы (Jira + Confluence + Xray), или даже структурированные таблицы в Excel при отсутствии специализированного ПО. Однако техническая реализация вторична по отношению к методологической дисциплине: без осознанного следования принципу прослеживаемости даже самая продвинутая система остаётся пустой формой.

Классификация проектных артефактов QA

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

1. Стратегические артефакты — определяют долгосрочные подходы и стандарты, применимые ко всему портфелю проектов или крупной программе.
2. Тактические артефакты — планируют и координируют тестирование в рамках одного релиза или итерации.
3. Операционные артефакты — непосредственно поддерживают исполнение и контроль тестовых активностей.
4. Аналитические и отчётные артефакты — фиксируют результаты, выводы и рекомендации для принятия решений.

Рассмотрим каждый тип подробно.

1. Test Strategy (Тестовая стратегия)

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

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

Ключевые компоненты стратегии включают:
— цели тестирования: конкретные, измеримые — например, «обеспечить покрытие всех критических бизнес-сценариев на 100 %», «снизить количество escape defects в production до менее 0,5 % от общего числа найденных дефектов».
— методологии тестирования: выбор между сквозным (end-to-end), компонентным, интеграционным, exploratory-подходами; определение доли ручного и автоматизированного тестирования; решение о применении shift-left или shift-right практик.
— стандарты и процессы: ссылки на внутренние регламенты (например, «Все тест-кейсы проходят peer-review перед включением в набор») или внешние стандарты (IEEE 829 для структуры отчётов).
— роли и ответственности: кто составляет тест-план, кто проводит тест-дизайн, кто утверждает отчёт — с учётом матрицы RACI.
— метрическая система: какие показатели используются для оценки качества (количество дефектов, плотность дефектов на функцию, время на воспроизведение, процент автоматизированных тестов, MTTR для critical-багов и т.д.).
— инструментальный стек: перечень допустимых решений для управления тестами, автоматизации, отслеживания дефектов, мониторинга окружений — с обоснованием выбора.

Стратегия утверждается на уровне руководства QA-направления или технического директората и пересматривается не чаще одного раза в квартал или при смене архитектурной парадигмы продукта.

2. Test Plan (Тест-план)

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

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

Основные разделы тест-плана:
— область тестирования (scope): чёткое разграничение того, что входит и что не входит в тестирование данного релиза. Например, «тестируется модуль расчёта НДС, интеграция с 1С-Бухгалтерия версии 8.3.20+, но не тестируется импорт данных из устаревших форматов *.dbf». Подразумевается, что out-of-scope элементы либо протестированы ранее, либо их проверка отложена по согласованию.
— подход к тестированию: как именно будет реализован тест-дизайн (эквивалентное разбиение, анализ граничных значений, таблицы решений), какие типы тестов приоритетны (юзабилити, нагрузка, безопасность), будет ли проводиться тестирование на разных языковых локалях.
— ресурсы: количество тестировщиков, их компетенции (например, «требуется специалист с опытом тестирования SOAP-сервисов»), а также задействованные инструменты и лицензии.
— окружения: описание конфигураций (dev, staging, performance lab), включая версии ОС, СУБД, middleware, сетевые настройки. Особенно важно фиксировать отклонения от production-подобия — например, «тестовое окружение использует PostgreSQL 14 вместо production-версии 15, что ограничивает проверку некоторых оптимизаторных фич».
— расписание: зависимые события — например, «тестирование модуля X начинается не ранее 3-го числа, после завершения сборки и развёртывания патча Y».
— критерии входа и выхода: условия, при которых тестирование может начаться (например, «все критические дефекты предыдущего этапа закрыты», «доступен тестовый набор данных») и условия, при которых оно считается завершённым («покрытие требований ≥ 95 %», «нет открытых дефектов severity Critical», «результаты нагрузочного теста соответствуют SLA»).
— управление рисками: идентификация потенциальных угроз («отсутствие тестовых данных для сценария возврата средств»), оценка их влияния и вероятности, а также планы реагирования (например, «в случае задержки поставки mock-сервиса — использовать stub-реализацию, ограничивающую покрытие до 80 %»).

Хороший тест-план предотвращает ситуацию, когда команда в финале итерации обнаруживает, что «забыла протестировать экспорт в Excel», потому что этот функционал не был включён в scope по объективным причинам, и решение было задокументировано.

3. Test Design Specification (Спецификация тестового проектирования)

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

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

Спецификация тестового проектирования состоит из трёх логических уровней:

1. Тестовые условия (Test Conditions) — это атомарные утверждения о поведении системы, которые поддаются верификации. Условие формулируется как «Система должна…» или «При выполнении X система обязана Y», и напрямую привязывается к конкретному пункту технического задания или user story. Пример:

   Требование REQ-204: «При вводе некорректного CVV-кода платежная форма отображает ошибку “Неверный CVV” и не отправляет запрос в шлюз»
   → Тестовое условие TC-204.1: «Отображение сообщения об ошибке CVV при вводе строки длиной ≠ 3 символа»
   → Тестовое условие TC-204.2: «Блокировка отправки запроса в платёжный шлюз при неверном CVV»

2. Методы проектирования тестов (Test Design Techniques) — выбор техники, по которой будет генерироваться набор конкретных сценариев для каждого условия. Классические методы включают:
   — Эквивалентное разбиение: выделение классов входных данных, ведущих к однотипному поведению (например, для поля «возраст»: 0–17, 18–65, 66+).
   — Анализ граничных значений: проверка значений на стыке классов эквивалентности (17, 18, 65, 66).
   — Таблицы решений: применение при наличии нескольких логических условий с чёткими комбинациями (например, скидка зависит от типа клиента И суммы заказа И наличия промокода).
   — Попарное тестирование (All-Pairs): для многомерных входов, когда полное покрытие всех комбинаций невозможно, но необходимо проверить взаимодействие параметров попарно.
   — State Transition Testing: когда система имеет дискретные состояния и переходы между ними управляются событиями (например, жизненный цикл заказа: «создан» → «оплачен» → «отгружен» → «доставлен»).
   Выбор метода фиксируется в спецификации с обоснованием — например: «Для поля “пароль” применён анализ граничных значений, так как требования явно регламентируют минимальную (8) и максимальную (64) длину».

3. Связь с требованиями и рисками — в этом разделе явно отражается, какие требования покрываются данным блоком проектирования, и какие риски снижаются (например, «Покрытие REQ-512 снижает риск блокировки легитимных пользователей при сбросе пароля»).

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

4. Test Case Specification (Спецификация тест-кейса)

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

Структура типового тест-кейса включает следующие элементы:

— Уникальный идентификатор (ID). Формат обычно иерархический (например, TC_LOGIN_012) и отражает модуль, функцию и порядковый номер. ID позволяет однозначно ссылаться на кейс в отчётах, логах и при обсуждении.

— Заголовок / Название. Должен быть информативным и отражать суть проверки: «Аутентификация по логину/паролю при вводе корректных учётных данных», а не «Тест 12».

— Связь с источниками. Указываются ID требований, тестовых условий и (при наличии) user stories. Это обеспечивает прослеживаемость в обе стороны.

— Предусловия (Preconditions). Состояния системы и окружения, которые должны быть выполнены до начала теста. Критически важны для воспроизводимости. Пример: «Пользователь зарегистрирован в системе», «База данных содержит запись о тарифе “Премиум” с ценой 990 руб./мес.», «Окружение: staging, версия API v2.4.1». Если предусловие не выполняется, тест считается некорректно запущенным — даже если шаги технически пройдены.

— Постусловия (Postconditions). Требуемые состояния после завершения теста — например, «Сессия пользователя завершена», «Временный файл лога удалён». Позволяет гарантировать «чистоту» окружения для последующих тестов.

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

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

1. Открыть браузер Chrome версии 128.
2. Перейти по адресу https://staging.example.com/login.
3. В поле «Логин» ввести «test_user_valid».
4. В поле «Пароль» ввести «Passw0rd!».
5. Нажать кнопку «Войти».
   Важно: шаги не должны содержать условных переходов («если появилось окно — нажать OK»), так как это нарушает воспроизводимость. Такие сценарии выделяются в отдельные кейсы или обрабатываются в exploratory-сессиях.

— Ожидаемый результат. Точное описание того, что должно произойти после выполнения шага (или группы шагов). Должен быть объективным и проверяемым: «Открывается страница “Личный кабинет” с заголовком “Добро пожаловать, test_user_valid”», «В консоли браузера отсутствуют ошибки уровня Error», а не «Пользователь успешно заходит».

— Приоритет и важность (Priority / Importance). Обычно по шкале:
— High: покрывает критическое требование, блокирующее основной сценарий;
— Medium: важен для второстепенных сценариев;
— Low: касается UI-нюансов, справочной информации и т.д.
Приоритет определяет очерёдность выполнения при ограничении времени.

— Теги и метаданные. Модуль («Авторизация», «Платежи»), тип теста («Функциональный», «UI», «API»), необходимость автоматизации («Eligible for automation»), автор, дата создания, версия продукта.

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

5. Test Log (Тестовый лог)

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

В отличие от отчёта, лог констатирует события. Он может вестись автоматически (например, CI/CD-пайплайн записывает результат каждого запуска в базу) или вручную (тестировщик заносит запись после прогона).

Обязательные атрибуты записи в логе:
— Дата и точное время начала/окончания выполнения (с учётом часового пояса).
— Идентификатор тест-кейса или набора.
— Статус выполнения: Passed, Failed, Blocked, Skipped — с указанием причины для последних двух (например, «Blocked: недоступен mock-сервис AuthMock v3»).
— Исполнитель (если ручное тестирование) или система/агент (если автоматизированное).
— Окружение и конфигурация на момент запуска: версия сборки (build number), хэш коммита, параметры окружения. Это критично для диагностики: дефект, воспроизводящийся только на сборке #1427, может быть вызван конкретным фиксом.
— Краткий комментарий или ссылка на доказательства: скриншот, видео, лог-файл, URL в TestRail. При статусе Failed комментарий должен содержать достаточно информации для быстрого воспроизведения без обращения к автору.

Лог служит основой для построения метрик: динамики прохождения тестов, времени на выполнение, стабильности сборок. В распределённых командах он предотвращает дублирование работы: «Коллега, TC_PAYMENT_045 уже запущен в 11:30, статус — In Progress».

6. Defect Report (Отчёт о дефекте)

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

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

— Чёткое и нейтральное название. Формулировка через наблюдаемое поведение: «После подтверждения оплаты статус заказа остаётся “Ожидает оплаты”».

— Шаги воспроизведения. Детализированные, нумерованные, с указанием тестовых данных и предусловий — по той же схеме, что и в тест-кейсе. Если дефект найден в ходе exploratory-тестирования, шаги должны быть реконструированы максимально точно.

— Фактический результат. Что произошло — объективно, без оценок: «Страница отображает HTTP 500», «В поле “Итого” отображается значение 0.00 при ненулевой корзине».

— Ожидаемый результат. Ссылка на требование или здравый смысл: «Согласно REQ-771, статус должен измениться на “Оплачен”, пользователь перенаправляется на страницу подтверждения».

— Окружение. Версия ПО (включая номер сборки), ОС, браузер/устройство, сетевые условия (при релевантности). Для мобильных приложений — модель устройства, версия ОС, ориентация экрана.

— Вложения. Скриншоты, видеозаписи (особенно для UI-глюков), фрагменты логов сервера/клиента, дампы сетевых запросов (HAR-файлы). Видео предпочтительнее скриншотов при нестабильных или временных дефектах.

— Классификация:
— Severity — влияние на бизнес: Critical (блокирует работу), Major (серьёзно нарушает функционал), Minor (косметика), Trivial (орфография).
— Priority — срочность исправления: High (до релиза), Medium (в ближайшем патче), Low (в долгосрочном плане).
Severity и Priority — разные измерения: дефект с Minor severity (опечатка в футере) может иметь High priority, если релиз на завтра и заказчик настаивает.

— Статус жизненного цикла: New → Open → In Progress → Fixed → Verified → Closed (или Reopened). Переходы должны быть согласованы и фиксироваться в системе.

— Связи: ссылки на связанные дефекты (дубликаты, «блокируется»), требования, тест-кейсы, в которых дефект был выявлен.

В регулируемых средах отчёт о дефекте является частью досье продукта и может запрашиваться контролирующими органами.

7. Test Summary Report (Сводный отчёт по тестированию)

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

Он адресован QA-команде, product-менеджерам, руководителям разработки, заказчикам — поэтому язык должен быть точным, но не избыточно техническим.

Структура отчёта:

— Контекст: наименование проекта/релиза, период тестирования, состав команды, версии ПО и окружений.

— Метрики качества:
— Объём тестирования: количество запланированных / выполненных / пройденных / проваленных тестов.
— Покрытие требований (по RTM): % требований с ≥1 тестом, % требований с 100 % passed-тестами.
— Статистика дефектов: общее количество, распределение по severity/priority, динамика (например, график открытия/закрытия по дням), количество escape defects (найденных после релиза).
— Эффективность тестов: например, defect detection percentage (DDP) — доля дефектов, найденных QA до релиза, от общего числа дефектов, выявленных за весь жизненный цикл версии.

— Анализ дефектов:
— Топ-5 модулей по плотности дефектов (дефектов / KLOC или / функция).
— Классификация по корневым причинам (например, «45 % — недостаточная проработка требований», «30 % — регрессия после рефакторинга»). Это позволяет корректировать процессы на следующих итерациях.

— Оценка рисков:
Перечень оставшихся рисков с оценкой воздействия и вероятности:

Риск R-08: Неполное покрытие сценария возврата средств для иностранных карт (покрытие 60 %). Воздействие: High (финансовые потери), Вероятность: Medium (редкий сценарий). Рекомендация: выпуск с оговоркой, тестирование в production-режиме мониторинга первых 10 транзакций.

— Рекомендации: чёткое, обоснованное предложение — «Рекомендуется отложить релиз до устранения 3-х critical-дефектов» или «Релиз допустим при условии включения feature-flag для модуля отчётов».

— Выводы и уроки: краткий анализ эффективности тестового процесса — что сработало, что требует доработки (например, «Сокращение времени на подготовку тестовых данных на 40 % за счёт внедрения генератора»).

Сводный отчёт подписывается ведущим QA-инженером или руководителем QA — это акт профессиональной ответственности.

---

Интеграция артефактов в единый процесс

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

• Test Strategy задаёт рамки для Test Plan;
• Test Plan определяет объём, в рамках которого создаётся Test Design Specification;
• Test Design генерирует Test Case Specification;
• Test Cases выполняются, и результаты фиксируются в Test Log;
• При выявлении несоответствий создаются Defect Reports;
• Все артефакты агрегируются в Test Summary Report;
• Отчёт, в свою очередь, становится входом для корректировки Test Strategy на следующем этапе.

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

---

Практическая реализация артефактов: шаблоны и принципы наполнения

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

Принципы качественного артефакта

1. Автономность — артефакт должен быть понятен и исполняем без обращения к внешним источникам (кроме явно указанных ссылок на требования). Если для понимания тест-кейса требуется открыть три документа и уточнить у коллеги — он не автономен.

2. Однозначность терминов — используется глоссарий проекта. Например, термин «пользователь» должен быть чётко определён: это «лицо, прошедшее аутентификацию и имеющее роль CUSTOMER», а не «тот, кто зашёл на сайт». Неоднозначные формулировки — основная причина расхождений в интерпретации результатов.

3. Версионность и актуальность — каждый артефакт содержит метаданные: дата создания, дата последнего изменения, автор, номер версии, статус (Draft, Approved, Obsolete). Автоматизированные системы (Confluence, Polarion, ReqSuite) поддерживают управление версиями; при ручном ведении — используется сквозная нумерация и журнал изменений.

4. Машинная читаемость (при необходимости) — если артефакт участвует в автоматизации (например, тест-кейс преобразуется в скрипт), его структура должна допускать парсинг. Это достигается через единообразное именование полей, использование контролируемых словарей (например, статусы только из списка: PASS, FAIL, BLOCKED) и избегание свободного текста в критических полях.

Ниже — текстовые шаблоны, пригодные для адаптации в Markdown без риска поломки форматирования.

---

Шаблон: Test Strategy (фрагмент — раздел «Методологии»)

Цель: формализовать выбор подходов без избыточной детализации.

3. Методологии тестирования

Для продукта «Финансовый портал» применяется гибридный подход, сочетающий:
— Сквозное тестирование (E2E) — для верификации критических бизнес-транзакций (регистрация, оплата, формирование отчёта). Объём: 100 % покрытие сценариев из раздела «Основные пользовательские пути» ТЗ.
— Компонентное тестирование — для верификации бизнес-логики финансовых расчётов вне зависимости от UI. Реализуется через unit- и integration-тесты на уровне сервисов. Требование: покрытие всех публичных методов классов расчёта ≥ 85 % по lines of code.
— Exploratory-тестирование — проводится еженедельно в течение 4-х часов на стабильной staging-сборке. Фокус: UX, обработка нештатных ситуаций, взаимодействие с внешними системами при задержках/ошибках. Результаты фиксируются в форме сессионных отчётов (charter-based).
— Тестирование безопасности — выполняется ежеквартально командой InfoSec по методике OWASP ASVS Level 2. Внепланово — при внесении изменений в модули аутентификации, авторизации и обработки платёжных данных.

Автоматизация применяется для:
— регрессионного набора (частота запуска: nightly),
— smoke-тестов (частота: после каждой сборки),
— нагрузочных тестов (ежемесячно, перед major-релизами).

Доля ручного тестирования:
— функциональное тестирование новых функций — 100 % (до стабилизации),
— юзабилити и локализация — 100 %,
— регрессия — ≤ 15 % от общего объёма.

---

Шаблон: Test Case Specification (полный пример)

Цель: демонстрация структуры без использования таблиц.

ID: TC_AUTH_027
Название: Блокировка аккаунта после 5 неудачных попыток входа в течение 15 минут
Связано с: REQ-AUTH-045, US-Login-Flow
Приоритет: High
Модуль: Аутентификация
Тип: Функциональный, Security

Предусловия:
— В системе зарегистрирован пользователь blocked_user@test.ru с паролем CorrectPass1!.
— Счётчик неудачных попыток входа для данного пользователя сброшен (значение = 0).
— Текущее время сервера: 2025-11-21 14:00:00 MSK.
— Окружение: staging, версия API v3.1.9, build #2044.

Тестовые данные:
— Логин: blocked_user@test.ru
— Неверные пароли: Wrong1, Wrong2, Wrong3, Wrong4, Wrong5
— Верный пароль: CorrectPass1!

Шаги выполнения:

1. Выполнить запрос POST /api/v1/auth/login с телом: {"login":"blocked_user@test.ru", "password":"Wrong1"}.
2. Повторить шаг 1 с паролями Wrong2, Wrong3, Wrong4, Wrong5 с интервалом ≤ 2 минуты между запросами.
3. Выполнить запрос POST /api/v1/auth/login с телом: {"login":"blocked_user@test.ru", "password":"CorrectPass1!"}.
4. Выждать 16 минут (до 14:16:00).
5. Повторить шаг 3.

Ожидаемые результаты:
— После шага 1–4: HTTP-статус 401, тело ответа содержит "error": "Invalid credentials". Счётчик неудачных попыток увеличивается на 1 при каждом запросе.
— После шага 2 (5-я попытка): HTTP-статус 403, тело ответа содержит "error": "Account locked due to excessive login attempts".
— После шага 3: HTTP-статус 403, тело ответа — то же сообщение об ошибке.
— После шага 5: HTTP-статус 200, тело содержит JWT-токен. Счётчик сброшен в 0.

Постусловия:
— Состояние аккаунта blocked_user@test.ru — активен.
— В аудит-логе зафиксированы 5 событий AUTH_FAILED и 1 событие AUTH_SUCCESS.
— Временные файлы сессии удалены.

Автор: Иванов А.В.
Дата создания: 2025-10-15
Версия продукта: ≥ 3.1.0

---

Шаблон: Defect Report (фрагмент — раздел «Анализ»)

Цель: показать техническую глубину без избыточного драматизма.

Анализ:
Дефект воспроизводится стабильно при использовании PostgreSQL 15.4 и отсутствует на PostgreSQL 14.10. В логах приложения зафиксировано исключение:
org.postgresql.util.PSQLException: ERROR: column "created_at" does not exist

Запрос, вызывающий ошибку:

SELECT id, status, created_at FROM payment_orders WHERE user_id = ? ORDER BY created_at DESC  

Сравнение DDL таблицы payment_orders:
— Версия 2.8.0 (production): столбец created_at TIMESTAMP NOT NULL DEFAULT NOW()
— Версия 3.1.9 (staging): столбец отсутствует; дата создания хранится в metadata::JSONB->>'created'

Причина: миграция БД V3_1__rename_created_column.sql удалена из сборки #2044 по ошибке при слиянии веток (commit a1b2c3d отменён без проверки зависимостей).

Рекомендуемое решение:
— Восстановить миграцию V3_1__rename_created_column.sql в ветку release/3.1.x;
— Добавить проверку наличия столбца в health-check сервиса перед запуском.

---

Эволюция артефактов в различных методологиях

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

Waterfall и регулируемые проекты

В последовательных моделях (например, при разработке МИС по ГОСТ Р ИСО/МЭК 12207) артефакты создаются по принципу «сначала документ — потом действие».
— Test Strategy и Test Plan утверждаются до начала кодирования.
— Test Design Specification разрабатывается параллельно с техническим заданием — до написания первой строчки кода.
— Все тест-кейсы проходят формальное согласование (sign-off) перед выполнением.
— Изменения в артефактах требуют процедуры change request: подачи запроса, оценки влияния, повторного утверждения.

Преимущество: полная прослеживаемость и соответствие требованиям аудита.
Риск: жёсткость — при изменении требований стоимость корректировки артефактов экспоненциально возрастает.

Agile (Scrum / Kanban)

В гибких методологиях артефакты адаптируются, но не исчезают. Акцент смещается с документирования ради документирования на документирование ради коммуникации и контроля.
— Test Strategy создаётся один раз на продукт и обновляется раз в квартал («Living Document»).
— Test Plan заменяется на тестовую часть sprint backlog: цели тестирования формулируются в начале спринта, ресурсы — в daily-планировании.
— Test Design Specification часто интегрируется в definition of ready для user story: условие готовности — наличие тестовых условий и методов покрытия.
— Test Case Specification создаётся «just-in-time» — перед началом тестирования итерации; автоматизированные тесты становятся исполняемой спецификацией (Specification by Example).
— Test Summary Report заменяется на итоговый блок daily-митинга или раздел в sprint review: «Тестирование завершено: 32 из 35 тестов пройдено, 3 дефекта critical в работе, релизный кандидат готов к демонстрации».

Ключевое отличие: артефакты живут в инструменте (Jira, Azure DevOps), а не в отдельных файлах. Ссылка на тест-кейс — это номер задачи; статус дефекта — это workflow в трекере.

DevOps и Continuous Testing

В средах с высокой частотой релизов (multiple deploys per day) акцент смещается на артефакты как код:
— Тест-планы выражаются в виде pipeline-конфигураций (.gitlab-ci.yml, azure-pipelines.yml): этапы, зависимости, условия запуска — это формализованный план.
— Тест-дизайн фиксируется в спецификациях BDD (Gherkin): Feature, Scenario, Given/When/Then — это и есть Test Design + Test Case в одном.
— Test Log генерируется автоматически CI-системой и хранится в ELK-стеке или Grafana.
— Defect Report создаётся автоматически при падении теста: интеграция с Sentry или Jira через webhook.
— Test Summary Report заменяется на дашборды качества: процент прохождения тестов, MTTR для failed-билдов, тренды покрытия кода.

Здесь артефакты перестают быть «документами» в классическом понимании и становятся элементами инфраструктуры как кода.

---

Типичные системные ошибки и их профилактика

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

Ошибка	Причина	Последствие	Профилактика
Нет прослеживаемости между дефектом и требованием	Требования не имеют уникальных ID; тестировщики не обучены работе с RTM	Невозможно оценить, какие бизнес-функции под угрозой; рост escape defects	— Внедрение сквозной нумерации требований (например, REQ-MODULE-NNN) — Обязательное поле «Связанные требования» в форме создания дефекта — Автоматическая проверка в CI: если дефект не привязан к requirement — билд помечается как unstable
Тест-кейсы не обновляются при изменении функционала	Отсутствие процесса impact analysis; ответственность не распределена	Выполнение устаревших тестов → ложные failures или пропуск дефектов	— Включение в definition of done: «Все затронутые тест-кейсы актуализированы» — Регулярный аудит покрытия (например, ежеквартально — проверка 10 % случайных кейсов на актуальность) — Использование статического анализа: если изменён метод calculateTax(), система предлагает пересмотреть все тесты, ссылающиеся на него
Test Summary Report содержит только метрики без интерпретации	Отчёт составляется формально, «для галочки»	Руководство не может принять решение; риски игнорируются до инцидента	— Шаблон отчёта включает обязательные разделы: «Ключевые риски», «Рекомендации», «План по устранению дефицитов» — Утверждение отчёта — совместное действие QA Lead и Product Owner
Артефакты хранятся в несистемном виде (локальные файлы, почта)	Отсутствие централизованного репозитория; недостаток бюджета на инструменты	Потеря знаний при смене сотрудника; невозможность аудита	— Использование open-source решений (Wiki.js + PostgreSQL для хранения артефактов) — Регламент: все артефакты после утверждения помещаются в общедоступный репозиторий (например, /docs/qa/artifacts/release-2025.11/)

---