Про Мир IT

Всем привет! 👋 Выпал из блогерской деятельности. Накопилась усталость. Много работы. В том числе в рамках «QA Спринта», который я провёл в июне. И, если честно, это был ПОЛНЫЙ ПРОВАЛ 🫣 По крайней мере, именно так мне казалось после первой недели. На спринте было 7 человек, разбились на две команды. Тестировали LMS-платформу, а также форс-мажором оттестировали новую фичу в сервисе автопостинга. Честно, ребята оказались не очень заряженными, плюс на это наложилась моя усталость. Вообще суть спринта задумывалась как возможность для ребят получить практику в тестировании: поработать над реальной фичей, довести её до прода, получить фидбек от пользователей. Но из 7 ребят активность проявляли буквально 3 человека. Вероятно, не хватало моих качеств как аниматора 😅 Либо у ребят просто не было столько мотивации. На второй неделе пообщались на тему использования ИИ. Как раз мой последний пост тут был об этом. Половина ребят на эту встречу не пришла. Но когда они узнали, что часть встречи была посвящена использованию ИИ в работе тестировщика, это заинтересовало всех. И мой изначальный план пришлось менять. Потому что я совсем не планировал превращать это обучение в обучение работе с LLM. Но в итоге мы разобрали, как внедрить ИИ в работу тестировщика и не превратить всё это в какой-то дикий треш, реализовали один MCP-сервер и ещё написали скиллы для агента. 🤷🏻‍♂️ Внедрили это в нашу работу. Конечно, не всё получилось идеально. Время было ограничено. За пару недель настроить процесс даже на скромном проекте невозможно. Всё это добро протестировали на нашем проекте. И тут проснулись даже те, кто после первой недели «выпал» из процесса. В общем, под конец спринта активность зашкаливала. До сих пор с ребятами обсуждаем наши наработки. Кто-то уже начал внедрять их в свою работу. Надеюсь это пойдет на пользу их проекту 😅

Сегодня с ребятами кто у меня на "QA спринте" прошел вебинар. На моем примере рассмотрели QA/AI workspace в Codex.  Собственно основной костяк структуры, которую я использую, представлена на скрине. Главная идея - разделить материалы по степени надежности и назначению: 👉domains/ отвечает на вопрос “о какой системе речь?”. 👉sources/ отвечает “где проверять факты?”. 👉playbooks/ отвечает “как выполнять работу?”. 👉evidence/ хранит доказательства конкретных проверок. 👉memory/ хранит только подтвержденное знание. 👉tmp/ отделяет мусор и промежуточные файлы от полезных артефактов. 👉AGENTS.md - общие инструкции для любого AI-агента, который работает в этом workspace: Codex, Cursor agent, Claude, другой ассистент, если он умеет читать такие файлы. Конечно, всё прям охватить не получилось, но по базе прошлись. Показал как работает Codex в связке с Atlassian, с Qase.io, фигмой. Естесственно всё на примере проекта на котором ребята проходят практику. Чтобы сразу применяли навыки - "не отходя от кассы".

Чем ИИ помогает тестировщику? Самое главное, на что я бы обратил внимание, - автоматизация рутинных задач. Для меня основная рутина в тестировании - это создание тест-кейсов и заведение багов. Давайте чуть подробнее разберём. Тест-кейс Пришла новая фича. Надо изучить → накидать матрицу покрытия → составить чек-лист. А хочется уже начать тестировать: пройтись по основному пути, покликать, начать исследовательское тестирование. Но сначала надо написать тест-кейсы. Допустим, фича небольшая. Накидали 16 тест-кейсов. На создание одного артефакта уйдёт в среднем минут 10. И это я ещё, наверное, оптимистично считаю. Это если мы такие спринтеры, херачим без перерыва, и при этом тест-кейсы очень простые. Сюда входит: продумать предусловия, шаги, тестовые данные, ожидаемый результат. 16 проверок × 10 минут = 160 минут. И в реальности это время можно смело умножать минимум на 1.5. То есть около 3 часов просто на то, чтобы зафиксировать артефакты в системе. Баг 🐞 Частая история: начал проходить тест-кейс → на 5-й минуте нашёл один-два бага → потратил ещё 20 минут, чтобы нормально оформить их в Jira. Шаги, фактический результат, ожидаемый результат, окружение, скрины, видео, логи - всё как положено. Как видит работу тестировщика проджект или тимлид, который не очень глубоко погружён в QA? Примерно так:"Ну тестировщик же 80–90% времени сидит и тестирует приложение".А по факту у многих всё иначе. Иногда значительная часть времени уходит не на само тестирование, а на ввод данных в Jira, TMS, Confluence и другие системы. По сути тестировщик внезапно превращается в оператора ввода данных 😅 К чему это приводит? К некорректной оценке трудозатрат на тестирование. Часто начинающие тестировщики - и не только начинающие - когда их спрашивают, сколько нужно времени на тестирование фичи, считают только само тестирование. Говорят: "пару часов". Но не закладывают время на оформление тест-кейсов, фиксацию багов, обновление чек-листов, подготовку тестовых данных, QA summary и уточнения. В итоге оценка была "пару часов", а тестирование растянулось на пару дней. Ожидания и действительность сильно разнятся. Бизнес думает, что тестировщик 80–90% времени именно тестирует, а рутина - это мелочь. Но на практике иногда значительная часть времени уходит на оформление, фиксацию и поддержку артефактов. В некоторых командах доля такой рутины может быть неожиданно большой - вплоть до половины рабочего времени и больше. Вернёмся к ИИ 🤖 Claude, ChatGPT/Codex и другие инструменты сейчас активно развивают плагины, коннекторы и MCP для взаимодействия с разными приложениями. С Jira и Confluence интеграции уже давно не выглядят чем-то фантастическим. С TMS вроде Qase.io тоже можно выстраивать рабочие сценарии. Раньше я делал так: накидывал тест-кейсы в Notepad++ или Google Docs → просил ИИ сконвертировать результат в CSV → импортировал в Qase.io. И это уже было сильно быстрее, чем руками изначально забивать всё в Qase. А теперь сценарий может быть ещё интереснее. ИИ может взять таску из Jira → накидать матрицу покрытия → оформить тест-кейсы в Qase.io → прилинковать Jira-таску к тест-кейсам → подготовить QA summary. И пока ИИ всё это делает, тестировщик может заниматься тестированием. А потом его задача - провалидировать результат: убедиться, что ничего не забыто, не упущены важные corner cases, и всё оформлено в соответствии с процессом команды. Конечно, это всё не работает идеально из коробки. Нужно отлаживать процесс, прописывать правила и ограничения для работы ИИ. Да, работу ИИ тоже нужно тестировать, пока не начнёте ей доверять. Но главное не забывать: ответственность за результат несёт человек 👫 а не Claude, ChatGPT или любой другой ИИ 🤖 ИИ - это не замена тестировщика. Это инструмент, который может снять часть рутины и вернуть время на главное: думать, исследовать и находить проблемы до пользователей.

На работе нам выдали корпоративного Клода. 😏 Наверное с год назад у меня была подписка на клод за 20 баксов или сколько она стоила, но из-за вечно мешающих работать лимитов я ушел к чату джипити. И с тех пор работаю в нем и когда появился у них Codex, то юзаю его.  Теперь буду переводить некоторые свои рабочие автоматизации на клода. Ну и изучать данный инструмент.  В инсте, ютубе, телеге из каждого утюга: "Клод то, Клод сё" - посмотрим насколько он крут и насколько удобней и мощней того же Codex. Я как-то думал, что я круто работаю с ИИ, там скиллы, mcp всякие - саммари к таскам, тест-кейсики завожу через него, анализ фич делаю и тд. Но пообщался с ребятами, коллегами тестировщиками на днях...Некоторые такое творят с ИИ, что диву даешься. 🤯  А у вас на работе есть корпоративные ИИ инструменты? Если да то какие поделитесь в комментах плиз. PS: ну что олды, кто скажет почему к посту я прилепил данное изображение? 👨‍🦳 тому почёт и моё уважение+)))

Всем привет! Первый момент, который я хочу обязательно подсветить:Нельзя просто написать в чатик: сгенерируй мне тест-кейсы по данному функицоналу. /и скидываете ему доку/Точнее можно и возможно в каких-то случаях он даже выдаст какую-то годную инфу.  Но, если вы хотите сделать себе помощника, инструмент с помощью которого вы будете экономить себе время, то к этому надо отнестись серьезно. Самый простой вариант без лишней автоматизации и геоморроя это сделать себе "скилл" для нейронки. И при создании тест-кейсов использовать его.  Для этого не требуется каких-то высоких технических знаний. Это просто создание одного или группы файлов в формате .md Я тестирвал так: 1. Просто промпт в ChatGPT 2. Промпт в ChatGPT + подготовленные файлы скиллы 3. Codex: создал папку проекта, разместил там доку + "скилл". И попросил написать тест кейс. 2 и 3 выдали лучший результат. Но с Codex понравился больше всего Я думал сделать может воркшоп на эту тему. Или просто видео записать. 😅 Если интересно кидайте реакции. 🔥

🤖"ИИ заменит тестировщиков! Разработчиков! Аналитиков!" Пришел и мой черед высказаться на данную тему... Что происходит? Мировая экономика живёт в режиме жёсткой оптимизации: быстрее выпускать продукт, дешевле поддерживать процессы и меньше тратить время людей на рутину. Да, часть компаний внедряет ИИ просто потому, что это хайп и "так сейчас надо". Но за хайпом стоит более жёсткая вещь: бизнес ищет способы ускоряться, сокращать косты и выживать в конкурентной гонке. Будут ли сокращения? Да, мы это уже видим. Значит ли это, что люди больше не нужны? Нет. 💥Но пропорции в работе уже меняются. Мне кажется, здесь хорошо работает аналогия с конвейером Форда. Не "один в один", конечно. Но по логике похоже. Когда появился движущийся конвейер, ценность человека в процессе начала смещаться. Многие "ручные" работники мастера стали не нужны производству. Кто не могу перестроится увольнялся или его увольняли. Закрывались целые заводы. Но потом производство встаёт на новые рельсы. Профессии не то что бы исчезли, они трансформировались. И начался колосальный спрос на сотрудников. Не на мастера, который один собирает всё руками. А на людей, которые работают внутри нового процесса: держат качество, следят за стабильностью и понимают систему. Людей требовалось еще больше, чем работало прежде на заводах. Мне кажется, с ИИ в IT будет похожая история. Сначала сокращения и перестройка. Потом новый цикл найма. Но нанимать будут уже не просто "руки", которые пишут код, тест-кейсы или документацию. Будут нужны люди, которые умеют работать с ИИ как с частью процесса. С ИИ в IT мы переходим от роли "я всё пишу руками" к роли: 🔹 ставлю задачу 🔹 проектирую решение 🔹 проверяю результат 🔹 связываю части системы 🔹 отлавливаю ошибки ИИ 🔹 отвечаю за качество результата Раньше специалист тратил много времени на генерацию базы: бойлерплейт, рутинные скрипты, типовые тест-кейсы, черновики документации. Теперь ИИ может выдать эту базу за секунды. Но это не значит, что работа закончилась. 🙅‍♂️ Теперь важно понимать, что он выдал, где наврал, что не учёл, какие риски пропустил и как это встроить в продукт. Мы больше не просто крутим гайки вручную. Мы учимся управлять умным конвейером. И выигрывает не тот, кто громче всех говорит: “ИИ меня не заменит”. А тот, кто умеет использовать ИИ, но остаётся профессионалом: думает, проверяет, задаёт правильные вопросы и отвечает за результат. 🧙‍♂️ Мой вывод простой: ИИ не заменит сильного специалиста. Но специалист с ИИ легко обгонит того, кто продолжает делать всю рутину руками и принципиально не перестраивается. Я не думаю, что история закончится тем, что "люди больше не нужны". Скорее рынок проходит фазу перестройки. Когда процессы стабилизируются, людей снова будут нанимать. Но требования будут другими. Никому не навязываю своё видение. Просто мысли которыми хотелось поделиться. -------- Добавляйся в контакты на LinkendIn | Подписывайся в MAX

💬QA Sprint Lab #2: Практика на реальном проекте EasyPost С 1 июня запускаю второй 4-недельный практикум для тестировщиков. Никакой теории и лекций - чистая работа в режиме реального продуктового стартапа. Тестировать будем SaaS-сервис отложенного постинга для Telegram и Max. Коротко, что внутри: 👉Работа по Agile на Канбан-доске в GitHub Projects(или аналог). 👉Тестирование REST API (Postman/Swagger) и UI/UX в условиях отсутствия или минимальной документации. 👉Попрактикуем использование ChatGPT/Claude для генерации тестов и ускорения рутины. 👉Строчка реального проекта в резюме + моя рекомендация для тех кто реально проявит себя и дойдёт до конца. Условия: строго 6 человек. Стоимость участия в группе - 24 000 руб. 👉 Полная программа, процесс и требования к базовым знаниям расписаны здесь Чтобы занять место, пиши мне в личку @EugSych кодовое слово «СПРИНТ». Коротко пообщаемся, на предмет ожиданий и мотивации. И если будет мэтч поработаем. 🤝

Всем привет! 👋 Кто следит хоть немножко за моими редкими постами тот знает, что у меня есть несколько проектов, которые я делаю в свободное время. Я об этом не раз писал и зазывал ребят кому не хватает практики потестировать мои проекты. Один из них это EasyPost - сервис отложенного постинга в Telegram и Max. В этом году у меня было несколько человек на месячной индивидуальной практике, где мы именно что разрабатывали, тестировали и внедряли новые фичи, в том числе и на данном проекте. Ребятам огромный респект🙌, нашли много багов, но и, конечно, многое найти ещё не успели. Есть много UX решений, которые нужно доработать, баги которые поправить.  Но сейчас мне очень сильно не хватает именно пользовательского фидбека. Именно поэтому я хочу уже запустить проект в жизнь пока в рамках бета-теста. Хочется, чтобы пользователи начали использовать приложение по назначению и возвращались с обратной связью. Я хочу отпалировать то что уже реализовано. А это: 👉 Создание постов в удобном редакторе. 👉Предпросмотр. Пишите пост и сразу видите как он будет выглядеть в мессенджере. Не уверены? Отправьте тестовое сообщение оно придет к вам в личку от бота. 👉 Можете сохранять черновики планируемых постов. 👉Поддержка изображений и видео. 🔥Функция relay. Это переопубликация поста из Telegram в Max. Если вы создаете пост в телеграм обычным способом он опубликуется автоматически в Max. Поддерживает в том числе кружки и голосовые.  Пока ссылок не даю. Идет подготовка инфраструктуры. Сегодня или завтра опубликую новый пост.  Кстати данное сообщение опубликовано с помощью данного сервиса. 💙

В инсте, в сторис запустил интерактивку. Но чёт потом подумал, что наверное в телеге получше. Тут комментарии хоть можно расписать. ) Идея такая, вспоминаю баги с прода свои или чужие. Рассказываю о них с точки зрения конечного пользователя. В комментарии начинаем обсуждать. Интересно именно послушать как бы кто действовал. Особенно призываю поучаствовать ребят кто без опыта. Только учится или обучился и ищет работу. Остальные тоже могут у кого желание есть. В чем профит? Будем прокачиваться в мышлении, в локализации. Учится задавать правильные вопросы. Как говаривал кто-то умный: плохой вопрос это незаданный вопрос. Я всегда был против подхода: "завел баг и забыл", Всегда хочется максимально точно его локализовать. Но порой даже непонятно с какой стороны взяться. Предыстория: Вы QA тестируете софт в котором надо работать со сканером штрихкодов. Условно касса в магазине, софт логистический, или в пунктах выдачи заказов сидят вот тоже пикают сканерами товары. В общем сканируем штрих-код получаем информацию о каком-то объекте. Но на проде случилась беда: определенные штрихкода не сканируются, выдается ошибка "Данный товар уже отсканирован ранее". Это не блокирует весь процесс. Есть обходной путь, но работу замедляет. Штрихкод: BC-12345678 и аналогичные проблемные Штрихкод вида 9876543210 проходят без проблем. Как бы вы локализовывали проблему? Можно мне вопросы задавать. Я буду в роли конечного пользователя, аналитика в общем кого угодно) Пишите в коментах 👇👇👇👇👇👇👇👇

Не так давно я описывал свои подходы (офигеть полгода прошло) по формированию тестовой модели на проекте, а так же организацию коллекций в Postman и тут. Собственно последний год я не мало материала изучал по ведению тестовой документации, что бы уловить современные тенденции. Зачем я это делал? Что бы быть в теме. Что бы на проекте применять только современные практики, если, конечно, они полезны проекту. Сегодня я бы хотел поговорить про API. А конкретно про API тест-кейсы. Один из регулярных вопросов за многие годы от коллег и учеников: "Как правильно писать тест-кейсы для ручного тестирования API?" Я и сам на протяжении многих лет задавался этим вопросом. Но сейчас я хотел поговорить не об этом. В наше время пожалуй правильно будет задавать вопрос: А надо ли писать тест-кейсы на API? Если погулять по зарубежным пабликам посвященным QA (и не только), можно периодически наталкиваться на доклады и статьи о том, что писать ручные тест-кейсы на API это расточительство времени и двойная работа. И вообще это антипаттерн в современной команде разработки. В наше время есть инструменты, которые позволяют легко покрывать 80% API автоматическими проверками. А так же подходы: shift-left testing и контрактное тестирование (про это как-нибудь в будущих постах). 🧐Почему коллекция в Postman может заменить тест-кейсы? Если вы используете Postman на "максималках", то он от части берет на себя функции TMS (система управления тестированием): Названия запросов = Заголовки тест-кейсов. Вместо GET /users/1 можете написать [Positive] Получит информацию о пользователе. Вкладка Scripts (Post-response) = Ожидаемые результаты. Скрипты на JS проверяют статус-коды, структуру JSON и бизнес-логику - то что мы ожидаем. Описание (Docs) = Шаги теста. В Postman у каждого запроса есть поле Docs, куда можно вписать описание параметров и логику теста. Или другую полезную информацию. Folders = Наборы тестов (Test Suites). Группировка по фичам или модулям. Вывод: Если ваша коллекция структурирована так, что сторонний человек может ее запустить и понять, что проверяется - дублировать это в Jira/TestRail текстом действительно бессмысленно. Это лишняя работа по поддержке актуальности. Поэтому я всегда говорил и буду говорить: если вы используете Postman, потратьте вы на 2 минуты больше времени на один запрос. Напишите тесты в Scripts к нему, простенькую документацию в Docs. Не знаете JS? Или даже знаете? Сгенерируйте тесты, сгенерируйте документацию с помощью AI. Не слушайте тех кто говорит что это кринж. Что, если писать автоматизацию, то надо обязательно сразу на Python+pytest, а документацию аналитик должен делать. Почему же все продолжают упорно писать ручные API тест-кейсы? Тут эффект старой школы. У меня он тоже пожалуй есть. Раньше это была стандартная практика и многие нынешние руководители это воспитанники "старой" школы. Им куда понятней 500 тест-кейсов в TMS, которые можно открыть посмотреть почитать. А что такое коллекция в Postman? А хрен её разберешь. С трудом, но всё таки новые тенденции пробираются в команды. А у вас как с этим дела на проекте? Вы пишите ручные тест-кейсы на API? 🔥  Кейсы на API не пишем 🤔  Пишем и кейсы, и коллекции ведем (двойная работа, а что делать...) ⚡️ Только код, только хардкор (автотесты, контракт-тестинг) 🌚 Кейсов нет, коллекций нет, тестируем по памяти 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

💡 На выходных проверял домашки по Postman. Всего было 4 работы. Все разные, по-своему интересные. Но одна прямо выделилась - самая объёмная и проработанная. На разбор у меня ушло 3 больших сообщения в Telegram. 🤯 И знаете, что мне нравится в таких моментах? Не просто проверить "правильно / неправильно", а именно разобрать, почему так и как сделать лучше. В этой работе было всё: -> цепочка запросов -> переменные -> скрипты -> тесты -> и даже заход на более продвинутые вещи И вот тут начинается самое интересное. Почти всегда проблема не в том, что "код не верный". А в том, что: -> где-то переменные перепутаны -> где-то шаги не связаны -> где-то логика ломается -> а где-то тест "зелёный", но на самом деле ничего не проверяет И именно такие разборы дают больше всего пользы, как ученику(я надеюсь), но и мне. Потому что это уже не теория, а реальные ошибки, которые потом ловятся в работе. А для меня польза не забыть какие-то базовые вещи. Это как на CodeWars решать каждый день задачки, чтоб держать себя в тонусе) Хотя я вот себя никак не могу приучить решать регулярно задачки))

👋 Всем привет! Давно хотел спросить ваше мнение про новый интерфейc Postman. Как вам он? Я, если честно, в восторге! Мне вообще нравятся интерфейсы в таком linear app стиле. Он сразу стал не таким тяжелым. Свободным что ли. Элементы аккуратные, компактные. Мне стало намного приятней в нём работать. Единственное, теперь хоть курс переписывай. Так как уже были ребята, кто задавался вопросом, что не могут что-то найти. Потому что в видеоуроках какая-то кнопка в одном месте, а в новом интерфейсе она уже в другом 🤷🏻‍♂️ А как вам новый интерфейс? 🙂 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Про Мир IT pinned a photo

🔻 🚨 🔠🔠🔠🔠 🚨 Postman обновил тарифы: что случилось с Free-планом? Разбор изменений с марта 2026 Я работаю с Postman c 2013 года. Тогда это было бесплатное расширение в браузере Chrome. Сейчас в 2026 году это большой SaaS продукт с классическим ценником который стартует от $19. Хотя нет…теперь от $9. Но давай по очереди. Главный поворот случился 1 марта 2026: Postman перезапустил линейку тарифов. Free теперь строго для одного человека, появился Solo за $9/мес, Team стал минимальным для любой команды ($19/пользователь/мес при годовой оплате), а Enterprise ушёл в $49 за пользователя. 💡 Что реально изменилось - Free → только соло-разработчик. Никаких команд, приглашений, шаринга коллекций или совместного редактирования. Раньше можно было 2–3 человека спокойно коллаборировать - теперь нет. И это удар по маленьким командам, где было 2-3 тестировщика и они пользовались много лет совместным workspace. Это было удобно. Тут стоит сделать поправку: в моей практике, когда я приходил на проект мало кто в команде пользовался совместным воркспейс, все тестировщики были сами по себе. Поэтому насколько реально это бьет по людям непонятно. Напиши в комментариях свое мнение. Но для одиночки Free стал даже щедрее: • 50 AI-кредитов/мес • ❗️Unlimited Collection Runner + Performance Testing runs (! никаких ограничений на запуск коллекций! это прям пушка) • Unlimited mock-серверы (облачные и локальные) • Unlimited manual Flows • Native Git, неограниченные спецификации, Postman CLI и т.д. → Если работаешь один - можно жить комфортно без копейки. - Solo ($9/мес, годовая оплата) → для power-соло-разработчиков. Всё из Free + 400 AI-кредитов, data-driven тесты с экспортом, unlimited private NPM-пакеты, кастомный брендинг доков, unlimited custom-домены, расширенный мониторинг API. - Team ($19/пользователь/мес, годовая) → точка входа для любой коллаборации. 400 AI-кредитов на человека, шаринг, unlimited viewers, базовый RBAC, генерация SDK. Для команды из 3 человек - $57/мес ($684/год). Для 5 уже $1140/год. - Enterprise ($49/пользователь/мес) → всё остальное: 800 AI-кредитов (пулинг), API Catalog, Private API Network, advanced governance, audit logs, private runners и т.д. Большинству команд это не нужно, но структура тарифов толкает туда тех, кто хочет «всё и сразу». 🐤 Скрытые подводные камни - AI-кредиты улетают молниеносно - генерация полной документации или тестов на сложный API может сожрать сотни/тысячи кредитов за раз. 400 в Solo/Team звучит круто, но на практике быстро кончаются → потом доплачиваешь $0.04–0.05 за кредит. - Только годовая оплата для Team/Enterprise - нельзя попробовать месяц и отменить. - Кто страдает сильнее всего - стартапы 2–5 человек, агентства с кучей мелких проектов, растущие команды, которые раньше сидели на Free и вдруг это у них забрали. ❓За что всё-таки платят (и стоит ли) Postman по-прежнему топ по коллаборации: синхронизированные environments, shared collections, удобный workflow "один дизайнит → второй тестует → третий документирует". Плюс огромная экосистема: тысячи готовых публичных коллекций, шаблонов, комьюнити. Но если твоя команда использует в основном базовые коллекции и тесты - а коллаборацию можно обойти (Slack + Git или что-то ещё), то $19/чел может показаться перебором. Многие уже смотрят на альтернативы, где free-tier всё ещё позволяет командам работать без жёстких ограничений. 💭 В итоге: если ты соло - Free/Solo огонь. Если небольшая команда - готовься либо платить, либо мигрировать. Вот такие новости ребят Кто что думает? Пишите своё мнение в комментариях. 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Вот и пришла весна! 🌿 Хотя по сугробам на улицах Москвы так сразу и не скажешь 🙂 В честь первых дней весны делаю скидку 20% на курс «Postman с нуля до профи». Этот курс - не про “потыкать запросики”. Мы учимся собирать из запросов цепочку бизнес-процесса, чтобы: 1. быстро проверять end-to-end сценарии руками, когда нужно “прям сейчас”, 2. и иметь готовый инструмент, который ускоряет тестирование и помогает команде. По сути, ты собираешь коллекцию так, чтобы она была похожа на мини-автотест: запустил - и сразу видно, где всё ок, а где что-то сломалось. Что по итогу ты будешь уметь: - собирать коллекции под конкретные цели (смоук/регресс/проверка фичи); - настраивать окружения и переменные, передавать данные из запроса в запрос; - за пару минут вручную “прокликивать” бизнес-процесс; - запускать сценарии автоматом в Runner или через Newman; - добавлять проверки и простые скрипты (tests + базовый JS) - чтобы коллекция не просто выполнялась, а сама проверяла результат и показывала понятный “зелёный/красный” итог; - и, конечно, увереннее отвечать на вопросы по Postman на собеседованиях (без ощущения “я вроде пользовался, но не уверен”). Полную программу курса можно посмотреть 👉 ЗДЕСЬ Все вопросы можно задать здесь или мне в личку @EugSych 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Бывало ли у вас так, вы начинаете регресс и выясняется, что одна из систем вдруг не работает? И это блокирует всю систему и блочит регресс? Оказывается одна из систем исправила один небольшой баг и это поломало контракт. И к примеру, встала очередь в кафка.  Такое может случиться и на релизе. В моей практике такое бывало.  ⚠️ Это нас приводит к важности контрактного тестирования, как одного из гейтов релизного пайплайна. 👇👇👇👇👇👇 Контрактное тестирование - это когда команда ведет разработку так, чтобы такие изменения ловились до релиза, автоматически в ci/cd. А Pact - один из самых популярных способов это организовать. Суть простая: 1️⃣ Потребитель фиксирует ожидания Потребитель (consumer) - тот, кто вызывает API. Для простоты в моей истории это будет фронт.  Он говорит: "когда я делаю вот этот запрос, я ожидаю вот такой ответ: такие поля, такие типы данных, такая структура". Фронтендер разрабатывая фичу пишет небольшой контрактный тест. Разработав функционал он запускает тест используя mock бэка. Если тест проходит успешно мы получаем артефакт: pact-файл в JSON формате. Это и есть наш контракт. Файл кладется в хранилище контрактов (может быть просто каталог в репозитории) 2️⃣ Бэк проверяет, что не сломал ожидания Дальше провайдер (provider) - в моей истории это будет бэк - в пайплайн своего деплоя добавляет этап верификации контрактов. На этом шаге CI берётся этот pact-файл, поднимаются эндпоинты новой сборки и проверяется контракт. Если не совпадает - сборка не проходит дальше. Анализируем -> исправляем -> пробуем снова собрать релиз. Это дает нам достаточно надёжный Gate ⛩не пропустить в релиз критичный баг. 🤔 Где тут QA? Спросите вы. Сам контрактный тест пишут как правило dev’ы. Но QA очень помогает, когда: 👉 выбирает что именно контрактовать (мы не проверяем всё подряд!) 👉 задаёт строгость (какие проверки must-have, что критично?) 👉 следит, чтобы контракт не был "ни о чём" или наоборот - не был избыточным Если вы прочитав этот пост поняли, что у вас нету такого, не стоит сразу бежать к команде и кричать, что нужно внедрять PACT. Но если у вас на проекте периодически встречаются ситуации, как та что описана вначале поста, то это прям повод задуматься. Если фронт и бэк релизятся отдельно и API часто меняется - Pact обычно окупается.  При интеграциях почти всегда must-have. Но если у вас пока проект не большой, всё выкатывается вместе и почти не меняется - можно не усложнять. 🫡 Напишите в комментариях у вас есть контрактное тестирование? Используете pact или другой подход? 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

😭Хаос в Postman начинается не с количества запросов, а с отсутствия правил структуры. Если коллекция у тебя это "просто запросы", обычно через пару спринтов получается свалка: дубли, непонятные названия, случайные проверки и вечный вопрос "а что вообще прогонять?". Я предпочитаю держать порядок, поэтому на проекте всегда структурирую Postman-коллекции. Пример подхода (как ориентир, не догма): 1) Коллекция “OpenAPI” Одна коллекция соответствует актуальной OpenAPI спецификации проекта. Это база, чтобы видеть как  оно сейчас на проде реализовано. 2) Коллекция “Functional (core)” Декомпозирована по функциональности: без лишних запросов, только то, что реально нужно в работе (самые частые операции, критичные флоу, опорные эндпоинты). 3) Коллекция “Smoke / E2E” Ключевые e2e-сценарии + проверки. Быстро понять: можно ли безопасно продолжать работу, не горит ли критичное. 4) Коллекция “Contract checks” Контрактные проверки: обязательные поля, типы, enum, форматы, мета (включая пагинацию). Это защита от "под шумок сломали контракт". 5) Коллекция “Negative / Edge” Сценарии, которые чаще всего ломают прод: auth/ACL, idempotency, retries/429/503, cache/consistency, границы значений и комбинации. Почему я не "лью всё в одну коллекцию"? Потому что у разных наборов разная цель, частота запуска и аудитория: Smoke нужен быстрый и стабильный, Contract - точный, Negative/Edge - точечный по рискам. Когда всё в одной куче - она перестаёт быть инструментом, превращается в архив. Я оформил этот подход в небольшой pack со структурой и примерами. Выложил у себя на сайте. 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman