* БД внешних систем для нас закрыты, это неизвестность - “черный ящик”. Даже если вы по какой-то причине знаете, что в БД внешней системы, т.к. интеграция осуществляется между системами внутри одной компании и секретов нет (NDA - соглашение о неразглашении), то не надо перегружать постановку задачи. Там и так много всего.

Когда и в каких случаях рекомендуется описывать маппинг на примере GetDelivery:

🟢 Для задач на мобильные или веб- приложения GetDelivery:
Маппинг между REST API GetDelivery и UI GetDelivery.

🟢 Для задач на интеграционный REST API GetDelivery c БД GetDelivery, СДЭК, Возовоз, Деловые Линии:
Маппинг между REST API GetDelivery , БД GetDelivery и API внешней системы СДЭК / Возовоз / Деловые Линии (все три внешние системы в один маппинг вставить можно, но тогда нужно очень хорошо подумать над тем, как организовать таблицы.


Это будут отдельные таблицы маппинга данных, для разных постановок задач. Теперь надо примеры статей 👇

Главный вопрос, с которого начинается любое обучение: «Какая цель?»🎯

Без конкретной цели вы рискуете свернуть не туда или не дойти до финиша.

В коучинге даже есть такой приём — расписать достижение поставленной цели по ощущениям в моменте, когда цель достигнута:
▪️ что я вижу,
▪️ что я слышу,
▪️ что я чувствую.

Это поможет больше прочувствовать желаемое и представить себе, как будет круто, когда поймете, что пришли в заданную точку.

После завершения программы мне всегда приятно фиксировать, что многие пришли к цели уже в процессе, а кто-то даже сделал «за» цель — перевыполнил план))

На новом потоке по Интеграциям я вижу не только бизнес- и системных аналитиков, которые пришли самостоятельно, но и специалистов, которые пришли учиться от работодателей! Особенно ценно, что компании хотят развивать и продвигать свои кадры 🙌

Я стараюсь помочь каждому определить цели и дать рекомендации, которые помогут достичь желаемого результата.


Какие цели ставят студенты GetAnalyst:

✅️ сменить работу и/или повысить доход,

✅️ перейти в системный анализ,

✅️ углубиться в техническое проектирование,

✅️ получить практический опыт по интеграциям, чтобы пополнить портфолио
(+++ моя цель, чтобы на собеседовании вы рассказывали про наш проект, который ведём в ходе курса, а не про «сферического коня в вакууме»)

Мы уже провели встречу по карьере, собираем точки А и цели, смотрели предобучение и первый теоретический модуль. А завтра я увижу коллег на первом онлайн-вебинаре по знакомству с проектом и выделению интеграционных Use Case! 🔥

В эти моменты старта мне ценно осознавать, что обучение от GetAnalyst будет для вас одной из точек в осуществлении целей и потенциальным карьерным ростом уже на старте 2024! 🎄

Спасибо за доверие! И вперёд к результатам 🚀♥️

🟠 Тестирование API - зачем это надо системному аналитику? 🟠


Системный аналитик встречается с тестированием API (программный интерфейс) в следующих случаях:



✅️ Мобильные приложения

Когда аналитик ставит задачи на разработку мобильных приложений, то, как правило, ему необходимо описать маппинг между тем, что есть на экране - UI (пользовательский интерфейс), и тем, что можно отправить или получить от сервера (Backend) через API.

Чтобы это сделать, аналитик знакомится с API-документацией, которую ему предоставляют Backend-разработчики. Возможно он сам ставил им задачи, возможно это были другой аналитик и отдельная команда, которые сделали API.

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



✅️ Backend

Во многих компаниях малого и среднего бизнеса, в крупных компаниях-интеграторах, которые делают IT-проекты на заказ, выделяют отдельную Backend-команду под проект. У крупных IT-проектов это просто необходимость. В такие компании ищут системного аналитика в Backend-команду. Тут сразу хочу заметить, что бизнес-аналитику такую роль выполнять будет почти невозможно, либо сразу можно назвать его системным.

Системный аналитик в Backend-команде должен уметь не только проверить API, но и спроектировать его с нуля, создать документацию для него.



✅️ Интеграции

Системы взаимодействуют друг с с другом по API. Это могут быть как подсистемы внутри одного проекта, так и системы других компаний. Пример - проектирование GetDelivery.

Для того, чтобы глубже погрузиться в интеграционную задачу следующий мой шаг - тестирование API, чтобы лучше понять как работают внешние системы, процессы в них. Та же история, что с мобильными приложениями.



Тестирование API позволяет глубже погрузиться в технические особенности, что невозможно сделать на уровне чтения API-документации.

🟢 Зачем системному аналитику инструменты для тестирования API?

1. Проверка Функциональности:
Системный аналитик убеждается, что API выполняет заданные функции в соответствии с документацией. Он проверяет как ведет себя в нестандартных ситуациях, чтобы учесть их и обработать в сценариях работы системы.

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

3. Оптимизация Производительности:
Проверка на скорость и надежность работы, особенно, когда в интеграциях идет обмен большим количеством данных. Тестирование помогает понять, какие нефункциональные требования и как поддержать, используя хорошо организованные архитектуру и инфраструктуру проекта.

Какими инструментами на работе пользуетесь вы, делитесь в комментариях? Интересно посмотреть на статистику 🙂

👉✅ Тестирование API: обязательные инструменты к освоению для системного аналитика

🟠 Postman

Возможности:
> Отправка запросов к API - HTTP, GraphQL, WebSocket, gRPC, MQTT, Socket.IO,
> Создание и управление коллекциями запросов под разные проекты.
> Тестирование API с помощью написания тестовых сценариев на JavaScript.
> Возможность имитации сервера (Mock Servers) для тестирования без реального API.
> Поддержка автоматизированного тестирования.
> Есть онлайн и десктоп версии, не обязательно устанавливать.

Преимущества:
+ Удобен для новичков.
+ Используется в большинстве компаний. Поэтому именно его я даю на программах по проектированию Интеграций и REST API.
+ Легко интегрируется с другими инструментами и системами.
+ Отличное сообщество и документация: Обширные руководства и активное сообщество пользователей.
+ Бесплатной версии достаточно для работы на небольших проектах.

Недостатки:
- Высокое потребление ресурсов: Может быть ресурсоемким на некоторых компьютерах.


🟡 SoapUI

Возможности:
> Тестирование REST и SOAP веб-сервисов.
> Возможность создания сложных тестовых сценариев без программирования.
> Автоматизация тестирования.
> Мокирование веб-сервисов для тестирования в изолированной среде.
> Поддержка асинхронного тестирования.
> Расширенные возможности отчетности и аналитики..

Преимущества:
+ Поддержка различных типов API: Включая SOAP и REST.
+ Мощные функции для сложного тестирования. Подходит для разработчиков, которым нужны продвинутые возможности.
+ Детальная отчетность, удобная для анализа результатов.

Недостатки:
- Высокий порог вхождения: Может быть сложным для новичков.
- Надо устанавливать, нет веб-версии.


Это два главных инструмента, которые используют для проверки API и компании ценят, когда системные аналитики их знают! Postman в большей степени.

Есть ещё два инструмента, которые здесь появятся. Есть идеи? Пишите в комментарии! 😉

🟢 Swagger

Возможности:
> Генерация интерактивной API-документации с использованием OpenAPI спецификации.
> Подходит для проектирования API с нуля, с возможностью визуального редактирования.
> Тестирование API прямо из создаваемой документации.
> Автогенерация API-документации на основе кода приложения благодаря OpenAPI спецификации.
> Поддержка OAuth и других механизмов аутентификации.

Преимущества:
+ Автоматическая документация AP на основе кода.
+ Поддержка OpenAPI Specification, что дает универсальность и стандартизацию для документирования API. OpenAPI сегодня также поддержан и в Postman.
+ Интерактивное тестирование API непосредственно из документации.
+ Сообщество и экосистема предоставляют множество плагинов и инструментов.

Недостатки:
- Начинающим может быть сложно разобраться во всех возможностях, и в целом с OpenAPI.
- Для тестирования API его почти не используют, в основном для написания документации.


🟣 insomnia - больше подходит для тестировщиков.

Возможности:
> Тестирование REST, SOAP, gRPC, GraphQL и др
> Загрузка проектов из Swagger.
> Возможность настройки окружений для тестирования (разработка, тестирование, прод и др.).
> Испольование переменных для упрощения и автоматизации тестов.
> Поддерживает автоматизацию тестов.
> Поддержка версионирования и совместной работы.
> Возможность расширения функциональности с помощью плагинов.

Преимущества:
+ Легок в освоении даже для начинающих.
+ Вся необходимая функциональность бесплатна.
+ Удобен для работы с GraphQL.
+ Активное сообщество: Множество руководств и поддержка сообщества.
+ Возможность создавать и прогонять тест-кейсы - полезно для тестировщиков.
+ Возможность поддержки версионности кейсов с подключением их к Git.

Недостатки:
- Может быть менее подходящим для очень сложных тестовых сценариев: В сравнении с такими инструментами как SoapUI, функционал Insomnia может показаться ограниченным.
- Недостаток интеграций по сравнению с Postman: Хотя Insomnia поддерживает плагины, общее количество интеграций и расширений может быть меньше.

Нагрузочное тестирование 🥲

А еще рекомендуют знать про JMeter. Стоит взять на заметку, если вдруг придется столкнуться с анализом нагрузок на систему и надо будет что-то подсказать разработчикам.

Возможности:
> Нагрузочное и стрессовое тестирование.
> Тестирование производительности веб-приложений.
> Поддержка многопоточности и симуляция одновременного доступа множества пользователей.
> Запись и воспроизведение тестовых сценариев.
> Графическое представление результатов тестирования.


Заключение:

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

Из опыта скажу, что в 90% работы я использую Postman.

Для тестирования SOAP API я обращаюсь к SOAP UI.

Для разработки API-документации тоже использую Postman, но и Swagger в этом деле идеальный помощник, просто более сложный.

Insomnia использовали коллеги-тестировщики, а JMeter однажды разработчики 🙂


Выбор определенного инструмента зависит от конкретных требований и целей тестирования.

Зачем быть частью сообщества, если можно и без этого жить? 🧐

Можно, но когда становишься частью сообщества, то в твоей жизни появляется больше возможностей, чтобы быстрее расти и развиваться.

Если ваша цель — прокачивать себя и выстраивать сильное окружение вокруг, то стоит об этом помнить 😏

Когда присоединяешься к сообществу, то находишь людей, которые разделяют твои интересы и ценности. Это классная возможность общаться с людьми, которые понимают тебя и говорят с тобой на одном языке.

Они помогают нам раскрыться, посмотреть на мир под другим углом. А ещё это классный шанс увидеть свои точки роста 💫

Я искренне радуюсь, когда подсвечиваю эти «точки» студентам GetAnalyst. Мне нравится говорить о том, как можно достигнуть новых высот, ставить новые цели в карьере, планировать новые проекты. Безумно приятно потом узнавать, что для кого-то общение стало судьбоносным и повлияло на жизнь.

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

Особенно я люблю живые вебинары и воркшопы ❣️Мне важно быть живой, видеть вашу реакцию, получать обратную связь. После таких встреч я настолько заряжаюсь, что уверена — моей энергии хватит, чтобы поддерживать в тепле как минимум один большой мегаполис! Или запустить ракету в космос 🚀

Спасибо Вам, что вы стали частью GetAnalyst. Спасибо всем, кто прошел с нами путь роста в этом году! ❤🦭