✅ Почему вариант C (адаптер) — хороший выбор:
Паттерн адаптер (или API gateway для интеграций) предполагает:
Внутренняя система (магазин) работает в своём внутреннем формате
Адаптер получает данные от магазина, преобразует их в формат каждого маркетплейса и отправляет через их API
При добавлении нового маркетплейса нужно написать только новый адаптер, не меняя код магазина
Это снижает связанность (магазин не зависит от форматов маркетплейсов) и упрощает расширение.
✅/ ❌ Почему вариант D (ESB с канонической моделью) — ещё лучше, но сложнее:
ESB (Enterprise Service Bus) — это более мощный, но и более сложный вариант. Вводится единая каноническая модель данных (например, универсальный формат товара, понятный внутри компании). Все системы преобразуют свои данные в каноническую модель и обратно. Это идеально для большого количества систем, но требует серьёзной инфраструктуры.
Для 3-4 маркетплейсов вариант C проще и быстрее. Для десятков — D.
❌ Почему другие варианты плохи:
A (Точка-точка): Классический спагетти-код интеграций. Каждая новая связь требует изменений и в магазине, и в адаптере. При росте числа маркетплейсов сложность растёт экспоненциально. Трудно поддерживать и тестировать.
B (Единая база данных): Предоставление доступа к своей БД внешним системам — антипаттерн. Это нарушает безопасность, инкапсуляцию, создаёт зависимость от схемы данных. Маркетплейсы не смогут работать с вашей внутренней схемой напрямую.
Совет: Для такой задачи аналитик должен:
Определить внутреннюю модель данных товара (каноническую для компании)
Для каждого маркетплейса описать правила маппинга из внутренней модели в их формат
Специфицировать адаптер как отдельный компонент, который будет выполнять это преобразование и управлять вызовами API
Учесть обработку ошибок, повторные попытки, логирование
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
4715. User story: смена пароля. Какие критерии приёмки сделают её проверяемой?
Anonymous Quiz
6%
Поле обязательно, кнопка работает, есть сообщение.
4%
Пароль безопасный, приходит уведомление.
90%
1. Длина ≥8, цифра и заглавная. 2. Приходит email. 3. Старый пароль не работает.
0%
Как в других банковских приложениях
❌ A: слишком размыто («работает», «сообщение» — какое?).
❌ B: отсылка к неопределённой «политике безопасности», не проверяемо.
❌ D: субъективно, невозможно проверить объективно.
Please open Telegram to view this post
VIEW IN TELEGRAM
4716. Логика скидок:
сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
Anonymous Quiz
12%
Эквивалентное разделение
40%
Таблица решений
11%
Попарное тестирование
37%
Анализ граничных значений
❌ A: эквивалентное разделение не учитывает комбинации условий.
❌ C: попарное тестирование избыточно для двух параметров и не даёт такой наглядности.
❌ D: анализ граничных значений полезен для чисел, но не проверяет комбинации условий.
Please open Telegram to view this post
VIEW IN TELEGRAM
4717. Тестировщик нашёл: система позволяет записаться на уже занятое время. Разработчик: «Так в ТЗ — сначала выбор, потом проверка». Ваши действия?
Anonymous Quiz
2%
Согласиться с разработчиком.
75%
Уточнить у заказчика ожидаемое поведение, при необходимости скорректировать ТЗ.
1%
Закрыть баг как «не баг».
23%
Предложить добавить валидацию на фронтенде.
❌ A: слепое следование ТЗ может привести к плохому UX.
❌ C: закрытие база без анализа игнорирует потенциальную проблему.
❌ D: техническое решение без проработки требований может не соответствовать бизнес-логике.
Please open Telegram to view this post
VIEW IN TELEGRAM
4718. Для интеграционного тестирования микросервисов нужны тестовые данные. Что сделает аналитик?
Anonymous Quiz
1%
Даст доступ к production-базе.
6%
Напишет сценарии тестирования.
92%
Подготовит документацию с примерами данных, форматами и скриптами генерации по бизнес-правилам.
1%
Попросит разработчиков написать юнит-тесты.
❌ A: доступ к production нарушает безопасность и законы о персональных данных.
❌ B: написание сценариев — задача тестировщика.
❌ D: юнит-тесты не решают проблему интеграционных данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
4719. Найден критический баг, разработчик исправил, но тестировщик не может воспроизвести. Что делать аналитику?
Anonymous Quiz
1%
Закрыть как невоспроизводимый.
12%
Попросить разработчика описать условия.
86%
Организовать встречу,где разработчик покажет условия, а аналитик зафиксирует неточности тестировщику
0%
Передать тимлиду.
❌ A: закрытие база оставляет риск повторения на проде.
❌ B: устное описание часто неполно; показ точнее.
❌ D: перекладывание ответственности не решает проблему.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1
4720. Вы проектируете базу данных для магазина. В одной таблице Orders вы планируете хранить: order_id, customer_name, customer_phone, product_id, product_name, product_price, quantity, order_date. Какая проблема скорее всего возникнет при таком дизайне?
Anonymous Quiz
4%
Невозможность быстрого поиска по дате
80%
Избыточность данных и аномалии обновления
13%
Отсутствие первичного ключа
3%
Медленная вставка новых записей
Аномалии обновления: если клиент сменил телефон, придётся обновлять все его заказы.
Аномалии вставки: нельзя добавить нового клиента без заказа.
Аномалии удаления: при удалении последнего заказа потеряется информация о клиенте.
❌ A: Поиск по дате можно ускорить индексом, это не главная проблема.
❌ C: Первичный ключ (order_id) есть, его можно добавить.
❌ D: Вставка может быть не медленной, а вот обновления — да.
Вывод: Правильное проектирование требует выделения сущностей (Клиенты, Товары, Заказы) в отдельные таблицы и установления связей между ними.
Please open Telegram to view this post
VIEW IN TELEGRAM
4721. В банковской системе выполняется перевод средств со счёта A на счёт B. Операция состоит из двух шагов: списание с A и зачисление на B. После списания, но до зачисления - сбой. Какое свойство транзакции нарушено,и каким механизмом оно обеспечивается?
Anonymous Quiz
28%
Согласованность (Consistency) — через триггеры
12%
Изоляция (Isolation) — через блокировки
58%
Атомарность (Atomicity) — через журнал транзакций (WAL)
2%
Долговечность (Durability) — через резервное копирование