Я аналитик или тестировщик?! или Зачем аналитику знать 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️⃣ Теперь представьте другую ситуацию: яблоки для пирога были, но вы всегда посыпаете свежеиспечённую шарлотку корицей. Но на этот раз дома нет корицы что за напасть! В этом случае ничто не мешает процессу приготовления шарлотки – пока шарлотка выпекается в духовке, вы можете сходить в магазин за корицей, попросить её у соседей или вообще не добавлять. Это пример асинхронного взаимодействия.

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


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

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