Системный аналитик
80 задач, из них 3 на код с автопроверкой. Условие и варианты ответа открыты всем; проверка, подсказка и разбор — в клубе.
Требования и документация
- Требование к времени отклика каталога: к какому типу его отнести в SRS
- Какой критерий приёмки можно проверить на демо
- Заказчик просит кнопку выгрузки в Excel: потребность или готовое решение
- Два подразделения требуют взаимоисключающего поведения формы заявки
- Как переписать требование «система должна быть отказоустойчивой»
- На UAT заказчик просит поведение, которого нет в согласованных требованиях
- Смежная команда делает поле обязательным: с чего начать анализ влияния
- Среднее время ответа укладывается в SLA, но пользователи жалуются на зависания
Моделирование в BPMN и UML
- Какая диаграмма покажет порядок вызовов между тремя системами
- Как исполняется эксклюзивный шлюз BPMN с двумя исходящими потоками
- Что означает вынесение партнёра в отдельный пул на BPMN-схеме
- Поток управления протянут из нашего пула в пул банка
- Как отразить публикацию события в брокер на sequence-диаграмме
- Внешний скоринг может не ответить за 30 секунд: как показать это в BPMN
- Схема To-Be на 70 элементов, которую не согласовывает ни бизнес, ни разработка
- Цепочка из четырёх синхронных вызовов и таймаут мобильного клиента
SQL и модель данных
- Сколько строк вернёт JOIN заказа с тремя позициями
- Чем COUNT(*) отличается от COUNT(колонки) при пустых значениях
- Как связать заказы и товары в схеме, если связь многие-ко-многим
- Почему условие с SUM в WHERE не выполняется
- LEFT JOIN перестал возвращать клиентов без заказов
- Заявки с незаполненным статусом не попали в отчёт
- Индекс по дате создан, но отчёт по дню по-прежнему сканирует всю таблицу
- Количество строк после миграции совпало, но данные всё равно повреждены
API и интеграции
- Какой ответ вернуть, если заказа с таким идентификатором нет
- Формат даты и времени в JSON-контракте между тремя системами
- Отмена заказа реализована через GET: чем это опасно
- Повтор запроса после таймаута привёл к двойному списанию
- События по одному заказу приходят потребителю не в том порядке
- Какое изменение REST-контракта сломает существующих потребителей
- Деньги списаны, а заказ не создан: что описать в требованиях
- Постраничная выгрузка справочника теряет и дублирует записи
Асинхронные интеграции: Kafka и RabbitMQ
- Оформление заказа ждёт 8 секунд, пока провайдер отправит SMS
- Три системы читают одну очередь RabbitMQ, и каждая получает только часть оплат
- Новому сервису аналитики нужны события заказов за последние две недели
- Сервис заказов публикует «SendWelcomeEmail» и «ReserveStock» в общий топик
- После каждого события «клиент изменён» двенадцать систем идут в CRM за данными
- Одно битое сообщение остановило обработку двух миллионов событий
- Потребителей увеличили с 6 до 12, а отставание от топика не сократилось
- Сервис начисления бонусов падал при деплое, и часть начислений пропала
- Баланс бонусов при повторной доставке событий
- Заказ сохранён в базе, а событие о нём так и не дошло до склада
- Никто не может сказать, на каком шаге застрял заказ из цепочки шести событий
- После переименования группы потребителей клиенты получили 300 тысяч старых SMS
Контракты API: OpenAPI, ошибки и маппинг данных
- Банк присылает middleName: null, и валидатор отклоняет 3% заявок
- После создания заказа клиенту приходится искать его номер в списке
- Какой код вернуть на регистрацию с уже занятым email
- Суммы в контракте переданы дробными числами, и сверка с партнёром не сходится на копейки
- Четыре эндпоинта возвращают ошибки в четырёх разных форматах
- Партнёр добавил в ответ поле loyaltyLevel, и наша интеграция упала
- В запрос оплаты приходят карты без токена и счета без ИНН
- Выгрузка двух миллионов операций для бухгалтерии не укладывается в таймаут шлюза
- Проверка тела запроса по упрощённому контракту
- PATCH с одним полем email стёр у клиента телефон и адрес
- Два оператора редактировали карточку клиента, и изменение лимита пропало
- Маппинг карточки клиента из старой АБС в новый контракт
Микросервисы и декомпозиция монолита
- Команда доставки переименовала колонку, и упал сервис заказов
- Сущность «Клиент» разрослась до 140 полей, и каждое изменение согласуют пять команд
- Смена адреса одного сервиса требует выпуска мобильного приложения
- Оформление заказа синхронно зависит от трёх сервисов с доступностью 99,9%
- План: полтора года переписывать монолит, потом переключиться за одну ночь
- Для отчёта директору разработчик хочет подключиться к базам трёх сервисов
- Сервисы «доступ к БД», «валидация» и «генерация PDF» на всю систему
- Каждый релиз требует выкатить пять сервисов в строгом порядке за один вечер
- Клиентка сменила фамилию: обновлять ли её в заказах прошлого года
- Карточка клиента собирается из пятнадцати вызовов к четырём сервисам
- Сбой каталога остановил продажи, хотя цены меняются раз в сутки
- Медленные рекомендации роняют всю страницу товара
User Story, Use Case и критерии приёмки
- Какая из историй бэклога службы доставки оформлена полноценно
- «Как разработчик, я хочу добавить индекс на таблицу заказов»
- Как разложить критерий про промокод на Дано, Когда, Тогда
- Где в use case «Оплатить заказ картой» описать отказ банка
- Эпик «Оплата бонусами» разбили на истории «бэкенд», «фронтенд» и «миграция БД»
- Тестировщик и разработчик спорят, положена ли скидка заказу ровно на 3 000 ₽
- История про выдачу займа переезжает в следующий спринт третий раз подряд
- Авторизация и промокод на диаграмме вариантов использования
- После редизайна упали все сценарии приёмки, хотя поведение не менялось
- Тридцать историй про кредитную заявку противоречат друг другу
- Отменить заказ «до отгрузки» стало невозможно уже через пять минут после оплаты
- Какие примеры включить в Scenario Outline для правила бесплатной доставки