Как делать ИПР для сотрудника: 8 правил от эксперта Okko
На QA-days: Оkko, ИнфоТеКС и Piter QA спикер из Okko поделился подходом к формированию траектории развития QA-специалиста через индивидуальные планы развития (ИПР). Доклад поможет выстроить систему, где сотрудники растут с интересом, а не «под кнутом».
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Представлен открытый проект WebKit CSSFontFace Exploit for PS4/PS5, который прошивает игровую консоль меньше чем за минуту. Работает через подмену кода в браузере: пока WebKit пытается считать CSS-код страницы, запускается эксплойт системы. Решение запускается на прошивках с версиями от 6.00 до 11.02 и совместимо с kernel-эксплойтом для версий 7.00–11.02, позволяя запускать HEN и другие пэйлоды. Минусы проекта: перепрошивку придётся активировать при каждом перезапуске консоли.
Как я устал от бардака в «Избранном» Telegram и за два вечера запилил бесплатную интерактивную доску (без регистраций и СМС)
Всем привет!
Хочу поделиться историей о том, как лень и раздражение в очередной раз победили систему и заставили меня сесть за код.
Думаю, у многих из вас Telegram давно превратился в помойку из сотен каналов. Полезные статьи, гайды, рецепты, мемы, рабочие задачи — всё это мы обычно скидываем в «Избранное» (Saved Messages). И что происходит дальше? Правильно, «Избранное» превращается в черную дыру. Найти там что-то через неделю — это квест уровня «Индиана Джонс».
Особенно сильно у меня подгорало, когда я листал ленту с телефона в метро, находил сложный чек-лист или рабочую инструкцию, пересылал в «Избранное», а вечером открывал комп и... тратил кучу времени просто на то, чтобы откопать этот пост в каше из мемов и рабочих чатов. Выполнять задачи с экрана телефона — ад, а структурировать это в самом Telegram невозможно.
Мне это надоело. Я хотел простой инструмент: нашел на смартфоне -> скинул боту -> открыл на компе в виде красивых карточек. Посмотрел готовые сервисы — везде просят регистрацию, привязку карт, вылезает реклама или ограничения на 10 постов.
В итоге я психанул, выделил два вечера и написал свой костыль, который неожиданно превратился в отличный инструмент — TG-drop.ru.
Как я это устроил (без заумной архитектуры)
Система работает на связке «бот + база данных + веб-интерфейс». Всё гениальное просто:
Вы листаете Telegram на телефоне и видите важный пост (гайд, чек-лист, статью).
Пересылаете его моему боту. Бот мгновенно подхватывает его и сохраняет в изолированную таблицу.
Вечером вы садитесь за ПК, открываете сайт, вводите свой Telegram ID (он нужен только как ключ, чтобы сайт понял, чьи посты показать) — и перед вами удобная интерактивная доска.
Почему это удобнее, чем просто Telegram?
Я делал проект для себя, поэтому сразу вырезал всё, что меня бесит в современном вебе:
Никаких регистраций вообще. Никаких вводов почты, подтверждений по SMS и придумывания паролей «с одной заглавной буквой и спецсимволом». Ввел ID — работаешь.
Живой поиск и фильтры. Когда постов становится много, вы можете искать по ключевым словам прямо в браузере. Всё фильтруется на лету, без перезагрузки страниц.
Личные заметки прямо на карточках. Можно дописать к посту дедлайн, свои мысли или вычеркнуть выполненные пункты. Текст сохраняется автоматически, как только вы убираете курсор из поля.
Конфиденциальность. Ваши посты подгружаются динамически. Никто другой вашу доску не увидит.
Кому это пригодится?
Изначально я думал о ребятах из крипты (охотники за Airdrop, тестнеты, DeFi-инвесторы), которым нужно по пунктам выполнять сложные активности с ПК, найдя их в мобильном телефоне.
Но в процессе понял, что штука закроет боли многих:
Контент-мейкеров и исследователей: собирать выжимки, инсайты и референсы в одном месте.
Студентов: скидывать материалы для курсовых и дипломов, чтобы потом структурировать на десктопе.
Да и вообще всех, кто использует Telegram как базу знаний и устал от хаоса в «Избранном».
Инструмент абсолютно бесплатный, без скрытых подписок и ограничений. Пользуйтесь, упрощайте себе жизнь.
Буду рад здоровой критике в комментариях! Чего вам не хватает в таком функционале? Что стоит добавить в первую очередь?
Безопасность для «чайников»: зачем обычному тестировщику знать про уязвимости
На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Гринатом поделился простыми, но важными вещами: «На волне вайб-кодинга безопасность стала проявлять себя всё ярче. Тестирование безопасности постепенно внедряется в процессы обычных тестеров».
Узнай, как QA может влиять на безопасность продукта.
Anthropic выпустила бета‑версию плагина Claude Security для Claude Code. Инструмент запускает многоагентную проверку репозитория, составляет отчёт об уязвимостях и предлагает исправления в виде патчей. Инструмент поддерживает четыре уровня глубины проверки. Чем выше выбранный уровень, тем больше агентов участвует в анализе и тем шире охват репозитория. При этом сканирование расходует токены в рамках тарифа пользователя.
Плагин работает внутри обычной сессии Claude Code и запускается командой /claude‑security. Пользователю доступны три основных сценария: проверка всего репозитория или отдельной его части; анализ изменений в ветке, pull request или коммите; создание патчей для выбранных уязвимостей.
Claude Security ищет ошибки, связанные с обработкой входных данных, управлением доступом, небезопасной работой с памятью, криптографией и секретами. Для проектов на языках с безопасным управлением памятью соответствующая категория автоматически исключается.
Для установки необходимо подключить плагин из официального каталога Anthropic. Для работы требуется платная подписка, Claude Code версии не ниже 2.1.154, Python 3.9.6 или новее и Git. Поддерживаются Linux, macOS и Windows.
Anthropic предупреждает, что плагин не создаёт отдельной изолированной среды и запускается с правами текущей сессии. Поэтому незнакомые и потенциально вредоносные репозитории рекомендуется проверять в песочнице. В команде проекта напомнили, что Claude Security не заменяет статические анализаторы, проверку зависимостей и ручной аудит кода.
Проект tlosint-vm - виртуальная машину от Tracelabs OSINT, которая проверяет тысячи открытых источников по запросу:
сервис специально создали для соревнований OSINT‑исследователей и поиска пропавших пользователей в сети;
готовый стек: Shodan CLI, Sherlock (поиск по логинам и юзернеймам), PhoneInfoga (разведка по номерам телефонов), SpiderFoot и sn0int (автоматизированные OSINT‑фреймворки), theHarvester и h8mail (email), Sublist3r (поддомены), exiftool и steghide (метаданные и стеганография);
проработана приватность — как только пользователь выходит из сервиса, то система чистит все данные и куки;
внутрь также вшили хранилище Obsidian, где можно оставлять заметки во время поиска;
без ограничений, открытый проект, легальный поиск по открытым источникам.
«Иллюзия безопасности» — когнитивное искажение, заставляющее нас цепляться за мёртвые тесты. Мы боимся удалять, потому что кажется: они ещё пригодятся. На самом деле они только засоряют прогоны и снижают доверие к оставшимся проверкам.
Эксперт из Nexign на QA-days разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.
YouTube научили проверять факты прямо во время просмотра — представлено бесплатное расширение для Chrome под названием Popup Fact Check, которое анализирует субтитры с помощью ИИ и сразу сверяет спорные утверждения с надёжными источниками. Пока что проект лучше всего работает с английскими субтитрами. Также решение умеет работать с прямыми эфирами.
Один из топовых генераторов фонов для сайтов, приложений и презентаций стал бесплатным — Paper Shaders открыли исходный код. Теперь проект можно свободно использовать в любых веб-задачах, создавать собственные инструменты, плагины и даже коммерческие продукты, объявил СЕО Paper Shaders.
Как собрать тестовый стенд, если опыта нет, а железо разное?
IP-камеры, роутеры, одноплатники — и всё это нужно подружить в одном стенде. Эксперт ИнфоТеКС на QA-days рассказал, через что ему пришлось пройти, пересобирая стенд с нуля. Трудности, подводные камни и отсутствие опыта на входе.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Все что нужно знать QA-специалистам: сводка новостей за весну и лето 2026
Наш QA-комитет держит руку на пульсе — читает отчеты, изучает кейсы и копается в обсуждениях, чтобы вы могли заниматься более важными вещами. Забирайте выжимку всего, что стоит внимания.
📊 Рынок Вышло крупное исследование Tricentis 2026 Quality Transformation Report: опросили 2 501 ИТ- и QA-руководителей из шести стран. 93% руководителей C-level уверены в своей стратегии тестирования, в то время как 30% руководителей QA и DevOps такой уверенности не испытывают. Доверие к ИИ-агентам упало с 48% до 34% за год.
Короче: скорость выхода ПО растет, но уверенность в его качестве падает из-за перегруженности инструментарием и невозможности перепроверить все за ИИ. Сейчас самое узкое место — валидация автотестов и подсчет реального покрытия, около 60% компаний выпускают непротестированный код в прод и теряют миллионы долларов.
Во многих источниках отмечают следующие тренды: shift-left подход к разработке ПО, плотная работа QA c data-специалистами и фокус на стратегии качества, а не на наращивании числа автотестов.
🔧 Интересные материалы на Хабре В блоге Росгосстраха вышел целый цикл статей про применение LLM в тестировании. Начать лучше с этой статьи — про подготовку контекста для LLM: как структурировать требования, парсить PDF из Confluence, работать с макетами и диаграммами.
ВкусВилл рассказали, как превратили Swagger из документации в двигатель API-автотестов: OpenAPI Generator генерирует Java-клиенты и модели, swagger-coverage считает реальное покрытие по контракту, а LLM-скиллы по JSON-отчету сами предлагают, какие тесты дописать.
В Telegram-сообществах в последнее время гремит Playwright как наиболее перспективный фреймворк для автоматизации. Вот тут один автор решил проверить, не маркетинг ли это: собрал все свежие бенчмарки Playwright vs Selenium vs Cypress vs WebdriverIO, сравнил методологию и выяснил, что большинство цифр просто несопоставимы. Вывод: единственный процент, которому можно доверять — тот, что вы сами намерили на своем проекте.
🤖Про агентов СВОЙ Тех описали свою архитектуру ИИ-агентов в автоматизации. Там сложный 12-актовый воркфлоу, но и результат интересный: агент анализирует собственные ошибки и обновляет конфигурацию. Можно взять как шаблон для построения агентного фреймворка.
Вот тут автор описывает, как собрал систему из 11 узкоспециализированных ИИ-скиллов, которая по Jira-ссылке сама генерирует тест-кейсы, пишет автотесты, загружает их в Zephyr и создает merge request. Можно адаптировать под свой стек.
💼 Для карьеры ISTQB выпустила обновленную версию сертификации Certified Tester AI Testing (CT‑AI) v2.0, что де-факто означает появление общепризнанного стандарта использования ИИ в тестировании и тестирования самих ИИ-систем. Кому актуально, можно получить сертификат и использовать его как аргумент в переговорах с HR.
Frontend-приложения (личные кабинеты, онлайн-банки, маркетплейсы, сайты, лендинги и т. д.) выполняются в браузере пользователя — традиционной "слепой" зоне для безопасности. В вебинаре рассмотрены актуальные угрозы, крупнейшие инциденты, построение модели угроз и то, как применение анализатора класса FAST (Frontend Application Security Testing) снижает риски и делает frontend-приложения безопасными. Объясняется, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессах РБПО по ГОСТ Р 56939—2024.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Тестирование давно перестало быть просто поиском багов. Сегодня QA‑инженеру важно разбираться в автоматизации, пользовательском опыте, метриках команды и понимать, как ИИ меняет профессию.
Собрали ближайшие открытые уроки для тестировщиков и QA Lead, которые помогут прокачать практические навыки и посмотреть на развитие карьеры под новым углом.
30 июня, 20:00. Тестирование UX для мобильных приложений: чек‑лист по основным проверкам. Записаться Разберем, на что смотреть при проверке мобильного UX: сценарии, интерфейс, ошибки взаимодействия и типовые проблемы, которые влияют на пользовательский опыт.
30 июня, 20:00. Gitlab CI как конструктор workflow. Записаться Покажем, как устроены workflow в GitLab CI и как автоматизация сборок помогает быстрее проверять изменения в проекте.
2 июля, 20:00. От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре. Записаться Полезно для QA, которые тестируют мобильные приложения и хотят лучше понимать, как связаны API, логика приложения и пользовательский интерфейс.
2 июля, 20:00. REST Assured & JSON Schema Validator: автоматизация тестирования API на практике. Записаться Разберем практический подход к автоматизации API‑тестов на Java: проверки ответов, схем данных и стабильности интеграций.
7 июля, 19:00. Как читать баги: метрики для руководителей команд тестирования (QA Lead). Записаться Поговорим о метриках дефектов, качестве баг‑репортов и том, как QA Lead может видеть реальные проблемы процесса, а не просто количество задач.
14 июля, 20:00. Развитие команды без найма: инструменты наставничества для QA Lead. Записаться Разберем, как усиливать QA‑команду через наставничество, внутренний рост и передачу экспертизы без расширения штата.
16 июля, 20:00. Профессия тестировщика в эпоху ИИ — угроза потери работы или суперсила? Записаться Обсудим, как ИИ меняет работу тестировщика, какие задачи можно усилить с помощью инструментов и какие навыки останутся критичными.
21 июля, 20:00. UI и API тестирование с Java и Playwright. Записаться Покажем, как объединять UI‑ и API‑проверки в автотестах и использовать Java и Playwright для более устойчивого тестового покрытия.
21 июля, 20:00. Оценка трудозатрат в QA: как перестать ошибаться в сроках. Записаться Разберем, как QA оценивать задачи точнее, учитывать риски, сложность проверок и не попадать в ловушку заниженных сроков.
23 июля, 20:00. Тестирование интернет‑магазина (eCommerce): от каталога до оплаты. Записаться Покажем, какие сценарии критичны при проверке eCommerce: каталог, карточки товаров, корзина, оформление заказа, оплата и ошибки на пути пользователя.
Больше уроков по тестированию, разработке, искусственному интеллекту и не только смотрите в дайджесте.
Пока выбираете урок, обратите внимание на материалы по тестированию:
Представлена мощную опция автоматизацию для Codex от президента OpenAI Грега Брокмана. Промпт loop тестирует каждую фичу приложения и проводит полноценный аудит проекта:
ИИ разложит по полочкам каждую фичу приложения: как ее используют, удобна ли она, как должна работать на самом деле.
Тестирует все сценарии использования и записывает ошибки в отчет.
Исправляет логику, баги, а также UX.
После фиксов тестирует проект заново и оттачивает его до идеала, повторяя итерации.
Промпт loop ИИ‑агента:
/goal go over every single feature in this app create a user story with expected behaviour based on the code keep a single canonical spreadsheet tracking the features status
when done switch loop to testing every user story and documenting all errors
В этом докладе рассказали, как выстроить «танец команд»: от smoke-планов до совместной стратегии развития. Обмен экспертизой, интеграционные кейсы и живые воркшопы — всё, чтобы совместимость не хромала.
Ранее меня просили рассказать про subj. Итак, домашнее задание по оценке навыков ML Evaluation Engineer: как оно выглядит и чего ожидают работодатели?
Сценарий тестового задания: Приложение для медицинских консультаций получает шквал жалоб от пользователей, хотя внутренняя модель анализа настроений (sentiment model) по-прежнему рапортует о высокой «глобальной точности» (Global Accuracy). Ваша миссия: найти «слепые зоны», которые скрывают метрики.
Данные: 1000 пользовательских отзывов (в формате JSON), содержащих эталонные значения (ground truth), предсказания модели и показатели уверенности (confidence scores).
Что ожидается в качестве результата? Просто показать навыки кодинга недостаточно. В Evaluation главное – это ответ на вопрос «Ну и что?».
Структурированный аудит: Текстовое объяснение того, где именно находятся слепые зоны, подкрепленное цифрами.
Визуальные доказательства: Калибровочные кривые (Calibration Curves) и матрицы ошибок (Confusion Matrices), которые покажут, почему старые метрики пропустили провалы.
Какими навыками нужно обладать?
Чтобы блеснуть, вам понадобится «гибридный» профиль:
Теоретическая база: Понимание того, как именно модели ошибаются, и какие метрики применимы к конкретным edge cases.
Интуиция данных: Способность искать пробелы как вручную, так и автоматически.
Инженерная строгость: Навыки работы с Python для создания пайплайнов и внедрения LLM-as-a-Judge.
Стратегическая коммуникация: Умение излагать выводы структурированно, точно и грамотно.
Давайте разберем выполнение этой гипотетической задачи по фазам:
Фаза 1: «Детектив» (Анализ данных) Прежде чем писать хоть одну строчку кода, нужно провести аудит распределения данных:
Проверка дисбаланса классов: Если «позитивных» отзывов в 10 раз больше, чем «негативных», ваша метрика Accuracy вам нагло врет.
Поиск предвзятости (bias): Не падает ли качество модели на специфических срезах (например, медицинский жаргон против разговорного языка)?
Критика статус-кво: Почему старая «глобальная точность» подвела? Сравните её с метриками, которые реально важны для несбалансированных данных.
Фаза 2: «Архитектор» (Реализация) Теперь строим фреймворк для оценки:
Python-архитектура: Используйте чистый, модульный код. Будь то Scikit-learn или Pandas, покажите, что вы заботитесь о поддерживаемости.
LLM-as-a-Judge vs. метрики: Решите, где нужны статистические библиотеки, а где не обойтись без LLM, чтобы «рассудить» нюансы сарказма или сложного медицинского контекста.
Уверенность vs. Правильность: Напишите проверку на «уверенно неверные» (Confidently Incorrect) предсказания. Это ваши самые высокорисковые ошибки.
Фаза 3: «Стратег» (Отчетность) Работа Eval-инженера – это на 20% получение цифр и на 80% объяснение того, что они значат.
Визуализация: Приложите калибровочные кривые и матрицы ошибок.
Бриф по «слепым зонам»: Структурируйте выводы. Где именно пробел? Модель пропускает «негатив», потому что там используются сложные термины? Объясните, почему старые метрики проглядели эти критические сбои.
Совет кандидатам
Работодатели в сфере ML Eval ищут не «Data Scientist Lite», а инженеров по качеству и надежности. В вашем GitHub должны быть не просто .py файлы, а README, который рассказывает историю рисков и их минимизации.
Как построить фронтенд-тесты от перехвата payload до кастомных отчётов?
В этом докладе — полный путь: выбор инструментов (Playwright + TypeScript), первые тесты, внедрение в CI/CD и расчёты покрытия. Без воды, только практика и реальные боли, с которыми столкнулись и которые решили.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
