Про Мир IT

Бывало ли у вас так, вы начинаете регресс и выясняется, что одна из систем вдруг не работает? И это блокирует всю систему и блочит регресс? Оказывается одна из систем исправила один небольшой баг и это поломало контракт. И к примеру, встала очередь в кафка.  Такое может случиться и на релизе. В моей практике такое бывало.  ⚠️ Это нас приводит к важности контрактного тестирования, как одного из гейтов релизного пайплайна. 👇👇👇👇👇👇 Контрактное тестирование - это когда команда ведет разработку так, чтобы такие изменения ловились до релиза, автоматически в 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

Наткнулся я на статистику hh.ru по количеству вакансий тестировщика по годам. Как менялось количество вакансий с 2021 по 2025 включительно. Там деление по регионам: Москва, СПб, Вся Россия Я взял только Москву. И можно посмотреть по уровню специалиста: Джуниор, Мидл, Сеньор. Предполагаю, что вакансии для статистики брались примерно так: Джуниор - вакансии, где указано опыт не требуется, либо до года. Мидл - 1-3 года опыта Сеньор - больше 3 лет опыта Собственно сама статистика на приложенных скринах. Вообще к чему я решил это выложить. На самом деле часто читаю, что джунам и начинающим тестировщикам сейчас прям очень тяжело. Вакансий мало, конкуренция высокая. Да да, я знаю что плохо не только начинающим. Вся айтишка страдает. Просто я чаще встречаю именно мнение, что джунам мега тяжело. Возможно опытные меньше делятся своей болью 🤷🏻‍♂️ Но посмотришь статистику, так вроде бы Сеньоры, то поболее пострадали. И количество вакансий упало в разы и зарплата не растет. У джунов же тренд восходящий. Интересная статистика) PS: Я исследования не проводил. Просто наткнулся на страничку и решил поделится мыслями ;) 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Сегодня хочу немного поворчать 😄 Иногда общаюсь с новичками в QA, разбираем резюме. И почти всегда звучит одно и то же: «Всем нужен опыт. А где его взять?» Контента на эту тему - море. Площадки для практики есть. Опенсорс есть. Учебные стенды есть. Но многие приходят, смотрят… и уходят. Почему? 👉 непонятно, с какого боку подойти 👉 непонятен профит 👉 нужен человек, который возьмёт за руку и поведёт. Бесплатно, конечно 🙂 А теперь реальность: на работе (особенно в стартапах) легко оказаться одним QA. Без документации. Без онбординга. Без ментора. Где, если не на таких открытых проектах(где вас не ведут за ручку) получать подобные навыки? Поэтому не ждите идеальных условий! Кто берётся и начинает делать - выходит на результат быстрее. Практикуйтесь параллельно с поиском: каждый месяц добавляйте в резюме "+1 месяц опыта". Не ждите волшебника в голубом вертолёте 🚁 который прилетит и за вас всё сделает. Удачи! 🫡 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Всем привет! 👋 В прошлый раз мы разобрали отчёт k6 и научились понимать, что такое avg / p(95) / vus / iterations. Но дальше у всех закономерный вопрос: Ок… я получил какие-то циферки, а это “норм” или “плохо”? И вот тут начинается классическая боль: смотришь на данные и пытаешься “на глаз” решить, выдержала система нагрузку или нет. =)) ✅ Решение = Thresholds (пороги). Это правила, которые говорят k6:

“Если метрики вышли за рамки - тест считается проваленным.”

То есть прогон становится автоматически зелёным или красным, а не “мне кажется норм”. 🎯 Что такое Thresholds простыми словами Thresholds = SLO/ожидания к системе, записанные прямо в сценарии k6. Примеры понятных требований: 🚫ошибок должно быть меньше 1% 🚫 95% запросов должны быть быстрее X ms 🚫проверки (checks) должны проходить почти всегда ✅ Добавляем thresholds в k6 (минимальный пример)

import http from "k6/http";
import { check, sleep } from "k6";

const BASE_URL = "https://quickpizza.grafana.com";

export const options = {
  vus: 5,
  duration: "5s",

  thresholds: {
    http_req_failed: ["rate<0.01"],        // ошибок меньше 1%
    http_req_duration: ["p(95)<800"],      // 95% запросов быстрее 800ms
    checks: ["rate>0.99"],                 // 99% checks успешны
  },
};

export default function () {
  const restrictions = {
    maxCaloriesPerSlice: 500,
    mustBeVegetarian: false,
    excludedIngredients: ["pepperoni"],
    excludedTools: ["knife"],
    maxNumberOfToppings: 6,
    minNumberOfToppings: 2,
  };

  let res = http.post(
    `${BASE_URL}/api/pizza`,
    JSON.stringify(restrictions),
    {
      headers: {
        "Content-Type": "application/json",
        "Authorization": "token abcdef0123456789",
      },
    }
  );

  let ok = check(res, {
    "status is 200": (r) => r.status === 200,
  });

  if (ok) {
    let body = res.json();
    console.log(`${body.pizza.name} (${body.pizza.ingredients.length} ingredients)`);
  } else {
    console.log(`Request failed. Status=${res.status}`);
  }

  sleep(1);
}

🔥 Разбираем смысл 1) http_req_failed: rate<0.01 Это доля неудачных запросов. 0.01 = 1%. То есть: из 1000 запросов максимум 10 могут “упасть” (таймауты/сеть/5xx и т.п.) 2) http_req_duration: p(95)<800 Тот самый p95, только теперь он не “для красоты”, а как критерий качества. 95% всех запросов должны уложиться в 800ms (уложились → ✅, нет → ❌) 3) checks: rate>0.99 Если у тебя есть проверки (например status=200), можно требовать: не меньше 99% успешных checks Это удобно, если checks несколько и нужен общий критерий. 🟢🟥 Что будет в результате После запуска k6 в конце покажет: → какие thresholds PASS → какие FAIL И ты сразу видишь: система выдержала или нет, без гадания на кофейной гуще. ⚠️ Важно: значения для thresholds мы берем не “с потолка” 800ms / 1% / 99% - это примеры, чтобы было понятно, как работает механика. В реальной жизни thresholds берутся из: ✔️ продуктовых ожиданий (что “нормально” для пользователя), ✔️ метрик прода, ✔️ или договорённостей внутри команды. И да: baseline = точка отсчёта, но он сам по себе не доказывает, что “всё хорошо”. 👉 В следующем посте разберём самое важное: как выбрать эти цифры и как понять, что уже на baseline всё плохо. Если было полезно - поддержи реакцией 🔥 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Всем привет! 👋 Я тут решил запилить свой проект - EasyPost 🛠 Это планировщик постов для Telegram. Почему? На самом деле как и с LMS системой решение пришло из моей боли. Я редко пишу посты для телеграма сразу в телеграм. Чаще сначала в notion, или в каком-нибудь редакторе. Выглядит примерно так:

Делаю красивый текст в Notion → копирую в Telegram → и... форматирование улетает в космос.

Приходиться текст прям тут форматировать заново. Минус еще в том, что редактор приложения телеграм ограничен. Через html(то есть через бота) возможностей больше. Все кто ведет свой канал, как правило, если он небольшой(как у меня), то публикуют руками через телеграм, у кого побольше или несколько каналов, то используют сервис какой-то, либо своего бота. В общем пошёл искать планировщик(честно сказать не особо запаривался поиском): 💲 платные (там реально круто, но мне не нужны половина фич, а платить $20/мес не хотелось) 🆓 бесплатные, но “1 канал / 1 бот / куча ограничений” 🖕 или просто кривенькие Короче, подумал: “ладно, сделаю свой”. Собственно и сделал. Предыдущий пост публиковал уже через свой планировщик. Конечно, я хотел чтоб был нормальный редактор. Чтобы было так: Делаю красивый текст в Notion → копирую в Telegram → И сразу публику - не парясь с форматированием. И я ещё наивно думал, что редактор - это вообще не проблема: типа возьму готовое решение, прикручу и оно там само волшебство творить будет. Ага, конечно 😂 Редактор оказался самой больной частью, и он до сих пор в стадии “полировки”: хочется много чего поправить. И вот тут главный вопрос: а сколько багов я ещё просто не увидел? 👀 Поэтому зову вас потестировать stage ✅ Особенно если вы новичок в тестировании и вам нужна реальная практика на живом продукте - это прям оно. 📌 Вся инфа (ссылки, мини-дока, куда заводить баги) — здесь: https://t.me/testerschool/375/376 Я ещё запишу короткое демо-видео. Если народу наберётся нормально - сделаем созвон и разберём самые интересные баги/наблюдения. Если готовы - приходите, потыкайте, поломайте 🙌 И просто так тоже заходите посмотреть. Буду рад любому фидбэку. Философия приложения - это максимум User Friendly, поэтому если вдруг что-то встречается непонятное обязательно пишите - мне это очень поможет. UPD: Сам планировщик пока еще не продакшине, пока у меня он в тестировании на тестовом стенде Надеюсь в две-три недели привести в божеский вид и уже опубликоваться. 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

✨ С Новым годом и наступающим Рождеством! Начало года - странное время. С одной стороны, хочется отдыха и тишины. С другой - появляется ощущение:

"Хочется начать по-новому. Чуть увереннее. Чуть сильнее."

Если у тебя тоже так - я тебя очень понимаю. Поэтому на старт года я сделал новогоднюю скидку -26% на обучение, которое помогает прокачать навыки без перегруза и хаоса. 📌 Новогодний промокод: NEWYEAR26 🎁 Это не про "начать новую жизнь с понедельника". Это про маленький, но правильный шаг - инвестировать в себя и свой рост в спокойном темпе. ⏳ Акция действует до 15.01.2026 Если давно присматривались к моему курсу "Postman с нуля до профи" - сейчас тот самый момент 🤍 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🧠 Как я организую скрипты и коллекции в Postman Периодически, в рамках моего 📘 Курса по Postman, мне прилетает вопрос как я организовываю работу с АПИ в Постман на проекте. И пару дней назад вновь подобный вопрос прилетеле и я подумал почему бы не поделится ответом в телеграм-канале. 📁 Общий подход Я стараюсь выстраивать коллекции как поддерживаемую структуру, а не просто как набор эндпоинтов. --- 📌 Коллекции 🔹 Swagger-коллекцию держу отдельно - как справочную (через Fork или просто рядом). 🔹 Для тестирования и автоматизации использую отдельные коллекции под реальные бизнес-процессы: - ориентируюсь на фактические запросы в системе - сверяюсь с devtools / Charles - повторяю реальные цепочки вызовов API 👉 Такие коллекции отлично подходят для: - e2e-проверок - регресса - дальнейшей автоматизации (даже в рамках Postman) --- 🗂 Структура внутри коллекции Запросы группирую по логике процесса, например: Авторизация → Ресурсы → Действия Так цепочки читаются последовательно и понятны без лишних комментариев. --- ⚙️ Pre-request scripts Использую для подготовки данных: - установка заголовков и токенов - генерация тестовых данных - подготовка состояния перед запросом 🔁 Общую логику выношу: - на уровень коллекции - или папок В самих запросах оставляю только специфичную часть. --- ✅ Post-response (Tests) В test-скриптах: - проверяю ответы - сохраняю данные для следующих шагов (токены, id ресурсов и т.д.) Использую: - collection variables - environment variables --- 🧩 Переменные 🟢 Окружение - параметры среды (baseUrl, токены, конфигурация) 🟡 Коллекция - данные конкретного сценария 🔴 Глобальные переменные - не использую --- ♻️ Рефакторинг и отладка Всё, что начинает дублироваться - 👉 выношу в общие скрипты. Для отладки обязательно использую console.log, особенно: - при запуске e2e-цепочек - чтобы понять что, где и на каком шаге упало 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🧠 Про тест-дизайн на собеседования QA Всем привет! 👋 У меня тут 20 дней было затишье. На работе высокий предновогодний сезон. Надо зарелизить всё что не успели за год =)) Но дело не только в этом. Иногда просто не хватает энергии и мотивации. Особенно когда под постами, видео нету реакции и комментариев. Ладно, сейчас не об этом =) Не так давно в линкендин увидел пост от рекрутера, который жаловался, что кандидаты пишут что знают техники тест-дизайна, а на собеседовании не могут продемонстрировать своё знание. Я конечно свечку не держал, но встречаются часто интервьюеры, которые задают вопросы: "Какие техники тест-дизайна знаете?" "А расскажите как применяете на практике?" и всё в таком духе. Никогда этого не понимал. Ведь как это происходит на проектах? Прилетает фича тестировщику и он такой: "Так, какую бы технику тест-дизайна сейчас применить?" 🤔 Ну нет конечно! Он просто смотрит на задачу и начинает думать (по крайней мере, хочется в это верить 😅): - какие здесь ограничения? - какие комбинации входных данных возможны? - где система может повести себя странно? - где ошибка реально ударит по бизнесу? - что может сломаться неочевидно? Из этих вопросов и рождаются проверки. А уже потом, при желании, всё это можно разложить по красивым названиям из учебников. Которые опытный тестировщик вполне мог и подзабыть (ну мы же не ангелы 😇). 💡 Где на самом деле начинается проблема? Не там, где человек не помнит термин и не там, где не может красиво его объяснить. Проблема начинается тогда, когда: - нет структуры мышления - всё тестирование сводится к паре шаблонов: «проверю граничные значения» «накину негативных проверок» И на этом всё. 🤷‍♂️ Поэтому вопросы на интервью в стиле: «Расскажите, как вы применяете такую-то технику тест-дизайна» часто дают странный эффект. Человек начинает вспоминать формулировки, нервничать и угадывать, что от него хотят услышать. И ответ получается смазанный. Так как для собеседования надо перестроить голову, чтоб она работала под собеседование. Хотя на практике всё работает иначе. 🧩 На мой взгляд, гораздо полезнее: - дать нормальный практический кейс - попросить рассказать, как он будет проверять задачу и почему именно так - без привязки к названиям техник и желательно ещё в этот момент поддерживать диалог, а не просто тупо сидеть слушать. В таком разговоре видно ход мысли кандидата. Очень хорошо можно понять какие техники он использует. Даже если ни одно умное название так и не прозвучит 🙂 📌 Когда общаешься с кандидатом через реальные задачи, как интервьюер ты прекрасно видишь всю нужную теорию — просто без академической обёртки.

Всем привет! 👋 В предыдущем посте мы с вами запустили простенький сценарий по нагрузочному тестированию. У всех всё получилось? Пишите ваши результаты в комментариях! 🔍 Разбираем отчёт k6: что это вообще значит? Ок, вы запустили базовый сценарий, получили красивый отчёт… и зависли. Я, например, в свое время точно завис. Что означают все эти avg, p(95), iterations, vus? Давайте разберёмся - без лишней теории, только практический смысл. Отчет стартует со слов TOTAL RESULTS ✅ Checks - это как такие мини аналог ассертов, которые есть в Postman, и фреймворках автоматизации. В нашем скрипте одна проверка - на status code 200. checks_total: сколько всего проверок было за весь прогон. checks_succeeded: сколько из них прошли успешно, то есть вернулся на наш запрос status code=200. checks_failed: соответственно, сколько наших проверок провалилось. ✓ Подобные проверки дают нам понять насколько стабильно наша система работает под нагрузкой. Если с увеличением нагрузки checks_failed начинает тоже увеличиваться - вероятно у нас есть где-то проблемы. 🌐 HTTP - скорость и стабильность отклика http_req_duration: время отклика сервера на наш запрос. Всем известно чем быстрей тем лучше! Никто не любит, когда после нажатия на кнопку приложение еще 10 секунд думает. Здесь главное понимать, что тут по сути нет какого-то золотого стандарта. Всё зависит от системы, от архитектуры, от операции, которые выполняются при вызове энд-поинта. Пробежимся вкратце по сокращениям avg - средняя температура по палате. med - медиана, надежнее чем средняя, точнее устойчивее к "случайным" всплескам, которые могут быть. p(90) / p(95) - процентили по времени отклика. Например, если указано как на скриншоте p(90)=2.69s, p(95)=2.69s, это означает, что 90% и 95% запросов были быстрее 2.69s. http_req_failed: процент ошибок. → 0.00% — всё стабильно. это встроенная метрика, которая фиксирует любую неудачу при выполнении HTTP‑запроса. "Неудача" - это может быть таймаут, сетевая какая-нибудь ошибка, либо status code который не соответствует ожидаемому (по умолчанию k6 считает успешными 2хх и 3хх статус коды) http_reqs: сколько всего запросов было отправлено во время нашего запуска. метрика показывает интенсивность нагрузки. То есть по этому показателю ты можешь понять корректно ли настроен твой сценарий. Если ты моделируешь работу 5 сотрудников, которые каждые 10 секунд проходят какой-то сценарий, то ты можешь высчитать сколько примерно запросов должно быть за время твоего теста. Если цифра сильно отличается, то значит надо корректировать либо vus, duration, либо саму логику сценария. 🔁 Execution — как отрабатывали VU iterations: сколько всего итераций было выполнено. iteration_duration: сколько длилась одна итерация. → Если итерации по 1.3 сек, а тест длился 5 сек — всё нормально, они шли параллельно: у нас 5 виртуальных пользователя, одна итерация в среднем 1,3 → то есть один пользователь за 5 секунд успевает выполнить (5/1.3=3.8) почти 4 итерации, всего у нас 5 VU, 5*4=20 - всё сходится. vus_max = 5: сколько максимум виртуальных пользователей мы запускаем. vus = 5: значит на протяжении всего теста всегда было ровно 5 активных VU. Никогда не было меньше, никогда не было больше. Что соответствует нашему сценарию. Если бы у нас был сценарий с нарастающей или переменной нагрузкой, где количество VU могло меняться в процессе теста, то значение было бы другим. 📡 Network - объём данных data_received / data_sent: сколько данных было получено / передано. → Полезно понимать, если API гоняет большие payload'ы. 🎯 И это всё что нужно? Это базовые метрики, которые уже идут по умолчанию из коробки k6. Конечно, на практике используют дополнительные метрики, которые подбираются индивидуально под бизнес-логику и цели нагрузки. Если было интересно и полезно - поддержи реакцией! 🔥 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🚀 Первый нагрузочный сценарий Если вы успешно установили k6(качаем с гитхаб), давайте сделаем простенький базовый нагрузочный сценарий. Перед тем как перейти к коду, создайте отдельный каталог, в котором будете хранить свои скрипты. Откройте консоль — например, PowerShell — и перейдите в этот каталог. Не переживайте, если вы не знаете JavaScript — мы не будем писать код с нуля. Я воспользуюсь специальной «песочницей» от Grafana - QuickPizza. В её GitHub‑репозитории лежит масса готовых шаблонов. Для примера я возьму скрипт 01.basic.js и слегка скорректирую BASE_URL , чтобы он указывал на QuickPizza:

import http from "k6/http";
import { check, sleep } from "k6";

const BASE_URL = "https://quickpizza.grafana.com";

export const options = {
  vus: 5,
  duration: '5s',
};

export default function () {
  let restrictions = {
    maxCaloriesPerSlice: 500,
    mustBeVegetarian: false,
    excludedIngredients: ["pepperoni"],
    excludedTools: ["knife"],
    maxNumberOfToppings: 6,
    minNumberOfToppings: 2
  };

  let res = http.post(`${BASE_URL}/api/pizza`, JSON.stringify(restrictions), {
    headers: {
      "Content-Type": "application/json",
      "Authorization": "token abcdef0123456789",
    },
  });

  check(res, { "status is 200": (r) => r.status === 200 });
  console.log(`${res.json().pizza.name} (${res.json().pizza.ingredients.length} ingredients)`);
  sleep(1);
}

Далее сохраняем в созданном каталоге как basic.js или любое другое имя. Затем в терминале(например PowerShell) выполняем команду:

k6 run basic.js

Начнется выполнение нагрузки. По завершении которой прямо в терминале вам будет выведен отчет по метриках*. *Как читать эти метрики мы поговорим в будущих постах и видео 🥸 📊 Что делает этот сценарий В options указываются настройки нагрузки: 5 виртуальных пользователей, продолжительность 5 секунд. Ну и функция в которой заложено выполнение простенького бизнес сценария: Отправляется POST запрос с параметрами пиццы, которую мы хотим заказать. - Каждый из 5 пользователей отправляет запрос на API QuickPizza параллельно друг-другу на протяжении 5 секунд. - Скрипт проверяет, что сервер отвечает со статусом 200 OK. - Выводит название и количество ингредиентов у сгенерированной пиццы. И самое важное - собирает метрики: время отклика, процент ошибок, количество запросов в секунду. 🎯 Зачем это нужно QuickPizza крайне простое приложение, поэтому и скрипт нагрузки тоже крайне простой, но уже полезный! Что он нам показывает - что API действительно работает под нагрузкой, - что бизнес‑логика (ограничения на пиццу) учитывается, - и как быстро сервис отвечает при одновременных запросах. Повторюсь это базовый сценарий, но он уже даёт полезную информацию: можно увидеть время отклика, процент ошибок и убедиться, что сервис не ломается при росте трафика. Как дополнение вы уже можете посмотреть графики в Grafana. Но учтите это демо площадка и само приложение и Grafana может ужасно глючить. У меня при подготовке поста Grafana жутко тормозила. На этом пока всё! Пишите о ваших успехах в комментариях. Если, что-то не получилось тоже пишите! И, конечно, если пост понравился и хочется продолжения - кидайте реакцию! 🔥 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🚀 Почему я выбрал k6 для нагрузочного тестирования Если ждёте какое-то офигенное техническое обоснование выбора, то вы его не дождетесь)) Когда меня попросили провести нагрузку, то встал вопрос выбора инструмента. У нас в компании пока нету каких-то установленных стандртов. Поэтому первым делом я скачал Apache JMeter. У меня уже был опыт работы с ним, значительно больше чем с k6. 🤷🏻‍♂️ Но JMeter у меня не запустился: не знаю почему может Java не обновлена или не установлена. Я не стал разбираться. Не хотел тратить на это время. В итоге я пошел в гитхаб и скачал там последнюю версию k6 для Windows. 📝 JMeter против k6 k6 установился без проблем. Думаю и у вас установится с пол пинка. У него нет зависимостей. Это CLI утилита поэтому проблем в принципе не должно быть. На самом деле ключевое отличие это то, что Jmeter это GUI инструмент. Поэтому тут вообще не обязательно знать язык программирования. Собственно так я и делал несколько лет назад, когда впервые познакомился с нагрузкой. В k6 всё иначе: сценарии пишутся полностью на JavaScript. Но при этом код не сложный, хоть в блокноте пиши. Я так и делал с первыми сценариями для последней нагрузке. Так как сценарии пишутся скриптами они удобно версионируются в гит и, соответственно, интегрируются в пайплайны. В общем инструмент более гибкий. Так же Jmeter написан на Java, а k6 на Go. Что делает первый более тяжелым, а k6 более легким и быстрым. 🎯 Почему я остановился на k6 Сценарии на JavaScript удобно и современно и мне отличная допоkнительная практика с JavaScript Отличная интеграция с Grafana - можно сразу наблюдать метрики и графики не тратя время на танцы с бубном. Тем более у нас на проекте Grafana. Ладно...к черту лирику. Давайте просто запустим первый скрипт нагрузки. 👇👇👇👇👇

🔥 Помните времена, когда от тестировщика ждали только ручное тестирование? Когда знание языка программирования было «приятным бонусом», который выделял тебя среди десятков резюме? Сейчас всё поменялось. Автоматизация стала не «хорошо бы знать», а фактически обязательным навыком. Стоит открыть вакансии - и в каждой второй, если не чаще, нужно знать какой-то язык программирования, понимать какой-то фреймворк. А строчка «будет плюсом» внезапно превратилась в полку: нагрузка, безопасность, CI/CD — и так далее по списку. И вот что интересно. Раньше вакансии «ручное + авто + нагрузка» встречались раз в год. Сегодня - это чуть ли не норма. Компании хотят универсалов, которые способны закрывать сразу несколько задач. Для бизнеса это экономия. Для тестировщика - вызов. И парадокс времени в том, что рынок под давлением: 💸 зарплаты почти не растут (что не скажешь о инфляции) ⚙️ требований - всё больше 📉 компании экономят на штате, но не на ожиданиях Конкурентов на одну вакансию очень много. Выигрывают те, кто умеет больше. Универсалы находят работу быстрее и увереннее держатся в переговорах. А такой навык, как нагрузочное тестирование, всё чаще становится тем самым «плюсом», который помогает пройти отбор и удержать хорошие условия. QA давно перестал быть "простым кликером по кнопочкам". Если его кто-то таким считал. Сегодня это инженер, который понимает архитектуру, работает с метриками, видит слабые места системы и помогает бизнесу пережить реальные пиковые нагрузки. К чему я вообще это всё рассказываю? Сейчас я готовлю серию постов, роликов и небольшое обучение по проведению нагрузочного тестирования с помощью k6. В следующих постах покажу, как нагрузочное тестирование с k6 может стать вашим реальным конкурентным преимуществом — особенно сейчас. Если эта тема вам интересна - поддержите пожалуйста реакцией 🔥 Любого автора ваша поддержка очень мотивирует. 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

➡️➡️➡️Часть 2. Обновления Postman. Ноябрь.⬅️⬅️⬅️ 11.70.5 - 6 ноября 2025 ⭐️Поддержка UDS(Unix Domain Sockets) и Named Pipes 👍 Это достаточно крутое нововведение для тех кто тестирует микросервисы. Внутренние сервисы как правило общаются не через HTTP, а используют сокет соединения(в Unix системах) или пайпы(Named Pipes) в Windows. Если раньше приходилось использовать "костыльные" решения, то теперь можно использовать напрямую, macOS and Linux: unix:/tmp/local-service.sock:/hello Windows: unix://./pipe/local-service/hello 11.70.6 - 7 ноября 2025 ⭐️Создание Jira-тасок прямо из раннера. Заводить баги сразу в Jira из ответа можно было уже достаточно давно. И для меня это достаточно удобная интеграция. Которая сделана например на порядок удобней чем в Qase.io. Выполняете запрос в Postman -> изучаете ответ -> видите баг -> жмёте кнопку Add to Jira Cloud -> заводите баг в интерфейсе Postman, все нужные поля из Jira подтянулись. Что добавили? Теперь можно создавать баги из Collection Runner. Прогнали прогон, выявились баги? Можно завести прям оттуда по каждому случаю. Ссылки на Jira таски привязаны к запросу. Открываешь запрос и видишь какие баги есть и в каком статусе. В целом удобно. Но так как мало кто пользуется на регулярной основе Runner, ввиду его ограничения в бесплатной версии, прям восхищаться данной обновой не стоит =) ⭐️Вкладку Docs перенесли на более видное место 👍 Вкладку Docs перенесли в основное окно запроса. Разместили слева от Params. Я считаю эту функцию полезной , особенно с использованием постбота, который может на основе вашего запроса и ответа сделать вполне прикольную документацию по запросу. Она точно не будет лишней. Я использую её. 11.71.5 - 13 ноября 2025 ⭐️ Live Sessions для коллекций Добавили возможность совместной работы с коллекцией в Real-time. Я, честно затрудняюсь оценить такое нововведение. В целом полезно наверное для проведения менторских сессий. Подключаешься с учеником к коллекции и работаете. Но насколько это удобней, чем использовать Zoom например? Что там можно одновременно делать? В общем не знаю. Если у вас есть мысли пишите в комментариях. 11.71.7 - 14 ноября 2025 ⭐️ Генерация Postman CLI code snippet из HTTP-запроса Последнее на сегодня обновление. В раздел Code snippet добавили новый тип Postman CLI. Postman CLI - кто не знает это официальная утилита командной строки от постман. Навряд ли кто-то из читающих активно юзает её. Многие сидят на бесплатном плане и поэтому актуальней Newman. Но тем не менее. Собственно нам просто добавили более удобную кодогенерацию для Postman CLI. 11.72.3 — 18 ноября 2025 ⭐️ Postman официально хоронит Webhook-триггер в Flows (15 января 2026) Postman уведомляет, что откажется от поддержки вебхуков в Flow 15 января 2026. Поэтому, если ты такие используешь - увы готовься переходить на Actions - облачная замена. Вебхуки были прикольной штукой, так как можно было настроить локально и они не жрали лимиты бесплатного плана. В общем кто юзал на бесплатном тарифе - пострадали. Кто на платном работает и ничего против облака не имеет - станет жить проще. Ну и на этом пока всё. Если вам было интересно оставляйте реакции буду такие обзорчики делать под различные релизы инструментов тестирования. 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

Всем привет! 👋 Postman регулярно выкатывает новые релизы. Последний был на прошлой неделе. Я подумал, что возможно будет не плохо, кратко освещать, что же они там натворили в очередной раз. В первом посте я решил пробежаться по всем ноябрьским апдейтам. В двух словах. Почему по всем? Не знаю 🤷🏻‍♂️ Наверное потому что в начале ноября вышла 11.70.0. в которой ввели BYOM. Погнали. ➡️ 11.70.0 — 3 ноября ⭐️Bring Your Own Model (BYOM) для AI Requests 👍 Сами AI Requests появились не так давно и стали вполне востребованы. А в ноябре добавился BYOM - это возможность подключать свои LLM модели, локальные или корпоративные. В общем, думаю реально полезная штука для тех кто работает с LLM. ⭐️Обновление в API Мониторинге. Сделали возможность мониторить внутренние корпоративные/локальные сервисы. Как было раньше? Ну и сейчас тоже это никуда не делось. Мы могли(можем) настроить мониторинг только к публичному API. Потому что Postman дергал эндпоинты из своего облака. Соответственно до localhost или какой-нибудь внутренней корпоративной сети добраться из вне не мог. Теперь можно сделать мониторинг и внутренний. Для этого используется утилита Postman CLI, которая мониторит локально, а в облако шлет только результат(ошибку, задержку и тд). Вообще я в принципе не встречал, чтобы кто-то использовал Postman для мониторинга. Но раз функционал есть наверное им кто-то пользуется. В любом случае это доступно только на платных тарифах. 11.70.1 - 4 ноября 2025 ⭐️Полная поддержка OpenAPI 2.0 и OpenAPI 3.1 в Spec Hub Небольшой апдейт. Где добавили полную поддержку OpenAPI 2.0 и 3.1. Для кого? Для тех кто работает, создает/редактирует спецификации OpenAPI. Как правило этот функционал тестировщики не трогают. Поэтому не буду вдаваться в детали. 11.70.2 - 4 ноября 2025 ⭐️Баг фикс Был некий баг когда Postman зависал при работе с локальной файловой системой. Пояснить не могу, такой баг не встречал. 11.70.4 - 5 ноября 2025 ⭐️Новая персонализированная Home-страница Если кто помнит раньше там был раздел "Быстрого старта" - создать или импортировать коллецию. Ссылки на шаблоны Postman. И ссылка на популярные API, которые доступны в Postman. Теперь нас там встречает Postbot, список наших последних коллекций с которыми мы работали. ⭐️Connector blocks в Postman Flows 👍 Во Flow добавили новые блоки коннекторы для интеграции со сторонними сервисами, пока это только Notion, Figma, Calendly, and Box. Прикольная и полезная штука для тех кто вообще использует Flow. Как можно использовать? Грубо говоря у вас подключен мониторинг вашего API или runner по расписанию. Можем поставить условие, что если будет ошибка - создать страницу в Notion. Понятно что это самый простенький пример и реализовать можно что-то поинтересней. Но для понимания сойдет. ⭐️Ещё небольшое улучшение Flow Теперь при добавлении блока For так же автоматически добавляется блок Collect. Многие новички часто забывали про этот блок и после того как цикл For обрабатывал весь массив они получали ошибку, и не понимали, что пошло не так. Теперь будет проще. Вполне интересные нововведения. У меня лично до Flow никак не дойдут руки поработать. Я думаю не ошибусь, если скажу, что мало кто из тестировщиков пользуется этим функционалом. Напишите в комментариях если используете в работе. Пишите в комментариях, что вам из нововведениях понравилось. Продолжение будет в следующем посте. ⬇️ 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

продолжение про мой опыт нагрузочного тестирования первый пост двумя постами выше 👆 Неделя 2: Нагрузка интеграции с Kafka Во вторник или среду ко мне пришли с просьбой провести нагрузку асинхронного конвейера Маркетплейс → Kafka → WMS. 🤔 Почему бы и нет! подумал я - и пошёл разбираться. Для такой нагрузки одного k6 мало - понадобилось расширение xk6. Есть официальный вариант от Grafana и форк с расширенными возможностями. Я выбрал форк - он активнее развивается, больше документации и примеров применения. ⚙️ Проблемы и решения 1. Изоляция. Мы не могли лить тестовый трафик в общий топик - рисковали зацепить другие системы и остановить их работу. А там активно шло тестирование перед началом акции. Решение: изолировать топик и лить синтетику, после теста - чистить БД скриптом. Главное - подготовить валидные данные, иначе система не примет сообщения и наша нагрузка потеряет весь смысл. 2. Сетевой шум. При запуске с личного ПК задержка отправки сообщений достигала 1+ секунды, при том что брокер обрабатывал за 65 мс. Проблема - сеть. Решение: запускать producer из Kubernetes(у нас куб) в той же сети, что и Kafka/WMS. Так, собственно и нужно делать. Но мы не могли =) не было ни времени, ни ресурсов девопса. Позже к этому обязательно придем. 3. Метрики. Главная метрика - Consumer Lag (насколько быстро вычитываются сообщения - они не должны накапливаться в очереди). k6 не может получить её напрямую, поэтому я реализовал получение через API Grafana используя свои логин и пароль. Лучше API key, но вариант с API key требовал помощи девопсов, а ресурсов не было. Самый лучший вариант, если для мониторинга у вас используется Grafana(у нас именно она) настроить в ней работу приложения k6. Это идеально решение к которому мы придем. Метрики берутся напрямую, замеры все пишутся сразу сюда же - очень удобно. Но опять же тут требуется помощь девопс, ну вы поняли?) 📊 Итог Запустить нагрузку до 11.11 не успели, но сделали важные наработки. После акции обязательно продолжим - впереди Новый год и другие распродажи! 🧠 Инсайт двух недель: Когда я впервые занимался нагрузкой (года 4 назад), думал, что сложнее всего - код. На деле самое трудное - метрики, SLA/SLO, RPS, и понимание как правильно выстроить инструментарий. В общем это был интересный опыт, зависал до ночи для решения задачки. Просто потому что это было очень интересно. А что вас в работе увлекает настолько, что вы готовы делать это даже после завершения рабочего дня? Или да ну его? 19:00 и домой. 🫡👇 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

О чём я подумал, пока ковырял нагрузку 😅 Пока готовил скрипт, приходилось проверять, как всё связано и работает. Сроки были сжатыми. Без Postman это было бы больно и главное долго - иногда нужно быстро отладить процесс или автоматизировать часть логики без всяких фреймворков. Postman — это не просто инструмент. Это способ работать быстро и уверенно. Почему Postman — маст-хэв: 🧩 Проверяете API за минуты. 🔐 Тестируя API попутно покрываем энд-поинт тестами в пару кликов ⚙️ Автоматизируете проверки и фокусируетесь на сути. 🎁 К 11.11 - я решил сделать скидку 30% на курс «Postman с нуля до профи» Промокод: 1111, действует до конца недели. 👉 https://qa-study.ru/postman Пусть бутылочным горлышком будет система под нагрузкой, а не ты 😎 Реклама ИП Сычев Евгений Александрович ИНН 860101629973 Erid: 3apb1Qrwwr2uBg1ETJYYn9EGgUDgMQXqi6CYcyLhmCiGQ 🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman

🔥 Куда я пропал на 2 недели, и причём тут 70 VU? Привет! 👋 Если вы заметили, что блог притих, - это не лень, а полное погружение в боевые задачи. Последние две недели я с головой ушёл в новую, захватывающую тему: Нагрузочное тестирование. Это был невероятный челлендж! Когда прилетает такая задача, интерес перевешивает всё, и ты не замечаешь, как после рабочего дня продолжаешь разбираться. Неделя 1️⃣: Постановка задачи. Борьба за информацию и базовый анализ Цель: в преддверии акции 11.11 необходимо было проверить как складская система(WMS) будет справляться с повышенной нагрузкой. Предполагалась что количество заказов будет выше почти в два раза чем в обычные дни. Здесь надо было нагрузить наш основной процесс, чтобы понять будет ли деградация и на сколько будут расти задержки. Тут же, конечно, столкнулись с двумя ключевыми проблемами: 1. Не так давно был изменен один из этапов процесса и мы его не успели ещё автоматизировать. Процесс не простой и с "пол пинка" не автоматизируешь. 2. Вторая проблема это генерация "живых" заказов. Так как у нас нет отдельного стенда под нагрузку, грузить надо было на тестовом стенде, где обычно проводим регресс. Максимально близок по своему состоянию к продакшну. Со всеми интеграциями. Поэтому просто лить синтетику было нельзя, так как почти на каждом шаге данные синхронизируются с различными системами. И мы просто на первом же шаге упадем с ошибкой. В итоге мы решили пока нагрузить хотя бы GET-запросы, чтобы понять, где система может "споткнутся" во время чтения данных, обращения к БД. Я сделал 4 сценария: - Базовый - имитирующий стандартный рабочий день. Продолжительность 60 минут. - Пиковый - установил значения ожидаемой пиковой нагрузки +10% сверху. Продолжительность 60 минут. - Стресс - короткий на 20 минут тест с резким повышением нагрузки, +30% к пику. - Продолжительный(Soak) - 6 часовой тест с базовой нагрузкой. Инсайт 1: Ценность простого теста. Мы увидели, что WMS в целом хорошо справляется с нагрузкой в ключевых точках. И при тестировании не наблюдалось деградации. Плюс смогли понять средний RPS нашей системы. Так же были единичные всплески задержек ряда запросов, которые достигали местами 6 секунд. Причины не ясны. Зафиксировали - будем наблюдать. Инсайт 2: Прозрачность критериев Какие метрики брать и какие значения использовать для критериев приемки? Пожалуй это самая сложная часть нагрузочного тестирования. Далеко не всегда в документации прописаны метрики, например, самый важный в нашем случае RPS(Requests Per Second) - запросов в секунду. Пришлось для первого раза брать значение "на глаз" и с текущих метрик с прода. Главный вывод: составлять и уточнять метрики и их значения заранее. Уделить этому самое сильное внимание. Нагрузку провел на выходных 2.11. В понедельник выложил интерпретацию результатов в конфлюенс. Думал на этом пока всё. И после акции продолжим работы. Но... Продолжение будет в другом посте.

Друзья, привет!👋 Кто помнит у меня есть пет-проект своей LMS системы. Она работает в продакшине. У меня там курс по постману. Я в свободное время дорабатываю платформу, добавляю новый функционал. И решил сделать стейдж стенд открытый для всех https://dev-lms.testerhub.ru туда я выкатываю то что готовится к продакшину, чтобы протестировать. Мне кажется это вполне хорошая возможность попрактиковаться для начинающих тестировщиков. Заводят баги - я правлю их. Попутно могу прокомментировать то как заведен баг. Что-то посоветовать. Активность пока маленькая. Поэтому я решил немного внедрить геймификацию. Теперь при выкатывание новой версии буду делать чек-лист. По выполнению которого можно получать балы. https://dev-lms.testerhub.ru/test-checklists/2025-10-28-profile-management.html За заведение багов и тест-кейсов будут тоже присваиваться очки. Есть лидербоард. Это все нуждается тоже в тестировании)) Будем дорабатывать, корректировать. Пока это просто ради фана. Но в будущем вероятно будут какие-то награды самым активным. Я бы в свое время за такую возможность попрактиковаться в тестировании конечно был бы рад. Но увы... Поэтому если у вас есть знакомые которые только думают или обучаются тестированию пересылайте им пусть подключаются!

https://rbc-ru.turbopages.org/rbc.ru/s/technology_and_media/26/08/2024/66ccca299a794740d50e24c4 ‼️Notion с 9 сентября уходит из РФ. Он закроет доступ к своим ресурсом из России. Вот такие новости. Многие его использовали для документации на проектах, как аналог Confluence. Теперь придется искать аналог Notion. Ещё один сервис, который будет доступен только с VPN 🤦🏻‍♂️ Как ребят вам такие новости? Вы пользуетесь Notion?