Модуль 12.2. Тестовые задания системного аналитика
Типовые кейсы: API-контракт, BPMN, ER, NFR + критерии проверки. Для каждого — чек-лист оценивания, примеры решений, типовые ошибки. В конце — «вопрос-ответ».
Зачем модуль и как им пользоваться
Этот модуль — готовый пакет тестовых для оценки SA на уровнях junior/middle/senior. Он закрывает четыре оси компетенций:
Поведение (BPMN) → Данные (ER/словари) → Интеграции (API/события) → Качество (NFR/наблюдаемость).
Каждый кейс содержит: бриф, ожидаемые артефакты, критерии и типичные анти-паттерны.
Формат для кандидата: «docs-as-code» (файлы в репозитории/архиве). Формат для проверяющего: рубрика (баллы) + «красные флаги».
Общие правила постановки и приёмки теста
Инструкция кандидату (вкладывается в задание)
- Срок: 24–48 ч календарных (или 3–4 часа чистого времени — укажите).
- Что сдавать: только перечисленные артефакты (без кода). Любая доп. гипотеза — явно помечена.
- Версионирование: добавляйте version, changelog.
- Ссылки внутри: взаимные ссылки между SRS/диаграммами/API/RTM.
- Прозрачность: если что-то приняли по допущению — впишите в Assumptions.
Структура папок (шаблон)
test/ README.md srs/assumptions.md bpmn/order_payment_delivery.bpmn api/openapi.yaml data/er_diagram.puml data/dictionary.md quality/nfr_catalog.md quality/observability.md rtm/rtm.csv
Рубрика уровней (что ожидаем)
- Junior: корректная нотация, понятные имена, измеримые NFR, базовые коды ошибок, простая ER с ключами.
- Middle: идемпотентность, пагинация курсором, async-ветви, boundary-события, DQ-пункты словаря, RTM.
- Senior: trade-off’ы/ADR, версия API/событий, DMN-врезки, SLI/SLO + план проверки, эволюция схем, отказоустойчивость.
Кейс A — API-контракт (REST + события)
Бриф
Нужно описать контракт API для сценария «Создать счёт → Оплатить → Получить статус», с асинхронным PSP. Клиента не устраивают дубликаты и «зависающие» статусы.
Ожидаемые артефакты
- OpenAPI 3.0+: /v1/invoices (POST/GET), /v1/payments (POST/GET/POST {id}/capture, POST {id}/refund).
- Ошибки: единый словарь (code, message, details).
- Идемпотентность: Idempotency-Key + поведение на повтор.
- Пагинация: cursor-based (ключ поля сортировки, стабильный порядок).
- Безопасность: OAuth2/JWT scopes (минимальный набор).
- События: описание 2–3 доменных событий (JSON Schema/Avro) — payment.captured.v1, refund.issued.v1 (минимальные поля + семантика версий).
Пример (фрагменты)
openapi: 3.0.3
info: { title: Billing API, version: 1.2.0 }
paths:
/v1/invoices:
post:
summary: Create invoice
parameters:
- in: header
name: Idempotency-Key
required: true
schema: { type: string, maxLength: 128 }
responses:
"201": { description: Created }
"409": { description: Duplicate key returns previous result }
"422": { description: Validation error }
/v1/payments:
post:
summary: Create payment
responses:
"201": { description: Authorized or Captured }
"202": { description: Accepted (async PSP) }
"409": { description: Duplicate }
"422": { description: Validation }
components:
securitySchemes:
oauth2:
type: oauth2
flows:
clientCredentials:
tokenUrl: https://auth/...
scopes: { payments:create: "Create payments", payments:read: "Read" }
Событие (JSON Schema, выдержка):
{
"title": "payment.captured.v1",
"type": "object",
"required": ["eventId","occurredAt","paymentId","invoiceId","amount","currency"],
"properties": {
"eventId": {"type":"string","format":"uuid"},
"occurredAt": {"type":"string","format":"date-time"},
"paymentId": {"type":"string","format":"uuid"},
"invoiceId": {"type":"string","format":"uuid"},
"amount": {"type":"string","pattern":"^[0-9]+(\\.[0-9]{2})$"},
"currency": {"type":"string","enum":["RUB","USD","EUR"]},
"correlationId": {"type":"string"}
}
}
Критерии проверки (баллы)
- Ресурсы/глаголы корректны (5)
- Идемпотентность и статус 202 для долгих операций (10)
- Пагинация курсором + стабильная сортировка (7)
- Ошибки: структ./коды/пример (8)
- Security (scopes), rate-limits, размеры (5)
- События: версия/минимализм/корреляция (5)
-
Версионирование API/депрекейшн-политика (5)
Итого: 45
Типовые ошибки
- 200 с текстом «обработка началась» вместо 202 + job/state.
- Идемпотентность описана словами, но нет ключа/реестра/поведения на повтор.
- «Вернём всё» пагинацией offset без сортировки → дырки/дубли.
- События «свободного формата» без схемы/версии.
- PII в событиях (email/телефон).
Кейс B — BPMN 2.0 (коллаборация)
Бриф
Нужно смоделировать To-Be процесс «Заказ → Оплата → Доставка» с асинхронным PSP и SLA доставки. Обязательны: Event-based gateway на ожидании результата платежа, Boundary timer на доставке, compensation на наклейке.
Ожидаемые артефакты
- Collaboration с пулами: Витрина/Checkout, Payments, Warehouse, Carrier, Customer.
- Boundary events: Timer на «Оплате» (таймаут PSP), Timer на «Доставке» (SLA breach), Error на «Печать этикетки».
- Multi-instance подпроцесс «Собрать посылки по OrderItems».
- Message flows для вебхуков payment.captured и tracking.updated.
- End Events: «Заказ завершён», «Заказ отменён».
Критерии проверки (баллы)
- Межсистемные вызовы — message flow, не sequence (6)
- Event-based gateway на платеже (8)
- Boundary timer и эскалация SLA (6)
- Compensation/откат (5)
- Нет висящих токенов, у XOR есть default (5)
-
Именование: глагол + объект, до 12 элементов на уровне (5)
Итого: 35
Типовые ошибки
- XOR вместо Event-based; отсутствие таймаутов.
- Sequence-переходы между пулами.
- Нет End-событий/«висящие» инстансы.
- Отсутствие альтернатив (decline/timeout).
Кейс C — ER-модель + словарь данных
Бриф
Смоделируйте данные для домена «Заказы–Клиенты–Платежи–Возвраты». Нужны: сущности, ключи, связи, обязательность, денежные типы, уникальность, бизнес-ключи для интеграций.
Ожидаемые артефакты
- ER-диаграмма (6–10 сущностей): Customer, Order, OrderItem, Payment, Refund, Shipment, Warehouse.
- Ключи: натуральные vs суррогатные, уникальные ограничения.
- Деньги: DECIMAL(18,2) + ISO4217; суммы в мин. единицах (обоснование).
- Словарь данных: атрибут, тип, обязательность, домен/справочник, DQ-правила (валидность/полнота/уникальность).
Критерии проверки (баллы)
- Корректные связи и кардинальности (8)
- Ключи и уникальность (натуральные/суррогатные) (6)
- Денежные поля и валютная модель (5)
- Обязательность и DQ-правила в словаре (6)
-
Бизнес-ключи для интеграций (ExternalId) (5)
Итого: 30
Типовые ошибки
- FLOAT для денег; отсутствие валютной поддержки.
- Отсутствие уникальности по (orderId, sku) в позициях.
- Нулевая/nullable семантика не описана.
- Нет ExternalId/таблицы маппинга.
Кейс D — NFR + наблюдаемость (SLO/SLI) + план проверки
Бриф
Определите NFR для эндпоинтов и процессов из кейсов A–B и опишите, как проверите их достижение (методика/инструмент/окно/порог).
Ожидаемые артефакты
- Каталог NFR: Latency (p95/p99), Availability, Error rate, Security, Audit, Capacity, Compliance, A11y (если UI).
- SLI/SLO таблица: метрика, цель, окно, как меряем (лог, трейсы, метрики).
- Нагрузочный план: профиль трафика, RPS, длительность, «нагрев/полка/остывание».
- Алерты: условия + действия (эскалация/фичефлаг/деградация).
- Observability: события/логи со схемой, traceId/correlationId, RED/USE.
Пример (фрагмент)
|
ID |
Область |
SLO |
Окно |
Метод проверки |
|---|---|---|---|---|
|
NFR-PERF-01 |
POST /v1/orders |
p95 ≤ 900 ms, p99 ≤ 1500 ms |
08:00–23:00 CET |
нагрузочный тест + SLI в прод-подобном стенде |
|
NFR-AVAIL-01 |
Payments API |
≥ 99.9% успешных за месяц |
Календарный месяц |
SLO-дашборд |
|
NFR-OBS-01 |
Логи |
JSON, поле traceId, маскирование PII |
Всегда |
инспекция + автомат. тест |
Критерии проверки (баллы)
- NFR измеримы (метрика+окно+метод) (6)
- SLI/SLO оформлены, привязка к системам мониторинга (6)
- Нагрузочный план реалистичен (профиль) (5)
- План деградации/фичефлаг/откат (4)
-
Безопасность логов/PII (3)
Итого: 24
Типовые ошибки
- «Быстро/надёжно» без цифр.
- p95 без окон/условий.
- Нет способа проверки (как измерим?).
- Логи без схемы/маскирования.
Суммарное оценивание (пример веса)
- Кейс A (API): 45
- Кейс B (BPMN): 35
- Кейс C (ER+словарь): 30
- Кейс D (NFR/SLI/SLO): 24
-
Бонусы: RTM, ADR/DR, DMN, версионирование схем — до +10
Максимум: 144 + 10
Junior — 60–85; Middle — 86–115; Senior — 116+ (ориентиры, адаптируйте под свою шкалу).
Чек-лист для проверяющего (быстрый просмотр)
- Ясные Assumptions и границы.
- Согласованность терминов между BPMN/API/ER.
- Идемпотентность/асинхрон отражены и в API, и в BPMN.
- Бизнес-ключи и ExternalId пригодны для интеграций.
- NFR не «вода», привязаны к метрикам и методам.
- Есть RTM (хотя бы минимальный CSV) и CHANGELOG.
- В событиях — минимум PII.
- Диаграммы читабельны (≤ ~12 элементов на уровень).
Красные флаги:
- 500 «на всё», отсутствие 202; нет Default Flow; sequence между пулами; деньги FLOAT; нет уникальности; «SLA быстро»; события без схемы/версии.
Примеры мини-решений (как должно выглядеть «вкратце»)
API (идея)
- POST /v1/payments → 201/202; заголовки Idempotency-Key, X-Correlation-Id.
- События: payment.captured.v1 (минимум полей).
- Ошибки: AMOUNT_TOO_SMALL (422), DUPLICATE (409), PSP_TIMEOUT (202).
- Пагинация: /v1/payments?cursor=…&limit=100 (cursor = base64(lastId, createdAt)).
BPMN (идея)
- Event-based gateway (Message vs Timer).
- Boundary timer на «Доставка», ветка «Эскалация/компенсация».
- Compensation на «Печать этикетки».
ER (идея)
- Order( orderId PK, customerId, status, total DECIMAL(18,2), currency )
- OrderItem( orderItemId PK, orderId FK, sku, qty, unitPrice, UNIQUE(orderId, sku) )
- Payment( paymentId PK, orderId FK, amount, currency, status )
- В словаре: обязательность/домены/справочники/валидации.
NFR/SLI (идея)
- POST /orders: p95 ≤ 900 ms, 08–23, EU/Stockholm; метод — нагрузочный тест + метрики.
- Наблюдаемость: JSON-логи c traceId, OpenTelemetry трассы, RED-метрики.
Риски при выдаче теста и как их гасить
|
Риск |
Проявление |
Митигирующие меры |
|---|---|---|
|
Туманная постановка |
«Додумал не туда» |
Дайте «Assumptions.md» с примерами допустимых допущений |
|
Слишком большой объём |
Не успевает |
Предложите «обязательный минимум» + бонусы |
|
Плагиат/«копипаста» |
Без адаптации |
Ставьте доменные нюансы, просите устную защиту 10–15 мин |
|
Перегруженные диаграммы |
«Обои» |
Ограничение на элементы/уровень, требование подпроцессов |
|
Не сравнил альтернативы |
Решение «по вкусу» |
Попросите 1–2 ADR/DR (контекст-варианты-решение) |
Доп. задания (для старших уровней)
- RTM: CSV «REQ → AC/BDD → API/Events → Tests → Metrics».
- DMN: таблица SLA доставки (hit policy F).
- События: политика версионирования (semver, additive-only, deprecation).
- DWH/BI: CDC описание, MERGE дедуп (одним SQL-фрагментом).
- Security: ABAC матрица (кто что может).
Вопрос–Ответ
В: Можно ли сдавать диаграммы скриншотами?
О: Да, но приложите исходники (BPMN XML/PlantUML) для ревью.
В: Нужны ли ссылки на стандарты и термины?
О: Желательно. В глоссарии пропишите термины (Order/Invoice/Payment) и дайте ссылки на разделы SRS.
В: Что считать «правильной» идемпотентностью?
О: Ключ на создающих операциях (Idempotency-Key), реестр на стороне сервиса, тот же ответ при повторе, уникальные индексы в БД; описать TTL/границы.
В: Как обосновать выбор offset vs cursor?
О: Cursor для изменяемых наборов и больших объёмов (нет «дыр» и «дублей»); offset — только для стабильных/малых наборов. Приведите критерии.
В: Обязательно ли делать DMN?
О: Нет, но DMN-фрагмент в кейсе со SLA/скидками — плюс к оценке (senior-поведение).
В: Как показать, что NFR выполнимы?
О: Дайте метод верификации: сценарий нагрузки, как меряем SLI, как алертим нарушения, какой fallback (деградация/фичефлаг).
Шпаргалка кандидату
- Всегда пишите Assumptions и ограничения.
- Имена = глагол+объект, данные = тип+домен.
- На каждом уровне думайте об идемпотентности и асинхронности.
- NFR = метрика + окно + метод.
- Диаграмма = одна идея, остальное в подпроцессы.
- PII минимизируйте; события — только минимальный payload.
- Делайте CHANGELOG и указывайте версии артефактов.
