Я аналитик или тестировщик?! или Зачем аналитику знать Postman 🚀


Всем привет! 👋
Сегодня хотим рассказать вам про такой hard-skill для аналитика, как владение Postman. #hardGetAnalyst

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

🥷: проще говоря, программа для работы с API


Что можно делать в Postman:
🔸 тестировать взаимодействие систем путём отправки запросов и получения ответов;
🔸 проектировать API;
🔸 фиксировать взаимодействие систем в удобном для чтения программой (и участниками проектной команды) виде
🔸и многое другое.


🧐 Возвращаемся к тому, а зачем это всё знать аналитику, если есть разработчики и тестировщики?


1️⃣Владение Postman позволяет качественнее определить текущую логику взаимодействия между системами.

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


2️⃣ Второе вытекает из первого: благодаря определению текущей логики во взаимодействии с помощью Postman, повышается качество проектируемых изменений.

🥷: если вы знаете, как системы «общаются» сейчас и уже собрали требования заказчика к тому, как они должны взаимодействовать в будущем, определить разрыв между этими состояниями (или по-другому GAP) и описать к нему требования станет значительно проще👌


3️⃣ Владение Postman – это не только про качественные решения в работе, но и про конкурентоспособность специалиста.

🥷: чем больше скиллов (hard- и soft-) имеет аналитик, тем дороже он ценится на рынке труда среди других специалистов


Короче говоря, владеть навыками работы с Postman — это абсолютный мастхэв для бизнес-, а тем более для системного аналитика. Ведь знания Postman не только полезны в самой работе, но также повышают авторитет и стоимость услуг аналитика что-то на богатом

В нашей работе как-то наоборот получается: чем больше знаешь, тем крепче спишь, ю ноу 😄

Недавно мы открыли новую рубрику #студентыGetAnalyst

Сегодня поделимся достижением ещё одной из студенток второго потока программы «Системный аналитик: с нуля до опыта работы» 💫

Анастасия пришла на курс без опыта работы в системном анализе👆
Раньше работала в сфере управления качеством. Деятельность была связана с анализом процессов в организации.

🎯 Была цель получить новую профессию и сменить работу

У Анастасии к выбору профессии был стратегический подход:
1️⃣ имелся бэкграунд, который она считала, может помочь войти в профессию, и она решила попробовать.
2️⃣ подогревала мысль, что в профессии СА можно применить себя в различных отраслях, ведь рынок IT широк.


Впечатления, которыми поделилась Анастасия с нами после обучения ⤵️

🙋‍♀️: Очень понравились воркшопы и практические занятия — в них была идеальная подача знаний на курсе.
Была полезна именно техническая сторона вопроса, т. к. ранее работала в анализе, но не в IT, и было важно «повернуть» мышление в сторону автоматизации в IT, освоить постановку задач.

Курс «практико-ориентированный». Эксперты дают много примеров из реального опыта работы, с реальных проектов.

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

💥Освоила многие программы — Postman, Notion, draw.io и другие


Сразу после курса Анастасию пригласили на стажировку в проект в качестве системного аналитика, где она на практике закрепляет полученные навыки 💪

Мы всей командой GetAnalyst желаем ей реализоваться в профессии и добиться крутых результатов 🚀

P. S. Есть ещё один приятный момент в этой истории: курс «Системный аналитик: с нуля до опыта работы» Анастасии посоветовала подруга — ранее она проходила обучение на программе по Интеграциям и осталась очень довольна результатом.

Спасибо, что рекомендуете наш проект своим друзьям и коллегам. Это бесценно💚

На прошлой неделе мы опубликовали пост с подходом к решению задач для системного аналитика - порядок работы.


Собрали для вас список ссылок на посты с примерами 😉🔗


1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
https://t.me/getanalysts/713


2. Определение ролей пользователей и приложений, которые будут задействованы
Указаны далее для каждого сценария
+ в работе с архитектурой, которая создается совместно с системным аналитиком на старте IT-проекта
https://t.me/getanalysts/734
https://t.me/getanalysts/735
https://t.me/getanalysts/739
https://t.me/getanalysts/742
https://t.me/getanalysts/746
https://t.me/getanalysts/747
https://t.me/getanalysts/749


3. Выделение и описание основных сценариев + 4. Проработка альтернативных сценариев
https://t.me/getanalysts/718
до https://t.me/getanalysts/720


5. Задачи на дизайнера
Примера постановки задачи нет. Если нужен, ставим ❤️ к посту

----
Про уровень детализации требований:
https://t.me/getanalysts/762
----

10. Задачи на фронтенд / мобильные
https://t.me/getanalysts/773
до https://t.me/getanalysts/776


-----
Прежде чем ставить задачи на бэкенд
https://t.me/getanalysts/790
-----

6. Определение сущностей и свойств + 7. Задачи на БД
https://t.me/getanalysts/794 (шаблон Confluence)

8. Задачи на подготовку тестовых данных
Примера нет. Просим тестировщиков обычным текстом заготовить данные в определенных форматах, если это необходимо. Не обязательный шаг.


9. Задачи на разработку методов Backend (API)
https://t.me/getanalysts/797 (шаблон Confluence)


11. Задачи на тестирование
Без примера 🙂 Исходная задача переходит в статус "Ready for Testing", либо создается подзадача на тестировщика.


12. Задачи на сохранение важных артефактов по документации после разработки - документация
Без примера 🙂 Это текстовое описание в Jira: указания что-где поправить, что дописать, и куда перенести, по окончании разработки.


Чтобы сохранить, пересылаем себе в ЛС! Делаем репосты коллегам и ставим 🔥

👋 Наверняка вы уже сотню раз слышали слова «фронтенд» и «бэкенд», но что за ними стоит? Сегодня рассказываем вам про различия и важность этих частей ПО для конечного пользователя. #hardGetAnalyst


Фронтенд — это то, с чем взаимодействует пользователь на интерфейсе ПО (кнопки, поля ввода и прочие элементы).
Каждая страница в интернете — это фронтенд какой-либо системы. Фронтенд решает несколько задач:

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


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

Основные языки программирования для фронтенда – это:
🔹HTML – отвечает за содержание экранной формы (заголовок, параграф, список, изображение и так далее)
🔹CSS – отвечает за визуальную составляющую экранной формы (цвета, шрифт, отступы и так далее)
🔹JavaScript – отвечает за реакцию системы на действие или бездействие пользователя на интерфейсе.

Далее про бэкенд 🌚

Бэкенд — это основа самой системы, которая отвечает за её работу и недоступна пользователям напрямую.


Бэкенд отвечает за работу с информацией и решение сложных бизнес-задач:

🔸Формирование и обработка бизнес-логики. На бэкенде содержится логика работы систем, которая решает конкретные задачи бизнеса.
🔸Хранение, обработка и предоставление информации. Данные, которые генерирует пользователь или сама система, хранятся «под капотом».
🔸Контроль доступа к информации: разграничение данных и функций, которые доступны пользователям с разными ролями. Например, пользователь интернет-магазина видит только свою историю покупок. Запрет на просмотр истории покупок соседа регулируется на бэкенде.


Бэкенд тоже предполагает код, но он нужен для системы в той части, где обрабатываются запросы пользователей. Например, обработка информации, которая была получена бэкендом по API от фронтенда происходит именно «под крышкой» – то есть на стороне бэкенда.

🔹Для проектирования логики на бэкенде можно использовать любой универсальный язык программирования: Ruby, PHP, Python, Java и другие.



🫂 Фронтенд и бэкенд связаны между собой, поэтому для решения некоторых задач бизнеса приходится дорабатывать обе части ПО.

В конечном итоге в рамках одного проекта разработчики делятся на два лагеря и постоянно общаются между собой, чтобы конечный продукт учитывал логику «лицевой» и «теневой» части:

👨‍🎨 Фронтенд-разработчики трудятся вместе с дизайнерами и верстальщиками над созданием интерфейса продукта, который будет виден пользователю и заказчику системы.

👩‍🔧 Бэкенд-разработчики же выполняют работу, которая скрыта от пользователя и заказчика. Но именно в этой части системы происходит то, что принято называть “работой системы” – то есть выполнение пользовательских задач.

Работа с опытными коллегами - это радость ❤️

Профессия системного аналитика - это непрерывная возможность для роста и обучения. Мы расширяем свой кругозор, знакомясь с разными проектами (банки, туризм, страхование, социальные сети, медицина и другие), улучшаем как технические навыки, так и навыки мягкого взаимодействия (soft skills) в ходе ежедневной работы.

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

Бывает, что приходится задавать самые странные вопросы. Иногда страшно, что спрашиваешь что-то глупое. Но все же... Они терпеливо рассказывают, объясняют, или отправляют что-то почитать 😄

Спасибо разработчикам, кто с удовольствием делится своим опытом, рассказывает про то, как надо делать, и как не надо. Спасибо старшим коллегам, которые также передают свой опыт и направляют в решении задач. И за то, что скидывают шаблоны, примеры постановок задач, чтобы было на что ориентироваться❤️

Ведь потом, через время, становится круто, когда начинаешь всех их по-настоящему понимать: говоришь на их языке, понимаешь технические детали проектов! Это не только ускоряет и упрощает процесс работы, но и придает уверенность!

Карьера в IT - это процесс непрерывного обучения и развития, и круто, когда есть возможность обучаться у лучших ❤️

Давайте мысленно вспомним тех, кто помогал или помогает нам расти, и выразим им огромную благодарность за то, что нам посчастливилось взаимодействовать с этими талантливыми людьми!

P.S. А еще можно написать ✉️

СРОЧНЫЙ ПЯТНИЧНЫЙ МЕМ от бизнес-аналитиков команды GetAnalyst 😄 #GAhahaha

Дружно говорят, что такой способ не работает, видимо пробовали🙈

❗️Внимание, вопрос: а что в таком случае нужно делать, чтобы стать системным аналитиком?

Делитесь своими предположениями в комментариях 🙃 ⬇️

REST API - самый популярный протокол в IT-компаниях для реализации программных систем ⚡️


Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀

Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.

‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️

ССЫЛКА НА АНКЕТУ ПРЕЗДАПИСИ REST API

Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈

🕺🏻 Помните, мы недавно рассказывали про frontend & backend?
Всё дело вот, в чём! ⬇️

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

Очень важно понимать, что API — это не только про взаимодействие различных систем (например, вашей и компании-партнёра), но это и про взаимодействие частей внутри одной системы ☝🏼

Ну и конечно, знания об архитектуре систем и их взаимодействии нужны не только системному аналитику — как мы уже сказали, на техническом собеседовании в компанию вопросы на эту тему будут с наибольшей вероятностью для аналитика любой области👌

Ниже делимся постом на тему API как соединительного звена между frontend & backend!

Ну и конечно напоминаем, что открыт набор на практический курс "Дизайн REST API", 6-ой поток! 🥷

‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️

ССЫЛКА НА АНКЕТУ ПРЕЗДАПИСИ REST API

Как простым языком объяснить, что приложение - это не просто красивые экраны? 🤓

Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌

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

С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!

Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.

В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.

И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀

🐝 НЕПРАВИЛЬНЫЕ ПЧЁЛЫ, НЕПРАВИЛЬНЫЙ МЁД 🐝

Есть улей, в котором пчелы делают мёд. Чтобы сделать мёд, им нужен нектар. Без нектара мёд не получится.


Разберёмся с участниками процесса и примерим их на взаимодействие внутри системы с помощью API:

🔹 Улей – это система, с которой взаимодействует пользователь.
🔹 Нектар – это данные внутри системы.
🔹 Пчёлы – это методы внутри системы, которые позволяют работать с данными. Короче говоря, пчёлы – это интерфейс взаимодействия частей внутри системы (API).
🔹 Мёд – это успешный результат использования метода для получения данных, назовём сокращённо "приложение».

Получается, чтобы система "Улей" работала и давала пользователям результат в виде мёда (работоспособного приложения), нужно подгружать в неё нектар (данные). Без нектара пользователи системы "Улей" мёд не получат и будут грустить 🥲

🥷 Раскрываем тему API в нашем блоге GetAnalyst, объясняя на пчёлах, официантах и пальцах! 🖖
Скорее бежим читать! 💫

👋 Современные системы состоят из множества приложений, которые могут работать независимо друг от друга, но в то же время двигаться с синергией – то есть как единый организм. #hardGetAnalyst


Например, у одной компании может быть:
🔸 веб-сайт И
🔸 отдельное приложение на телефон И
🔸 внутренее ПО (по типу CRM) для коммуникаций с клиентом офлайн (например, в пунктах выдачи или офисах компании).

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

Но помимо приложений внутри одной компании, как единый организм могут работать разные ПО от разных компаний. Вы с таким наверняка встречались, когда регистрировались на новом веб-сайте с помощью учётной записи mail.ru, google и так далее. В этом процессе веб-сайт взаимодействовал с сервисом авторизации стороннего ПО, а для вас, как для пользователя, всё прошло незаметно в рамках одного процесса. Не ПО, а ниндзя какой-то! 🥷


Все эти приложения могут быть написаны на разных языках программирования и использовать разные типы данных. Но несмотря на всю эту «непохожесть» при грамотном проектировании интеграции системы отлично ладят друг с другом, а пользователь получает больше возможностей при взаимодействии с системой 🤌💓

🤓 Основная цель интеграции – установить обмен информацией между приложениями. Как раз для этого и существуют различные режимы и стили взаимодействия приложений.

Скоро вернёмся с рассказом о том, что это за режимы такие и чем они отличаются, не переключаемся 🙃

💥РЕЖИМЫ ВЗАИМОДЕЙСТВИЯ ПРИЛОЖЕНИЙ💥

Существует два режима взаимодействия приложений:
🔹 Синхронный.
🔹 Асинхронный.


Чтобы понять, в каком режиме работает или должна работать система, следует задать вопрос:

🧐«Должна ли система дождаться ответа на запрос, чтобы продолжить работу или может переключиться на выполнение других задач, а за ответом вернуться позже?».

Если был получен ответ:
🔹 «Да, должна дождаться», то это синхронное взаимодействие систем
🔹 «Нет, не должна», то это асинхронное взаимодействие систем


Разберём на простом примере.

1️⃣ Предположим, вам необходимо приготовить яблочный пирог - шарлотку. Если у вас нет яблок, которые составляют основу пирога, то начинать готовить пирог нет смысла – что за шарлотка без яблок? В этом случае вы прерываете процесс приготовления и идёте в магазин за яблоками. По возвращении с яблоками, вы возобновляете процесс готовки. Это синхронное взаимодействие – отсутствие яблок блокирует приготовление шарлотки.

2️⃣ Теперь представьте другую ситуацию: яблоки для пирога были, но вы всегда посыпаете свежеиспечённую шарлотку корицей. Но на этот раз дома нет корицы что за напасть! В этом случае ничто не мешает процессу приготовления шарлотки – пока шарлотка выпекается в духовке, вы можете сходить в магазин за корицей, попросить её у соседей или вообще не добавлять. Это пример асинхронного взаимодействия.

Точно так же происходит и в работе приложений. Влияет ли получение ответа от одной системы на продолжение процесса другой? Например, система интернет-магазина может не запускать процесс доставки, пока не будет получен ответ об оплате, желательно успешный 😄


🔥 Ставьте реакции, если тема понятна или пишите комменты, если остались вопросы — будем разбираться вместе!

Ну и конечно будет КВИЗ на эту тему, как раз потренируемся 😉
А завтра переходим к теме стилей взаимодействия 👌

💥 СТИЛИ ВЗАИМОДЕЙСТВИЯ ПРИЛОЖЕНИЙ 💥

Выделяют четыре основных стиля взаимодействия приложений. Рассмотрим каждый из них немного подробнее.


1️⃣ ПЕРЕДАЧА ФАЙЛОВ

Смысл метода в том, что одно приложение передает в другое приложение файл в согласованном формате (например, XML). В этом файле содержится информация, которая необходима второму приложению для работы.

🧐 В этом стиле очень важно учитывать формат файлов, которыми обмениваются приложения.

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

Передача файлов чаще всего выполняется с использованием FTP (File Transfer Protocol) — стандартного протокола передачи файлов по сети, появившегося задолго до HTTP.

При таком взаимодействии приложения общаются асинхронно, потому что никто из них не уведомляется о том, был ли использован отправленный файл — каждая система занимается своими «системными делами» 🙃



2️⃣ ОБЩАЯ БАЗА ДАННЫХ

Использование общей базы данных несколькими приложениями — это отличный способ создать единое информационное пространство с актуальной информацией для всех потребителей.

Иногда такой подход реализуют в формате «база к базе», когда данные из одной базы передаются в другую напрямую.

🔸 Например, при наполнении базы данных информацией для формирования отчётности, чтобы разгрузить основную систему.

Системы, использующие этот стиль взаимодействия, нельзя назвать ни синхронными, ни асинхронными. При внесении изменений в базу данных просто нет необходимости ждать реакции от систем — данные просто изменяются в одной базе и сразу же изменение перетекает в другую 👌



3️⃣ УДАЛЁННЫЙ ВЫЗОВ ПРОЦЕДУР

Удалённый вызов процедур даёт возможность программному коду, выполняемому на одном компьютере, вызывать код на другом.

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

Проще говоря, одно приложение удалённо вызывает метод другого приложения, передавая ему нужные параметры.

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

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

🔸 Например, если при создании заказа в интернет-магазине, система «Склада» не будет отвечать о наличии необходимых позиций, заказ не должен сформироваться.



4️⃣ ОБМЕН СООБЩЕНИЯМИ

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

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

Обмен сообщениями позволяет приложениям отправлять друг другу сообщения быстро, надёжно и асинхронно.

🔸 Например, с помощью обмена сообщениями разрабатывают мессенджеры и социальные сети.

Наконец-то КВИЗ, где можно закрепить полученные знания, верно? 😄 #quizGetAnalyst

На самом деле учиться играя – это одна из лучших методик запоминания информации! Будет два блока заданий: на тему режимов взаимодействия и на тему стилей взаимодействия приложения.

Не торопитесь, расслабьтесь, старайтесь рассуждать. Конечно, можно подглядывать в теорию, но старайтесь пользоваться подсказкой в крайнем случае – так ощущение победы будет приятнее 😊

Итак, поехали 🚀



1️⃣ Определите, какой режим взаимодействия подходит для каждой ситуации.