Системный анализ: вопросы для собеседования QA

Артефакт — любой документ или модель, который остаётся как результат работы и используется другими ролями: BRD, SRS, user stories с AC, BPMN-диаграммы, Sequence, ERD, контракты API (OpenAPI), глоссарий, decision log.

Какие именно — зависит от методологии и проекта. В Agile-команде продукта чаще всего: user stories с AC, sequence-диаграммы интеграций, OpenAPI, краткие тех. спецификации. В госпроекте — полный комплект по ГОСТ.

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

Разные артефакты — разные потребители. BRD — спонсор и бизнес. SRS/user stories — разработчики и тестировщики. Sequence/OpenAPI — backend/интегратор. UI-спеки — дизайнер и фронт. Глоссарий — все. Decision log — будущие участники проекта.

Хороший аналитик пишет каждый артефакт для конкретной аудитории и в нужном для неё языке. Универсальный документ часто не нужен никому.

Из практики: перед написанием нового документа спрашиваю «кто его прочитает в течение месяца?». Если ответа нет — не пишу.

Минимум: участники и направление вызова, протокол и метод, контракт (схема запроса/ответа, OpenAPI/JSON Schema/WSDL), сценарии (включая ошибки и таймауты), аутентификация и авторизация, идемпотентность, гарантии доставки, нефункциональные требования (latency, throughput), SLA.

Дополнительно: формат идентификаторов, retry-политика, обработка дубликатов, логирование и трассировка, обратная совместимость, версионирование.

Из практики: 70% багов на интеграциях — в недописанном поведении при ошибках. Описывайте error-сценарии так же подробно, как happy path.

Impact-анализ — оценка последствий предлагаемого изменения: какие требования, модули, интеграции, данные, процессы и пользователи будут затронуты. Дополняется оценкой трудозатрат и рисков.

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

Из практики: качественный impact-анализ невозможен без traceability matrix. С ней — 30 минут. Без — неделя ручного поиска зависимостей.

BPMN — бизнес-процессы. UML — модели ПО (структура, поведение, взаимодействие). ER/IDEF1X — модели данных. DFD — потоки данных. C4 — архитектура. ArchiMate — корпоративная архитектура.

Выбор нотации зависит от аудитории. BPMN читает бизнес, UML Sequence — разработчики, C4 — архитекторы и менеджеры. Нет «самой правильной» нотации.

Из практики: на одном проекте редко обходится одной нотацией. AS-IS процесса — BPMN, интеграция — Sequence, данные — ERD.

Категории элементов: Flow Objects (события, активности, шлюзы), Connecting Objects (поток управления, поток сообщений, ассоциации), Swimlanes (Pool, Lane), Artifacts (data object, group, аннотация).

Минимально достаточный набор для 80% диаграмм: Start/End event, Task, Gateway (XOR/AND), Sequence Flow, Lane. Этого хватает, чтобы описать большинство бизнес-процессов читаемо.

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

XOR (exclusive) — ровно одна ветка по условию. AND (parallel) — все ветки параллельно и схождение ждёт все. OR (inclusive) — одна или несколько веток по условиям, схождение ждёт активированные. Event-based — выбор по первому пришедшему событию (таймер/сообщение). Complex — нестандартные условия.

Самые используемые — XOR и AND. OR-схождение коварно: разработчику нужно реализовать «дождись только активированных», что не всегда тривиально.

Из практики: 90% бизнес-логики покрывается XOR и AND. Event-based удобен для моделирования таймаутов («ждём ответа клиента 24 часа, иначе...»).

По позиции: Start (тонкая граница), Intermediate (двойная граница), End (толстая граница). По типу триггера: None, Message, Timer, Signal, Error, Conditional, Compensation, Escalation, Cancel, Terminate, Link.

Промежуточные события бывают двух поведений: catching (ловит) и throwing (бросает). Например, Intermediate Message Throwing отправляет сообщение, Catching — ждёт.

Из практики: Terminate End — единственный способ принудительно остановить весь процесс. Обычный End завершает только свою ветку.

Pool — отдельный участник процесса (организация, система, внешний сервис). Pool'ы общаются только через message flow, не sequence flow.

Lane — подразделение внутри Pool: отдел, роль, система-компонент. Внутри Pool связи идут sequence flow.

Из практики: правило «один Pool — один процесс». Если у вас 5 Pool'ов с равноправными процессами, скорее всего нужно разделить на 5 диаграмм с явной интеграцией.

Две категории: структурные (Class, Object, Component, Composite Structure, Package, Deployment, Profile) и поведенческие (Use Case, Activity, State Machine, Sequence, Communication, Timing, Interaction Overview).

Самые ходовые: Class (модель домена), Sequence (взаимодействие во времени), State Machine (поведение объекта), Use Case (функциональные требования верхнего уровня), Activity (процесс/алгоритм).

Из практики: в Agile-проектах UML используют выборочно — обычно Sequence для интеграций и Class для домена. Полный набор UML — это редкая практика крупных регулируемых проектов.

Use Case Diagram — диаграмма поведения, показывающая, какие сценарии система выполняет для разных типов пользователей. Высокоуровневый взгляд на функциональность.

Элементы: акторы (человек/система/таймер), use cases (овалы), системные границы (прямоугольник), отношения (association, include, extend, generalization).

Из практики: ценность не в самой диаграмме, а в обсуждении при её создании. После согласования use cases раскрываются в текстовые спецификации или user stories.

<<include>> — базовый use case ВСЕГДА включает другой. «Оформить заказ» include «Аутентификация» — без аутентификации заказ не оформляется. Стрелка идёт от базового к включаемому.

<<extend>> — расширяющий use case ИНОГДА добавляется к базовому по условию. «Оформить заказ» extend «Применить промокод» — промокод опционален. Стрелка идёт от расширяющего к базовому (с extension point).

Из практики: путают чаще всего направление стрелки. Запоминание: include — «нужен», стрелка показывает, что нужно; extend — «дополняет», стрелка указывает, кого дополняет.

alt — альтернатива (if/else); opt — опционально (выполняется при условии); loop — цикл; par — параллельные ветки; ref — ссылка на другую диаграмму; break — выход из цикла; critical — атомарная секция; neg — недопустимое поведение.

Самые ходовые — alt, opt, loop, par, ref. Остальные нужны редко и часто заменяются обычным текстовым комментарием.

Из практики: чрезмерное вложение alt/loop делает Sequence нечитаемой. Если глубина > 2, лучше разбить на несколько диаграмм через ref.

State Machine — диаграмма, описывающая жизненный цикл объекта: возможные состояния и переходы между ними по событиям с условиями (guards) и действиями (actions).

Использую, когда у сущности есть явные состояния с правилами переходов: заказ (создан → оплачен → отгружен → доставлен), заявка, документ, тикет. Сразу видны «дыры» и недопустимые переходы.

Из практики: state machine — лучший союзник тестировщика. Каждый переход = тест-кейс, каждое запрещённое сочетание = негативный тест.

Activity Diagram (UML) — поведенческая диаграмма для описания потока действий: активности, решения, разделение/слияние потоков, swimlane'ы. Похожа на BPMN, но из мира UML.

Отличия от BPMN: BPMN богаче на типы событий и шлюзов, заточен под бизнес и стандарт OMG. Activity — общая нотация UML, проще, но менее выразительна для бизнес-процессов с межсистемными взаимодействиями.

Из практики: бизнес-процесс — BPMN. Алгоритм внутри одного компонента — Activity. Не наоборот.

Class Diagram (UML) — модель объектов кода: классы, методы, поведение, наследование, полиморфизм. Описывает «как живёт» предметная область в коде.

ER-диаграмма — модель данных в БД: сущности, атрибуты, связи (1:1, 1:N, N:M), ключи. Не описывает поведение и наследование.

Из практики: Class и ER часто похожи на уровне сущностей, но разные по содержанию. У класса есть поведение и наследование; у entity — атрибуты и связи. Поэтому Class для домена, ER для физической модели БД.

DFD — диаграмма потоков данных: показывает, как данные движутся между процессами, хранилищами и внешними сущностями. Не описывает время и порядок.

Элементы: внешние сущности (квадрат), процессы (круг/прямоугольник со скруглением), хранилища (две линии), потоки данных (стрелки с подписями).

Из практики: DFD удобна для верхнего уровня архитектуры данных — понять, что куда течёт. Для логики порядка операций — нужна BPMN или Sequence.

C4 (Simon Brown) — модель архитектуры на 4 уровнях абстракции: Context (система и её соседи), Container (приложения, БД, сервисы внутри системы), Component (модули внутри контейнера), Code (классы и связи).

На практике обычно делают только первые два уровня — Context и Container. Component нужен редко, Code почти никогда (его уже даёт IDE).

Из практики: C4 хорош тем, что одни и те же блоки на разных уровнях, у разной аудитории. Спонсору — Context, разработчику — Container/Component.

ArchiMate — стандарт нотации для описания корпоративной архитектуры (Enterprise Architecture) в 3 слоях: Business (процессы/роли), Application (приложения/сервисы), Technology (инфраструктура). Есть расширения Motivation, Strategy, Physical.

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

Из практики: ArchiMate избыточен для одного продукта. Это инструмент архитектора предприятия, не разработчика.

Маппинг данных — описание соответствия полей между двумя структурами: источник (например, исходная система или внешний контракт) и приёмник (БД целевой системы). Включает имена полей, типы, преобразования, обработку отсутствующих/невалидных значений.

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

Из практики: 80% багов на интеграции — в маппинге, особенно в преобразованиях форматов (даты, валюты, пробелы).

Инициация — формулировка цели, бизнес-кейс, scope. Анализ — выявление требований, моделирование, ТЗ. Проектирование — участие в архитектуре, контракты API, схема данных. Разработка — поддержка команды, уточнения, мини-демо. Тестирование — приёмка с бизнесом, поддержка QA. Внедрение — обучение, миграция, готовность данных. Эксплуатация — анализ инцидентов, изменения, развитие.

Аналитик — «переводчик» между бизнесом и командой на всех этапах, а не «исчезает» после ТЗ.

Из практики: главный антипаттерн — «написал ТЗ и ушёл». Хороший аналитик присутствует на всех этапах, иначе требования теряют контакт с реальностью.

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

Опционален / поддерживающая роль: дизайн UI, кодирование, написание тестов, инфраструктура, эксплуатация. Здесь аналитик помогает контекстом и решениями, но не ведёт работу.

Из практики: в маленькой команде аналитик закрывает и продуктовые, и проектные роли. В больших — фокусируется на «своей» части и выходит из чужих.

С тестировщиками — общий язык AC и пограничных случаев. Аналитик пишет проверяемые AC, QA — тест-кейсы. Ревью требований до начала разработки помогает поймать «дыры» до кода.

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

Из практики: с дизайнерами аналитик согласует логику и состояния (валидации, ошибки, пустые состояния). Дизайнер делает форму, аналитик — поведение. Без совместной работы получается «красивая нерабочая форма».

Декомпозиция: сверху вниз — от бизнес-задачи к функциональным блокам, дальше к user stories с AC. Каждая story помещается в спринт. Сплит — по сценариям/вертикалям, не по слоям.

Оценка: для крупных инициатив — t-shirt size (S/M/L/XL) или story-points с эталоном. Для конкретных задач в спринте — planning poker. Я как аналитик не ставлю оценку команде, но помогаю формулировать так, чтобы её можно было оценить.

Из практики: главное в декомпозиции — каждая задача должна быть проверяемой и приносить пользу. «Завести модель в БД» — не задача, «реализовать поиск клиента по фамилии» — да.

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

Для общей оценки задачи провожу с командой совместный разбор: декомпозиция, обсуждение рисков, planning poker для крупных кусков. Свожу к диапазону «оптимистично — реалистично — пессимистично».

Из практики: чем больше неизвестных — тем шире диапазон. Если разница опт/песс «в 5 раз» — значит, нужно сначала прояснить, а не оценивать.

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

Технически — знает домен, умеет моделировать, работает с данными и интеграциями. По soft-skills — слушает больше, чем говорит; задаёт правильные вопросы; не боится сказать «не знаю» и пойти разобраться.

Из практики: лучшие аналитики — не «писатели ТЗ», а «переводчики». Они переводят бизнес в технику и обратно, и команда им доверяет в обе стороны.

Должен: выявление и формализация требований, моделирование процессов и данных, описание интеграций и контрактов, работа с НФТ, импакт-анализ изменений, поддержка команды разработки и QA контекстом.

Не должен: писать код в продакшен, ставить задачи команде (это PO/PM), писать тест-кейсы (это QA), рисовать UI-дизайн (это дизайнер), управлять командой (это team lead).

Из практики: размытие ролей в маленьких командах часто превращает аналитика в «delivery manager». Это работает временно, но в долгую — путь к выгоранию.