BRUNOVSKI ПРО IT 🛎

Ребята, напоминаю наш канал переехал сюда https://t.me/pentesting_channel Кому интересна тема нагрузочного тестирования / безопасности и автоматизации - велком

Вы не будете получать большие деньги как QA, если вы не поймете пару вещей - Могут ли большие деньги быть в найме? - - Да, могут, но .... что для этого надо ... - Опыт, хотя бы 3 года (не обязательно 10 лет) - Редкий скилл, реально редкий, не QA Manual, не QA Automation как факт - Если это автоматизация, то это либо хорошее знание современного фреймворка типа Playwright, либо какой-то редкий фреймворк - Kaspresso - Редкий и сложный язык программирования, типа Rust - Кибербезопасность или тестирование безопасноти в случае QA. - Знания нагрузочного тестирования, хотя бы основы Будьте редким специалистом, выделяйтесь, и будут вам нормальные деньги

А у вас не было такой проблемы? Что вы начинаете пилить проект на вайбкоде, у вас крутая идея. У вас получается MVP, и даже больше. Вы уже на финальной стадии и вдруг вы просто бросаете этот проект, потому что либо теряете мотивация, либо не знаете кок его продвигать. Вообще, маркетинг ооооочень важен, я это понял спустя годы. Поэтому крутые маркетологи, которые умеют двигать твою идею в соц сетях, Интернете или которые настраивают круто таргет, это очень ценные специалисты. А вы забивали на свои вайбкод проекты на финальной стадии?

Как Vibe Coding справляется с Big Data и сложной бизнес-логикой Сервис MDaccept.com решает критическую проблему американской медицины - помогает найти врачей, которые реально принимают конкретную медицинскую страховку, на основе отзывов живых пациентов Для инженера этот проект интересен тем, что это не просто красивый интерфейс. Это пример того, как с помощью Vibe Coding автоматизировать работу с огромными базами данных, сложной фильтрацией и интеграциями, не тратя месяцы на написание кода. Давайте рассмотрим профит и выводы из этого кейса: 1. Обработка и фильтрация тяжелых реестров (Big Data & API) Под капотом сервиса находится база NPI (National Provider Identifier) - это более 7 миллионов медицинских провайдеров в США, плюс сотни страховых планов. Вручную писать парсеры, маппинг данных и пайплайны очистки под каждую страховую компанию - это месяцы рутины. Выгода: При Vibe Coding вы делегируете ИИ создание SQL-запросов, настройку индексов базы данных и логику нормализации данных. Вы ставите задачу архитектурно: «Свяжи реестр NPI со справочником страховых планов и сделай выборку по геолокации и специальности за <100мс». ИИ берет на себя весь boilerplate-код оптимизации запросов. 2. Архитектура скоринга в реальном времени (Recency-Weighted Scoring) Сервис пересчитывает рейтинг врача (Trust Score) на лету после каждого подтверждения от пользователя, причем свежие отзывы весят больше, чем старые. Выгода: Вместо математического проектирования алгоритмов взвешенного среднего руками, вы описываете ИИ логику бизнес-правил: «Если отзыву меньше 30 дней - вес 1.0, если больше года - вес 0.1. Пересчитывай баланс мгновенно при апдейте строки в БД». Вы фокусируетесь на валидации этой математики и бизнес-логике, а не на синтаксисе. 3. Проектирование воронки конверсии (микро-UI/UX) Форма подтверждения визита у них занимает всего 10-30 секунд. Чтобы краудсорсинг работал, интерфейс сбора данных должен быть стерильно чистым, без лишних кликов. Выгода: ИИ отлично генерирует пошаговые реактивные формы (Multi-step forms) на фронтенде с мгновенной валидацией ввода. Вы задаете «вайб» и логику шагов (Шаг 1: Выбор плана -> Шаг 2: Ввод имени врача -> Шаг 3: Галочка подтверждения), а LLM собирает под это чистый компонентный код. MDaccept доказывает, что Vibe Coding - это уже давно не про «создать простую визитку или лендинг». Сегодня один архитектор с ИИ-агентами может поднять масштабируемый сервис, работающий с миллионными государственными реестрами и сложными алгоритмами реального времени. Посмотреть проект можно тут: https://mdaccept.com/ Творите!

Ребят, смотрите, какой интересный кейс. Попался на глаза проект naksu.app (это CRM и конструктор программ для фитнес-тренеров и коучей). Проект - https://naksu.app/ Интересен он нам не своей фитнес-тематикой, а тем, как именно он сейчас собирается и развивается. Продукт полностью построен на концепте vibe coding. Что по технической и продуктовой части: Разработка идет силами AI-агентов (Cursor, Windsurf, Claude Code), где фаундер выступает скорее в роли архитектора и продакта, накидывая фичи через промпты. Скорость доставки фич в прод при таком подходе в разы выше, чем у классической микро-команды. Внутри зашит стандартный для SaaS функционал: база данных, интеграция со Stripe/Revolut, планировщик задач, логика расписаний и чаты. То, на что раньше уходили месяцы разработки, сейчас поднимается за недели в режиме общения с моделью. Советую следить ребят за такими проектами, особенно кто хочет свалить с найма или кто хочет в доплнительное время развивать свое детище Почему? Такие проекты монетизируются очень хорошо и приносят пассивные небольшие, а иногда большие деньги (сам сейчас пилю один проект) Что происходит с наймом? Подобные проекты наглядно показывают, куда смещаются требования к инженерам. Полноценная разработка таких платформ силами AI-агентов не означает, что программисты больше не нужны. Наоборот: Растет спрос на людей, которые умеют валидировать сгенерированный код, настраивать CI/CD, следить за безопасностью (особенно где есть платежи вроде Stripe) и собирать правильную архитектуру. Выигрывают те, кто умеет управлять ИИ-агентами как подчиненными джунами. Если думаете, куда развивать свои навыки в автоматизации или бэкенде, покрутите подобные AI-first платформы. Понимание того, как устроена инфраструктура под капотом таких вайб-проектов, сейчас становится критически важным скиллом на рынке.

Если я буду вести данный канал про АЙТИшку без конкретных привязок к QA / QA auto / security и тд - такой формат зайдет? у меня много есть что рассказать из своей практики, рассказы как можно зарабатывать на айтишке помимо найма, про поиск работы? Если такой формат интересен, дайте реакцию ребят А чисто техническая часть - тут https://t.me/+zPyQdiul7j02YTM0

Скоро тут будет много бесплатных видео по безопасности помимо платного менторства, я буду давать вам много полезностей просто так, за то что вы подписались на меня и доверились мне Все будет тут https://t.me/+zPyQdiul7j02YTM0

BRUNOVSKI ПРО IT 🛎 pinned «Друзья, тема QA Automation и SDET шире, чем просто тесты. Мы переезжаем в мой главный канал, где теперь будет мощный упор на автоматизацию безопасности, DevSecOps и разборы реальных кибератак. Все новые скрипты, гайды по Playwright и CI/CD будут выходить только…»

Друзья, тема QA Automation и SDET шире, чем просто тесты. Мы переезжаем в мой главный канал, где теперь будет мощный упор на автоматизацию безопасности, DevSecOps и разборы реальных кибератак. Все новые скрипты, гайды по Playwright и CI/CD будут выходить только там. Перекатывайтесь: https://t.me/+zPyQdiul7j02YTM0

​​Race Condition - это баг (который кстати надо знать каждому уважающему себя QA), который возникает в многопоточных или распределенных системах, когда два или более потока (или запроса) одновременно обращаются к одному и тому же ресурсу, и итоговый результат зависит от того, какой из них выполнится быстрее. Простыми словами: система работает некорректно, потому что несколько действий происходят одновременно и по сути соревнуются друг с другом, нарушая логическую последовательность. Пример из практики Самый наглядный пример - покупка товара в интернет-магазине с ограниченным запасом. Условие: На складе остался ровно 1 iPhone. Два разных пользователя (Пользователь А и Пользователь Б) одновременно нажимают кнопку "Купить". Как это работает без бага: Запрос от А проверяет базу: Остаток = 1. Заказ оформляется, остаток уменьшается: 1 - 1 = 0. Запрос от Б проверяет базу: Остаток = 0. Система выдает Б ошибку: «Товара нет в наличии». Как происходит Race Condition: Запрос от А проверяет базу: Остаток = 1. В эту же миллисекунду запрос от Б проверяет базу: Остаток = 1 (потому что запрос от А еще не успел обновить данные). Система одобряет покупку пользователю А. Система одобряет покупку пользователю Б. База данных обновляется дважды. Итог: продано 2 телефона, хотя в наличии был всего 1. Магазин не может выполнить один из заказов. Почему это важно знать каждому QA инженеру? 1. Такие баги критичны для бизнеса Race Condition чаще всего бьет по деньгам, безопасности и логике: Списание денег со счета дважды. Применение промокода несколько раз вместо одного. Регистрация двух пользователей на один и тот же логин. 2. Их тяжело воспроизвести и найти Это плавающие баги... Они зависят от скорости интернета, загрузки процессора и работы базы данных. Тест может успешно пройти 99 раз, а на 100-й раз упасть, потому что запросы совпали по времени. 3. Обычные позитивные тесты их не находят Если тестировать функционал последовательно (в один поток), система всегда будет работать корректно.  Чтобы обнаружить Race Condition, QA инженер должен уметь применять инструменты для нагрузочного и параллельного тестирования (например, отправлять одновременные запросы через Apache JMeter или Postman). Как это предотвратить? На этапе ревью требований или тестирования API проверяйте, заблокирован ли ресурс во время изменения данных.  Разработчики должны использовать механизмы блокировки (например, Pessimistic/Optimistic Locking на уровне базы данных), чтобы второй запрос ждал завершения первого. Удачи! По обучению TG @faroeman

​​Как бы я искал работу в IT в 2026 году? 1. Традиционный поиск через Linkedin / Telegram / остальные сайты я бы точно не забрасывал... Использовал бы как дополнительный источник. Подавал бы на вакансии только на те, где нет еще 100 кандидатов и где дата вакансии не более суток. 2. Просил бы зареферить меня из круга знокомых и коннекшенов, сейчас референс важная тема. 3. Если нашел интересную вакансию, то искал бы рекрутера из этой компании в разделе Company / People и писал бы напрямую, что я такой-то крутой, очень интересно у вас поработать, давайте пообщаемся. Тут есть шанс, что вас хотя бы заметят или запомнят на будущее. Тут может понадобиться платная подписка Linkedin, чтобы процесс шел быстрее. 4. Находил бы список стартапов(да, именно стартапов) и писал бы в личку им (но только НЕ на info, support и тд ящики), а лично CTO/Lead и тд, ЛПР короче. Писать можно в Linkedin или же находить емейлы нужные через специальные сервисы, типа Apollo. Пользуйтесь! По обучению TG @faroeman

​​Взламываю самого себя) Если честно работаю над лабой по уязвимости BOLA / IDOR на примере REST API Пора походу а Баг Баунти двигать)) А у вас как рабочий день проходит?

​​Как повысить зарплату тестировщику на текущем месте работы Чтобы получить прибавку к зарплате, нужно продемонстрировать руководству выгоду для бизнеса или расширение своих технических компетенций. Ниже приведены 4 конкретных шага для подготовки к переговорам: 1. Сбор результатов Приходите на встречу с руководителем с фактами, а не с субъективными ощущениями. Зафиксируйте: --- На сколько процентов или часов сократилось время регрессионного тестирования благодаря вашим действиям. --- Сколько критических багов и уязвимостей (например, BOLA или XSS) вы обнаружили до релиза. --- Каких ошибок на проде удалось избежать за счет оптимизации тест-покрытия. PS: и да, лучше это делать на Performance Review 2. Расширение технических навыков Пересмотр дохода напрямую привязан к освоению более дорогих на рынке технологий. Что нужно внедрять: --- Автоматизация тестирования: Переход от ручного тестирования к автоматизации (например, написание автотестов на Playwright). --- Нагрузочное тестирование: Настройка мониторинга производительности и работы с инфраструктурой (связка JMeter + InfluxDB + Grafana). --- Безопасность: Проведение аудита API по стандартам OWASP. 3. Оптимизация рабочих процессов --- Возьмите на себя задачи, которые разгружают команду и менеджмент: --- Внедрение и настройка CI/CD пайплайнов для тестирования. --- Наведение порядка в тестовой документации и актуализация базы знаний. --- Обучение или онбординг новых сотрудников в команде. 4. Проведение переговоров с лидом/манагером --- Запланируйте встречу с лидом --- Озвучьте свои результаты за последний период. Задайте прямой вопрос: "Я хочу увеличить свой доход на (ну например на 20% или 400 евро). Каких конкретных целей и KPI мне нужно достичь за следующие 3–6 месяцев, чтобы компания пересмотрела мой контракт?". Что из этого вы уже применили на практике? Пишите в комментариях. Мне интересно узнать, что у вас сработало, а что нет, вы же по-любому пытались повысить себе ЗП...верно да? верно?? По обучению TG @faroeman #QA #Testing #Automation #QualityAssurance #Career

​​Зачем тестировщику SOAP API в 2026 году? Когда речь заходит об автоматизации или тестировании безопасности API, все сразу думают про REST, GraphQL или gRPC и тд и тп. JSON стал стандартом для большинства веб-сервисов, а про SOAP часто забывают, считая его устаревшим. Но если вы планируете работать в финтехе, банковском секторе, логистике или страховании - без SOAP не обойтись даже в 2026 году. Крупный Enterprise не может быстро и дешево переписать архитектуру, которая стабильно работает годами. В чем практическая разница для QA? В автоматизации: REST гибок и часто не требует жестких схем. SOAP строго завязан на XML и контракт WSDL. Вы всегда точно знаете структуру запроса и ответа, а валидация происходит на уровне схемы. Автоматизировать такие тесты (например, на Playwright или Python) сложнее из-за объемного XML-тела, но сам контракт всегда предсказуем. В нагрузочном тестировании (JMeter): XML-пакеты тяжелее JSON. Тестирование производительности SOAP-сервисов критично для оценки пропускной способности каналов и нагрузки на процессоры серверов. В безопасности (AppSec): В REST мы часто ищем логические ошибки (вроде BOLA/IDOR, меняя ID в URL). В SOAP параметры скрыты внутри XML-тела, но здесь возникают специфические и опасные уязвимости: XXE (XML External Entity) инъекции и атаки класса DoS (SOAP B0mb), способные уронить сервер из-за переполнения памяти при парсинге. Не поймите неправильно, я ничего не имею против REST, наоборот это золотой стандарт и база для любого QA. Но, знание SOAP это то, что отличает рядового инженера от специалиста, способного работать на сложных масштабных проектах с высоким чеком. #QA #AutomationTesting #APITesting #ApplicationSecurity #SOAP #REST #SDET

Хочу рассказать, почему QA инженерам советую изучить, как делать проверки на XSS уязвимости в 2026 году и почему это все еще актуально. Современные фреймворки, типа React / Angular / Vue и тд умеют экранировать данные, а у браузеров есть встроенная безопасность, казалось бы, какие еще XSS в 2026 году? Однако, что XSS (Cross-Site Scripting) никуда не исчезла и стабильно держится в топах уязвимостей. Более того, подходы к её поиску и эксплуатации изменились. Если вы QA, SDET или хотите развиваться в сторону безопасности, вот почему вы должны уметь делать ручные и автоматизированные проверки на XSS. 1!!! Фреймворки защищают, но разработчики обходят защиту Да, React безопасен по умолчанию. Но до тех пор, пока в коде не появляется dangerouslySetInnerHTML. В погоне за быстрыми фичами, сложной кастомизацией интерфейсов или интеграцией сторонних текстовых редакторов разработчики регулярно оставляют лазейки. Задача QA - найти эти дыры. 2!!! Client-Side (DOM-based) XSS С переходом большинства приложений на Single Page Applications (SPA) классическая Stored XSS встречается реже, зато DOM-based XSS встречаются постоянно. Когда приложение доверяет данным из URL(хэш, параметры) или localStorage и передает их в исполнительный контекст браузера, рождается уязвимость. Автоматические сканеры часто пропускают такие сценарии, потому что они завязаны на сложную бизнес-логику фронтенда. 3!!! Безопасность это часть Quality Assurance, а не только задача ИБ Ожидать, пока application security команда или внешний аудит найдет баг на этапе релиз-кандидата (или, хуже того, на прод) - это достаточно дорого. Чем раньше QA локализует XSS в рамках функционального тестирования, тем дешевле обходится её исправление (Shift-Left Security в действии). 4!!! Рост ценности специалиста QA-инженер, который понимает разницу между Stored, Reflected и DOM XSS, умеет составить базовый payload и объяснить разработчику, почему Content Security Policy (CSP) не спасает от плохой фильтрации на бэкенде - поверьте это специалист совершенно другого уровня. Это прямой путь от рутинного тестирования к глубокому техническому аудиту. Учитесь, и будет у вас работа, и будете вы хорошо зарабатывать!

Завтра стартует обучение по тестированию безопасности! По Эстонии в 20-15 Учимся ломать и защищать веб-приложения и Rest API от XSS / Broken Object Level Authorization Последний шанс попасть Писать @faroeman

Настало лето и у меня есть несколько мест на обучение CYBERSECURITY. Есть места как в группе, так и индивидуально. Группа стартует уже 7 июня. Подойдет для новичков. Группа небольшая, в районе 10 человек, чтобы каждому мог уделить внимание. Много практики. Будем изучать основы тестирования безопасности, будем практиковаться ломать и защищать веб-приложения на специально уязвимых лабораториях. По окончанию у вас будут крутые знания, которые вы сможете применить в работе. И конечно же сертификат моего образовательного центра. _________________________________________ Также могу взять на индивидуальное менторство, где за 4-6 месяцев проведу вас до крепкого Middle Applicaton Security специалиста. Очень много много практики, самые передовые знания, сам я занимаюсь аудитами по безопасности, поэтому с радостью передам вам свои знания. Помогаю в поиске работы, не бросаю студентов. Кому откликается и кто хочет получить не побоюсь этого слова самую востребованную профессию в IT, пишите смело мне в телеграм @faroeman

7 июня стартует мой первый поток по основам Security Testing, где мы углубленно будем решать задачи по XSS инъекциям и по IDOR/BOLA. Атаковать и защищать веб и API. Немного теории и сразу практика на тестовых уязвимых машинах. Краткая программа: минимально основы HTML / JS (нужно чтобы читать код и делать XSS) Reflected, DOM-Based, Stored XSS. Rest API (нужно чтобы искать BOLA) Ищем BOLA (Broken Object Level Authorization) Сначала показываю я, потом все вместе делаем практику(буду чередовать ваши шейр экраны и на них будем тренироваться, чтобы лучше запоминалось). Подойдет всем, особенно QA инженерам, кто любит не просто кривые кнопочки искать, а тем кому нужен навык, за который готовы больше платить. Напомню, что XSS и BOLA стоят в A05 по OWASP и API1 по API OWASP. то есть это самые опасные уязвимости, через которые крадут данные и сливают базы. Обучаю с самого нуля. Ни над кем не смеемся, что кто-то глупые вопросы задает. Предыдущие потоки по QA Automation показали, что ребята все хорошие у нас и друг другу помогают. Можно задавать все вопросы на уроке и после. По окончанию сертификат моего образовательного центра Brunovski IT Education Center. Пишите в личку тг @faroeman За лайк - отдельно спасибо!