Про Мир IT
前往频道在 Telegram
13 лет в тестировании. Показываю, как прокачивать скиллы, внедрять новые фишки и расти в доходе. Postman, практика и всё, что помогает QA стать сильнее. Инстаграм: @pro.mir.it
显示更多1 372
订阅者
+424 小时
+247 天
+6830 天
正在加载数据
吸引订阅者
十月 '2610月 '26
十月 '26
+971
在0个频道中
九月 '260
在0个频道中
Get PRO
八月 '260
在0个频道中
Get PRO
七月 '260
在0个频道中
Get PRO
六月 '260
在0个频道中
Get PRO
五月 '260
在0个频道中
Get PRO
四月 '260
在0个频道中
Get PRO
三月 '260
在1个频道中
Get PRO
二月 '260
在0个频道中
Get PRO
一月 '260
在0个频道中
Get PRO
十二月 '250
在0个频道中
Get PRO
十一月 '250
在0个频道中
Get PRO
十月 '250
在0个频道中
Get PRO
九月 '250
在0个频道中
Get PRO
八月 '250
在0个频道中
Get PRO
七月 '250
在0个频道中
Get PRO
六月 '250
在0个频道中
Get PRO
五月 '250
在0个频道中
Get PRO
四月 '250
在0个频道中
Get PRO
三月 '250
在0个频道中
Get PRO
二月 '250
在0个频道中
Get PRO
一月 '250
在0个频道中
Get PRO
十二月 '24
+3
在0个频道中
Get PRO
十一月 '24
+126
在0个频道中
Get PRO
十月 '240
在0个频道中
Get PRO
九月 '24
+16
在0个频道中
Get PRO
八月 '24
+272
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 30 十月 | +1 | |||
| 29 十月 | +5 | |||
| 28 十月 | +3 | |||
| 27 十月 | +6 | |||
| 26 十月 | +8 | |||
| 25 十月 | +9 | |||
| 24 十月 | +44 | |||
| 23 十月 | 0 | |||
| 22 十月 | 0 | |||
| 21 十月 | 0 | |||
| 20 十月 | 0 | |||
| 19 十月 | 0 | |||
| 18 十月 | 0 | |||
| 17 十月 | 0 | |||
| 16 十月 | 0 | |||
| 15 十月 | 0 | |||
| 14 十月 | 0 | |||
| 13 十月 | 0 | |||
| 12 十月 | 0 | |||
| 11 十月 | 0 |
频道帖子
| 2 | 没有文字... | 194 |
| 3 | 没有文字... | 210 |
| 4 |  Как мы шли влево. Часть 1: сначала разобрались с багами 👈
В компании преобладало ручное тестирование. Автоматизацией занималась отдельная команда: она покрывала регресс преимущественно на уровне API — Python + pytest.
Функциональность начинали проверять, когда реализация уже была готова, а PR передан тестировщику для локального тестирования.
Конечно, QA подключались раньше: изучали документацию, уточняли требования, писали тест-кейсы. Это тоже часть shift-left. Но хотелось понять, какие ещё проверки можно перенести на более ранние этапы.
🔎 Начал с анализа дефектов
Я пошёл по пути, который уже использовал на других проектах: взял баги за несколько месяцев, обнаруженные при ручном тестировании.
Разбирал причины: ошибки бизнес-логики, расхождения контрактов, неверные типы данных, проблемы взаимодействия компонентов и другие. Для каждого дефекта оценивал, какой автоматизированной проверкой его потенциально можно было обнаружить раньше.
Работу с требованиями в эту оценку не включал — хотел отдельно посмотреть на возможности автоматизированных технических проверок.
📊 Получилась такая картина:
🔹 54% — потенциально обнаруживаются unit/component-тестами.
🔹 29% — API- и интеграционными проверками.
🔹 17% — в рамках разбора оставил за ручным тестированием.
То есть для 83% дефектов из выборки удалось определить потенциальную проверку на более раннем этапе. Напомню: все эти дефекты мы фактически нашли руками, уже на готовой реализации.
Разумеется, это не означает, что достаточно написать тесты — и 83% багов исчезнут. Когда причина уже известна, придумать подходящую проверку проще. Заранее предусмотреть всё невозможно, а сами автотесты тоже могут содержать ошибки.
Но масштаб показательный. Даже если удастся раньше обнаруживать 30% таких дефектов, это уже сократит количество возвратов в разработку и повторных проверок.
🛠 Что с этим делать дальше
С unit-тестами следующий шаг относительно понятен: показать разработчикам конкретные примеры и обсудить пробелы в покрытии.
А вот API-группу я разобрал подробнее, потому что здесь видел точку приложения усилий со стороны QA.
В ней были случаи, когда контракт не соответствовал ожиданиям клиента, возвращался неверный тип данных, компоненты некорректно взаимодействовали друг с другом. Иногда базовый сценарий фичи вообще не работал — задачу приходилось сразу возвращать на доработку.
Такие проблемы хотелось обнаруживать до передачи изменений на ручное тестирование. Часть проверок можно выполнять без запуска приложения, другие — на сервисе, поднятом во временном окружении внутри CI.
После этого разбора появилась конкретная отправная точка: начать с API-проверок и постепенно встроить их в процесс разработки.
➡️ В следующем посте расскажу, какие подходы и инструменты я выбрал для внедрения, почему именно их и как они должны помочь с проблемами из этой выборки.
#QA #SDET #ShiftLeft #APITesting #CICD | 240 |
| 5 |  Меня недавно непонятно за что заблокировали в телеграмме. 🤷🏻♂️
Подал апелляцию в тот же день и почти две недели ни привета ни ответа.
Был уверен, конечно, что разблокируют. Ибо ничего вроде как не нарушал.
Но не был уверен на счет того насколько модерация впринципе работает в телеграм))
Оказывается работает. 😁
Сегодня разблокировали. Написали, чтоб я никому код не сообщал и отвязал неизвестные устройства.
Но кажется это скорей стандартная отписка. Сомневаюсь, что взломали. Вроде бы все защитные средства использую 😷
Вот этот код что только что получил 4013, никому не сообщал 🤷🏻♂️
В общем хорошо, что хорошо заканчивается) | 386 |
| 6 | Всем привет! 👋
Выпал из блогерской деятельности. Накопилась усталость. Много работы. В том числе в рамках «QA Спринта», который я провёл в июне. И, если честно, это был ПОЛНЫЙ ПРОВАЛ 🫣
По крайней мере, именно так мне казалось после первой недели.
На спринте было 7 человек, разбились на две команды. Тестировали LMS-платформу, а также форс-мажором оттестировали новую фичу в сервисе автопостинга.
Честно, ребята оказались не очень заряженными, плюс на это наложилась моя усталость.
Вообще суть спринта задумывалась как возможность для ребят получить практику в тестировании: поработать над реальной фичей, довести её до прода, получить фидбек от пользователей.
Но из 7 ребят активность проявляли буквально 3 человека.
Вероятно, не хватало моих качеств как аниматора 😅 Либо у ребят просто не было столько мотивации.
На второй неделе пообщались на тему использования ИИ. Как раз мой последний пост тут был об этом. Половина ребят на эту встречу не пришла. Но когда они узнали, что часть встречи была посвящена использованию ИИ в работе тестировщика, это заинтересовало всех.
И мой изначальный план пришлось менять. Потому что я совсем не планировал превращать это обучение в обучение работе с LLM.
Но в итоге мы разобрали, как внедрить ИИ в работу тестировщика и не превратить всё это в какой-то дикий треш, реализовали один MCP-сервер и ещё написали скиллы для агента. 🤷🏻♂️
Внедрили это в нашу работу. Конечно, не всё получилось идеально. Время было ограничено. За пару недель настроить процесс даже на скромном проекте невозможно.
Всё это добро протестировали на нашем проекте.
И тут проснулись даже те, кто после первой недели «выпал» из процесса.
В общем, под конец спринта активность зашкаливала. До сих пор с ребятами обсуждаем наши наработки. Кто-то уже начал внедрять их в свою работу.
Надеюсь это пойдет на пользу их проекту 😅 | 481 |
| 7 |  Сегодня с ребятами кто у меня на "QA спринте" прошел вебинар.
На моем примере рассмотрели QA/AI workspace в Codex.
Собственно основной костяк структуры, которую я использую, представлена на скрине.
Главная идея - разделить материалы по степени надежности и назначению:
👉domains/ отвечает на вопрос “о какой системе речь?”.
👉sources/ отвечает “где проверять факты?”.
👉playbooks/ отвечает “как выполнять работу?”.
👉evidence/ хранит доказательства конкретных проверок.
👉memory/ хранит только подтвержденное знание.
👉tmp/ отделяет мусор и промежуточные файлы от полезных артефактов.
👉AGENTS.md - общие инструкции для любого AI-агента, который работает в этом workspace: Codex, Cursor agent, Claude, другой ассистент, если он умеет читать такие файлы.
Конечно, всё прям охватить не получилось, но по базе прошлись. Показал как работает Codex в связке с Atlassian, с Qase.io, фигмой. Естесственно всё на примере проекта на котором ребята проходят практику. Чтобы сразу применяли навыки - "не отходя от кассы". | 615 |
| 8 | Чем ИИ помогает тестировщику?
Самое главное, на что я бы обратил внимание, - автоматизация рутинных задач.
Для меня основная рутина в тестировании - это создание тест-кейсов и заведение багов.
Давайте чуть подробнее разберём.
Тест-кейс
Пришла новая фича.
Надо изучить → накидать матрицу покрытия → составить чек-лист.
А хочется уже начать тестировать: пройтись по основному пути, покликать, начать исследовательское тестирование. Но сначала надо написать тест-кейсы.
Допустим, фича небольшая. Накидали 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 или любой другой ИИ 🤖
ИИ - это не замена тестировщика. Это инструмент, который может снять часть рутины и вернуть время на главное: думать, исследовать и находить проблемы до пользователей. | 415 |
| 9 |  На работе нам выдали корпоративного Клода. 😏
Наверное с год назад у меня была подписка на клод за 20 баксов или сколько она стоила, но из-за вечно мешающих работать лимитов я ушел к чату джипити. И с тех пор работаю в нем и когда появился у них Codex, то юзаю его.
Теперь буду переводить некоторые свои рабочие автоматизации на клода. Ну и изучать данный инструмент.
В инсте, ютубе, телеге из каждого утюга: "Клод то, Клод сё" - посмотрим насколько он крут и насколько удобней и мощней того же Codex.
Я как-то думал, что я круто работаю с ИИ, там скиллы, mcp всякие - саммари к таскам, тест-кейсики завожу через него, анализ фич делаю и тд. Но пообщался с ребятами, коллегами тестировщиками на днях...Некоторые такое творят с ИИ, что диву даешься. 🤯
А у вас на работе есть корпоративные ИИ инструменты? Если да то какие поделитесь в комментах плиз.
PS: ну что олды, кто скажет почему к посту я прилепил данное изображение? 👨🦳 тому почёт и моё уважение+))) | 404 |
| 10 |  Всем привет!
Первый момент, который я хочу обязательно подсветить:Нельзя просто написать в чатик: сгенерируй мне тест-кейсы по данному функицоналу. /и скидываете ему доку/Точнее можно и возможно в каких-то случаях он даже выдаст какую-то годную инфу.
Но, если вы хотите сделать себе помощника, инструмент с помощью которого вы будете экономить себе время, то к этому надо отнестись серьезно.
Самый простой вариант без лишней автоматизации и геоморроя это сделать себе "скилл" для нейронки. И при создании тест-кейсов использовать его.
Для этого не требуется каких-то высоких технических знаний. Это просто создание одного или группы файлов в формате .md
Я тестирвал так:
1. Просто промпт в ChatGPT
2. Промпт в ChatGPT + подготовленные файлы скиллы
3. Codex: создал папку проекта, разместил там доку + "скилл". И попросил написать тест кейс.
2 и 3 выдали лучший результат. Но с Codex понравился больше всего
Я думал сделать может воркшоп на эту тему. Или просто видео записать. 😅
Если интересно кидайте реакции. 🔥 | 453 |
| 11 | 🤖"ИИ заменит тестировщиков! Разработчиков! Аналитиков!"
Пришел и мой черед высказаться на данную тему...
Что происходит?
Мировая экономика живёт в режиме жёсткой оптимизации: быстрее выпускать продукт, дешевле поддерживать процессы и меньше тратить время людей на рутину.
Да, часть компаний внедряет ИИ просто потому, что это хайп и "так сейчас надо".
Но за хайпом стоит более жёсткая вещь: бизнес ищет способы ускоряться, сокращать косты и выживать в конкурентной гонке.
Будут ли сокращения?
Да, мы это уже видим.
Значит ли это, что люди больше не нужны?
Нет.
💥Но пропорции в работе уже меняются.
Мне кажется, здесь хорошо работает аналогия с конвейером Форда.
Не "один в один", конечно. Но по логике похоже.
Когда появился движущийся конвейер, ценность человека в процессе начала смещаться. Многие "ручные" работники мастера стали не нужны производству. Кто не могу перестроится увольнялся или его увольняли. Закрывались целые заводы. Но потом производство встаёт на новые рельсы.
Профессии не то что бы исчезли, они трансформировались.
И начался колосальный спрос на сотрудников. Не на мастера, который один собирает всё руками. А на людей, которые работают внутри нового процесса: держат качество, следят за стабильностью и понимают систему.
Людей требовалось еще больше, чем работало прежде на заводах.
Мне кажется, с ИИ в IT будет похожая история.
Сначала сокращения и перестройка.
Потом новый цикл найма.
Но нанимать будут уже не просто "руки", которые пишут код, тест-кейсы или документацию. Будут нужны люди, которые умеют работать с ИИ как с частью процесса.
С ИИ в IT мы переходим от роли "я всё пишу руками" к роли:
🔹 ставлю задачу
🔹 проектирую решение
🔹 проверяю результат
🔹 связываю части системы
🔹 отлавливаю ошибки ИИ
🔹 отвечаю за качество результата
Раньше специалист тратил много времени на генерацию базы: бойлерплейт, рутинные скрипты, типовые тест-кейсы, черновики документации. Теперь ИИ может выдать эту базу за секунды. Но это не значит, что работа закончилась. 🙅♂️
Теперь важно понимать, что он выдал, где наврал, что не учёл, какие риски пропустил и как это встроить в продукт.
Мы больше не просто крутим гайки вручную.
Мы учимся управлять умным конвейером.
И выигрывает не тот, кто громче всех говорит: “ИИ меня не заменит”.
А тот, кто умеет использовать ИИ, но остаётся профессионалом: думает, проверяет, задаёт правильные вопросы и отвечает за результат.
🧙♂️ Мой вывод простой:
ИИ не заменит сильного специалиста. Но специалист с ИИ легко обгонит того, кто продолжает делать всю рутину руками и принципиально не перестраивается.
Я не думаю, что история закончится тем, что "люди больше не нужны".
Скорее рынок проходит фазу перестройки.
Когда процессы стабилизируются, людей снова будут нанимать.
Но требования будут другими.
Никому не навязываю своё видение.
Просто мысли которыми хотелось поделиться.
--------
Добавляйся в контакты на LinkendIn | Подписывайся в MAX | 424 |
| 12 |  💬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 кодовое слово «СПРИНТ».
Коротко пообщаемся, на предмет ожиданий и мотивации. И если будет мэтч поработаем. 🤝 | 395 |
| 13 | Всем привет! 👋
Кто следит хоть немножко за моими редкими постами тот знает, что у меня есть несколько проектов, которые я делаю в свободное время. Я об этом не раз писал и зазывал ребят кому не хватает практики потестировать мои проекты.
Один из них это EasyPost - сервис отложенного постинга в Telegram и Max.
В этом году у меня было несколько человек на месячной индивидуальной практике, где мы именно что разрабатывали, тестировали и внедряли новые фичи, в том числе и на данном проекте.
Ребятам огромный респект🙌, нашли много багов, но и, конечно, многое найти ещё не успели. Есть много UX решений, которые нужно доработать, баги которые поправить.
Но сейчас мне очень сильно не хватает именно пользовательского фидбека.
Именно поэтому я хочу уже запустить проект в жизнь пока в рамках бета-теста. Хочется, чтобы пользователи начали использовать приложение по назначению и возвращались с обратной связью.
Я хочу отпалировать то что уже реализовано.
А это:
👉 Создание постов в удобном редакторе.
👉Предпросмотр. Пишите пост и сразу видите как он будет выглядеть в мессенджере. Не уверены? Отправьте тестовое сообщение оно придет к вам в личку от бота.
👉 Можете сохранять черновики планируемых постов.
👉Поддержка изображений и видео.
🔥Функция relay. Это переопубликация поста из Telegram в Max. Если вы создаете пост в телеграм обычным способом он опубликуется автоматически в Max. Поддерживает в том числе кружки и голосовые.
Пока ссылок не даю. Идет подготовка инфраструктуры. Сегодня или завтра опубликую новый пост.
Кстати данное сообщение опубликовано с помощью данного сервиса. 💙 | 436 |
| 14 |  没有文字... | 379 |
| 15 |  В инсте, в сторис запустил интерактивку. Но чёт потом подумал, что наверное в телеге получше. Тут комментарии хоть можно расписать. )
Идея такая, вспоминаю баги с прода свои или чужие. Рассказываю о них с точки зрения конечного пользователя.
В комментарии начинаем обсуждать. Интересно именно послушать как бы кто действовал.
Особенно призываю поучаствовать ребят кто без опыта. Только учится или обучился и ищет работу.
Остальные тоже могут у кого желание есть.
В чем профит? Будем прокачиваться в мышлении, в локализации. Учится задавать правильные вопросы. Как говаривал кто-то умный: плохой вопрос это незаданный вопрос.
Я всегда был против подхода: "завел баг и забыл",
Всегда хочется максимально точно его локализовать.
Но порой даже непонятно с какой стороны взяться.
Предыстория:
Вы QA тестируете софт в котором надо работать со сканером штрихкодов. Условно касса в магазине, софт логистический, или в пунктах выдачи заказов сидят вот тоже пикают сканерами товары.
В общем сканируем штрих-код получаем информацию о каком-то объекте.
Но на проде случилась беда: определенные штрихкода не сканируются, выдается ошибка "Данный товар уже отсканирован ранее".
Это не блокирует весь процесс. Есть обходной путь, но работу замедляет.
Штрихкод: BC-12345678 и аналогичные проблемные
Штрихкод вида 9876543210 проходят без проблем.
Как бы вы локализовывали проблему?
Можно мне вопросы задавать. Я буду в роли конечного пользователя, аналитика в общем кого угодно)
Пишите в коментах
👇👇👇👇👇👇👇👇 | 499 |
| 16 | Не так давно я описывал свои подходы (офигеть полгода прошло) по формированию тестовой модели на проекте, а так же организацию коллекций в 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 | 469 |
| 17 | 💡 На выходных проверял домашки по Postman.
Всего было 4 работы.
Все разные, по-своему интересные.
Но одна прямо выделилась -
самая объёмная и проработанная.
На разбор у меня ушло 3 больших сообщения в Telegram. 🤯
И знаете, что мне нравится в таких моментах?
Не просто проверить "правильно / неправильно",
а именно разобрать, почему так и как сделать лучше.
В этой работе было всё:
-> цепочка запросов
-> переменные
-> скрипты
-> тесты
-> и даже заход на более продвинутые вещи
И вот тут начинается самое интересное.
Почти всегда проблема не в том, что "код не верный".
А в том, что:
-> где-то переменные перепутаны
-> где-то шаги не связаны
-> где-то логика ломается
-> а где-то тест "зелёный", но на самом деле ничего не проверяет
И именно такие разборы дают больше всего пользы, как ученику(я надеюсь), но и мне.
Потому что это уже не теория, а реальные ошибки, которые потом ловятся в работе.
А для меня польза не забыть какие-то базовые вещи.
Это как на CodeWars решать каждый день задачки, чтоб держать себя в тонусе)
Хотя я вот себя никак не могу приучить решать регулярно задачки)) | 523 |
| 18 |  👋 Всем привет! Давно хотел спросить ваше мнение про новый интерфейc Postman.
Как вам он?
Я, если честно, в восторге! Мне вообще нравятся интерфейсы в таком linear app стиле.
Он сразу стал не таким тяжелым.
Свободным что ли.
Элементы аккуратные, компактные.
Мне стало намного приятней в нём работать.
Единственное, теперь хоть курс переписывай. Так как уже были ребята, кто задавался вопросом, что не могут что-то найти. Потому что в видеоуроках какая-то кнопка в одном месте, а в новом интерфейсе она уже в другом 🤷🏻♂️
А как вам новый интерфейс? 🙂
🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman | 558 |
| 19 |  🔻 🚨 🔠🔠🔠🔠 🚨 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 | 902 |
| 20 |  Вот и пришла весна! 🌿
Хотя по сугробам на улицах Москвы так сразу и не скажешь 🙂
В честь первых дней весны делаю скидку 20% на курс «Postman с нуля до профи».
Этот курс - не про “потыкать запросики”.
Мы учимся собирать из запросов цепочку бизнес-процесса, чтобы:
1. быстро проверять end-to-end сценарии руками, когда нужно “прям сейчас”,
2. и иметь готовый инструмент, который ускоряет тестирование и помогает команде.
По сути, ты собираешь коллекцию так, чтобы она была похожа на мини-автотест: запустил - и сразу видно, где всё ок, а где что-то сломалось.
Что по итогу ты будешь уметь:
- собирать коллекции под конкретные цели (смоук/регресс/проверка фичи);
- настраивать окружения и переменные, передавать данные из запроса в запрос;
- за пару минут вручную “прокликивать” бизнес-процесс;
- запускать сценарии автоматом в Runner или через Newman;
- добавлять проверки и простые скрипты (tests + базовый JS) - чтобы коллекция не просто выполнялась, а сама проверяла результат и показывала понятный “зелёный/красный” итог;
- и, конечно, увереннее отвечать на вопросы по Postman на собеседованиях (без ощущения “я вроде пользовался, но не уверен”).
Полную программу курса можно посмотреть 👉 ЗДЕСЬ
Все вопросы можно задать здесь или мне в личку @EugSych
🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman | 509 |
