Тестирование веб-сервисов *

OpenAI сообщила о доработке сервиса ChatGPT Sites, который позволяет по описанию от пользователя создавать, публиковать сайты и простые веб-приложения. Теперь над ИИ-проектом сайта могут работать несколько пользователей.

Вот несколько способов начать работу с сервисом Sites, если пользователем нужно вдохновение:

• запускайте панели управления для отслеживания и обмена результатами;

• личные портфолио, чтобы помочь вашей работе выделиться;

• центры онбординга, чтобы помочь новым коллегам быстрее войти в курс дела;

• игры (например, викторины) для дня рождения;

• карты ваших любимых местных мест для гостей из других городов;

• планы поездок, чтобы все были на одной волне.

Пять болевых точек QA: смотри запись круглого стола и включайся в обсуждение

На круглом столе QA-days эксперты Okko, ИнфоТеКС, Piter QA прошлись по самым острым темам тестирования:

• Доверие к QA — как заслужить и не потерять

• Рутина — враг или союзник?

• Кросс-командное vs кроссплатформенное тестирование — в чём разница и как организовать без боли

• Интеграционное тестирование — где ломается чаще всего и как чинить

• Shift Left — почему на практике внедряется так тяжело, несмотря на очевидную пользу.

Смотреть запись

Ещё больше о мероприятиях — в нашем TG-канале.

QA-дайджест за июль-август 2026

Пока вы наслаждались последними деньками лета, мы скроллили аналитические отчеты и изучали лучшие практики от коллег, чтобы принести вам урожай из того, что действительно стоит знать. 

📊Рынок
Вышел The State of Testing™ Report 2026 от PractiTest. Статистика неутешительна: 56,4% QA-команд по-прежнему оценивают по покрытию тестами и 40,1% — по покрытию автоматизацией, тогда как бизнес-влияние учитывают лишь 8,6% организаций. Это явный перекос в сторону объема работы, а не ее ценности для продукта. Похожий перекос виден и в применении ИИ: 70% команд используют его для генерации тест-кейсов и только 19,9% — для стратегического риск-анализа. Самыми передовыми инструментами сейчас называют Selenium и Playwright, при этом за владение вторым соискателям дают на 38% больше денег в год. Впрочем, возможно, это всего лишь корреляция. 

Еще забавное: отчет Perforce/Perfecto по DevOps и ИИ в тестировании свидетельствует, что 66% компаний отметили рост общих затрат после внедрения ИИ. При этом комплексный трекинг затрат на ИИ-тестирование настроен лишь у 43% — то есть тестирование с использованием ИИ растет быстрее, чем контроль затрат над ним. 

🔧 Интересные материалы на Хабре
Команда из InfoWatch рассказала, как ввела регламент стыковки ручного и автотестирования для построения единой системы контроля качества. Можно утащить к себе в практику таблицу этапов/артефактов/критериев и список ошибок, ну и саму логику стыковки. 

Ozon Tech поделился Testo — open source фреймворком для E2E-тестов на Go (Apache-2.0, 60 тыс. тестов, 500+ сервисов). В статье описывают, как это меняет работу: теперь инженер пишет проверку как обычно, а Testo сам красиво оформляет отчет, параллельно запускает тесты на сотнях машин, повторно прогоняет упавшие и передает данные между этапами. Перспективно для тех, кому надо писать и поддерживать большие end-to-end-тесты на Go.

Ребята из 2ГИС описали свой опыт тестирования приложения «в поле», ведь баги геопозиции почти невозможно воспроизвести на тестовом стенде. Описанные практики возможно пригодятся тем, чьи продукты связаны с навигацией и страдают от «глушилок».

🤖Про агентов
Коллеги из TestOps построили «Агента Смита» — платформу агентной правки багов с целью «ноль багов в бэклоге». Суть следующая: выстраивается цепочка независимых шагов, каждый из которых создает артефакт, на который опираются последующие шаги. Итог: 100 прогонов, 76 закончились открытым мерж-реквестом, 62 из них влиты (81,6%). Из влитых 53 ушли в основную ветку без единой правки человеком. Можно утащить к себе логику шагов и потестить на своих кейсах. 

Наш коллега Никита рассказал, как начал писать документацию с помощью ИИ-агента, и чем это облегчило его жизнь. Он описал, как выгружает контекст проекта в RAG и задает архитектурные вопросы, которые формируют основную часть документации. Задача человека в этом пайплайне — верифицировать все данные по первоисточникам, не пропустить убедительные галлюцинации модели в доку и зафиксировать все неформальные договоренности, без которых не понятно почему проект устроен именно так. 

💼 Для карьеры
Вышел анонс осенней конференции Heisenbug 2026, обещают 36 докладов от гигантов рынка. От нас там выступит Александр Волков, который проведет воркшоп по тому, как собрать своего QAI-агента. 

Также анонсировали SQA Days / 39. Цены на участие немного кусачие, поэтому если хотите попасть, самое время начать согласовывать затраты с руководством.

У нас появилась целая пачка горячих вакансий, которая ждет ваших откликов:

• Fullstack QA (Infra Agent)

• Fullstack QA (IaaS Terraform)

• Fullstack QA (Distributed Train)

• Fullstack QA (Managed RAG)

• Fullstack QA (ML Inference)

👉Подписывайтесь, чтобы не пропустить следующую порцию пользы. 

Полезные онлайн-ресурсы с актуальными и отчётами по информационной безопасности:

• Annual Security Reports — репозиторий, который включает в себя ежегодные отчёты по кибербезопасности от крупнейших IT-компаний.

• Phishing campaigns — репозиторий с примерами фишинговых писем, которые направлялись APT‑группировками в различные компании по всему миру. Помимо примеров, проект включает в себя презентации с разбором и описанием фишинговых атак.

• Hackerone Reports — объёмный репозиторий, который включает в себя топ отчёты HackerOne. Поможет узнать много нового и полезного (варианты эксплуатации различных уязвимостей, векторы атак и так далее).

Баг в проде — кто виноват?

На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Okko показал, как в компании ZBP учитывают не только критичность бага, но и причины его пропуска. Результат: багов первой категории стало в 2,5 раза меньше. Просто показали разработчикам, сколько они выкатывают.

• Смотреть запись доклада

Ещё больше о мероприятиях — в нашем TG-канале.

ИИ-агента Manus предлагают протестировать бесплатно на две недели без ограничений до 25 августа (без карты, без номера телефона, только регистрация на сайте):

• выполняет задачи без подсказок от начала до конца и по расписанию;

• одновременно исследует сотни сайтов, книг, статей и других ресурсов;

• команда ИИ‑систем внутри: планирование, задачи, проверка;

• ИИ‑агент сам заходит на сайты, может заказать еду, забронировать билеты или спланировать отпуск;

• работает с таблицами Excel, PDF, документами;

• правит картинки прямо на экране;

• подключается к Gmail, Slack, GitHub и другим платформам;

• показывает свои действия в реальном времени и отчитывается о них.

QA без рутины: нагрузка, автоматизация, AI и новые инструменты

В тестировании регулярно появляется новая задача, к которой вчера ещё можно было не прикасаться: проверить сервис под нагрузкой, автоматизировать UI и API, разобраться с трафиком или подключить ИИ к автотестам.

И каждый раз приходится выбирать: долго собирать решение по документации и чужим кейсам или посмотреть, как такую задачу решают на практике.

Собрали бесплатные уроки недели, которые помогут на практике разобраться с наиболее часто встречающимися проблемами.

Нагрузочное тестирование

• 13 августа, 20:00. «Минимум для старта: как провести свое первое нагрузочное тестирование». Записаться

Автоматизация тестирования

• 20 августа, 20:00. «Как ускорить создание автотестов с помощью локальных ИИ‑моделей». Записаться

• 3 сентября, 20:00. «UI и API тестирование с Java и Playwright». Записаться

• 22 сентября, 20:00. «Playwright JS: как быстро начать писать автотесты?». Записаться

• 22 сентября, 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться

ИИ в работе тестировщика

• 2 сентября, 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться

• 8 сентября, 19:00. «Автотесты 1С через ИИ: от запуска до контроля результата». Записаться

Game QA

• 24 августа, 20:00. «Тестирование игровых уровней: как находить ошибки, которые влияют на игровой опыт». Записаться

Выбирайте направление под свою текущую рабочую задачу и приходите разбирать её на практике. Участие в открытых уроках бесплатное, нужто только зарегистрироваться.

А если хочется посмотреть на QA шире — читайте материалы:

• «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)» — о том, почему качество всё сложнее подтверждать только набором проверок перед релизом и как меняется роль QA в постоянно меняющихся системах.

• «6 ошибок в метриках дефектов, из‑за которых QA теряет контроль над качеством» — о ситуациях, когда дашборды выглядят хорошо, количество багов снижается, а реальное качество продукта при этом может ухудшаться.

Полный список бесплатных уроков августа смотрите в дайджесте.

Подборка материалов: что почитать тестировщику 

Собрали в одном месте материалы о разных сторонах работы тестировщика: от проверки требований и верстки до инструментов и коммуникации внутри команды. Будет полезно и тем, кто только начинает работать в тестировании, и тем, кто уже в профессии и хочет узнать, как к знакомым задачам подходят коллеги.

➡️ Мифы о тестировании

Какие ожидания от профессии расходятся с реальностью и чем на самом деле занимается тестировщик.

➡️ Тестирование верстки

На что обращать внимание при проверке интерфейса кроме соответствия макету: тексты разной длины, переносы, отступы, состояния элементов и работа с DevTools.

➡️ Как начинающему тестировщику выстраивать рабочий диалог в команде

Как задавать вопросы, обсуждать баги без конфликтов, уточнять требования и находить общий язык с разработчиками и аналитиками.

➡️ Инструменты ручного тестирования

Подборка сервисов и инструментов, которые помогают быстрее готовить проверки, работать с тестовыми данными, файлами, запросами и интерфейсами. 

➡️ Как тестировать требования

Как находить проблемы еще до разработки: проверять требования на полноту, однозначность, выполнимость и использовать для этого вопросы, чек-листы, прототипы и другие техники.

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

Привет! На связи снова QA-сообщество 2ГИС. Подготовили новый дайджест свежих релизов.

➡️ Playwright 1.62

Появилась новая модель тестирования компонентов — stories и galleries. Теперь можно быстро создавать сценарии с конкретными параметрами и моками, а затем запускать их из галереи. Добавили возможность прерывать долгие операции через AbortSignal. Скриншоты теперь поддерживают формат WebP с разным качеством. Улучшены фильтры тестов и добавлен режим изолированных повторов для минимизации мешающих друг другу тестов. Обновились API браузера и сетевых операций. Debian 11 больше не поддерживается.

➡️ uv 0.12.0

Усилена безопасность и совместимость: теперь запрещены устаревшие форматы архивов и опасные wheel-файлы, способные нарушить виртуальное окружение. Возвращена упаковка проектов по умолчанию с uv_build. Улучшена проверка хэшей зависимостей и работа с сертификатами. Добавлено много новых стабилизированных функций и исправлений.

➡️ Robot Framework 7.5b1

Поддержка документации в Markdown и Google Style форматах облегчает создание описаний ключевых слов. Консольное логирование расширилось — теперь можно использовать собственные логгеры. Появилась возможность запускать тесты прямо из Markdown-файлов. Несколько мелких правок и исправлений.

➡️ Python 3.15.0b4 (бета)

Финальный бета-релиз с важными исправлениями и новинками: ленивые импорты для ускорения старта, новые встроенные типы frozendict и sentinel, усовершенствованный JIT и UTF-8 по умолчанию. Многие мелкие улучшения и большая стабильность.

➡️ FastAPI 0.141.x

Исправлены ошибки с фоновыми задачами и заголовками. Появилась удобная функция app.frontend(check_dir="auto") для быстрой локальной разработки с fastapi dev. Улучшена поддержка SSE и JSONL стриминга.

➡️ Ruff 0.16.0

Значительно расширился набор правил линтинга — теперь по умолчанию включено 413 проверок вместо 59. Добавлена поддержка автоформатирования Python кода внутри Markdown. Добавлены новые форматы комментариев для подавления предупреждений и улучшен вывод исправлений.

Что из этих релизов уже интересно вам? Где планируете попробовать что-то новое? Напишите в комментариях. И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.

Делаем профессиональное ревью кода и не пропускаем ни одного бага — вышел открытый инструмент Rеjudge, который проверяет код с помощью трех ИИ-агентов, а затем ИИ-судья выносит вердикт в готовый отчёт:

• каждая ИИ-модель проверяет один и тот же запрос, разбирая его в изолированном контексте. При этом ни одна модель не видит, что делают другие;

• ИИ-судья затем проверяет все три ответа, задаёт уточняющие вопросы там, где расходятся независимые проверки;

• затем судья выдает один готовый отчет, где указывает все риски, баги и уязвимости в коде.

Лишнее поле в ответе, которое никто не замечает

Когда сверяешь ответ с документацией, обычно идёшь по списку из доки. Поле на месте, тип подходящий, значение похоже на правду, дальше. Так ловится отсутствие того, что должно быть, но совершенно не ловится появление того, чего быть не должно.

По документации ответ выглядит так:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230001",
  "orderId": "ORD-2026-0723-001",
  "status": "CREATED",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "currency": "RUB",
    "vatAmount": 0
  }
}

А это то, что реально пришло со стенда:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230002",
  "orderId": "ORD-2025-0723-001",
  "stats": "CREATE",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "curency": "RU",
    "price": 46764
  }
}

Засеките тридцать секунд и посчитайте расхождения. Девять полей, глазами — ровно так, как это делается в реальной задаче.

⁂

⁂

⁂

Восемь!

1. traceId заканчивается на 0002, а ждали 0001 — ответ пришёл не на наш запрос.

2. В orderId стоит 2025 вместо 2026.

3. Поля status нет: вместо него stats,

4. значение CREATE вместо CREATED.

5. Поля currency нет: вместо него curency,

6. значение RU вместо RUB.

7. Поле vatAmount пропало совсем.

8. Появилось поле price, которого в документации нет.

Все три суммы совпали, и глаз расслабляется именно там, где надо смотреть внимательнее.

В блоке pricing по документации пять полей, а в ответе приехало шестое: price. Сверка по списку из документации его не показывает — по определению: ты идёшь по перечню известных полей, а незнакомого в перечне нет. Плюс значение в нём совпадало с total, так что даже случайный взгляд ни за что бы не зацепился. Разошлись они позже, когда логику расчёта поправили, и к тому моменту это поле уже читал клиент.

Штука в том, что лишнее поле редко бывает безобидным. Обычно это либо внутренний флаг, который случайно вылез наружу, либо отладочное значение, либо данные, которых в публичном ответе быть не должно вообще. И глазами такое ловится ровно один раз, на самом первом ответе, пока смотришь внимательно.

Я закрыл это одной проверкой. Перечислил, какие ключи разрешены на каждом уровне вложенности, и потребовал, чтобы других не было. Дальше она работает сама и краснеет, когда в ответе появляется что-то новое. В том числе когда поле честно добавили в документацию, а мне сказать забыли — тоже полезно узнать.

Собирал я это без кода, в своём настольном приложении под Windows. Указываешь путь к параметру, оператор, ожидаемое значение из документации, при желании тип данных — и всё. Запускается руками, из CI не работает, так что если у вас уже есть автотесты и человек, который их пишет, вам это неинтересно, у вас задача решена лучше.

Мне сейчас не хватает взгляда со стороны, особенно ручных тестировщиков и аналитиков. Если вы тоже проверяете API руками и автотестов у вас нет, расскажите в комментариях, как вы ловите такие расхождения. А если захочется посмотреть на инструмент вживую, напишите мне, я покажу и дам доступ, он бесплатный.

Вышел 9-й номер журнала Paged Out (#8 выпустили в июне), который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.

Как делать ИПР для сотрудника: 8 правил от эксперта Okko

На QA-days: Оkko, ИнфоТеКС и Piter QA спикер из Okko поделился подходом к формированию траектории развития QA-специалиста через индивидуальные планы развития (ИПР). Доклад поможет выстроить систему, где сотрудники растут с интересом, а не «под кнутом».

Забирай 8 готовых правил в работу.

• Смотреть запись доклада

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.

Как я это устроил (без заумной архитектуры)

Система работает на связке «бот + база данных + веб-интерфейс». Всё гениальное просто:

1. Вы листаете Telegram на телефоне и видите важный пост (гайд, чек-лист, статью).

2. Пересылаете его моему боту. Бот мгновенно подхватывает его и сохраняет в изолированную таблицу.

3. Вечером вы садитесь за ПК, открываете сайт, вводите свой Telegram ID (он нужен только как ключ, чтобы сайт понял, чьи посты показать) — и перед вами удобная интерактивная доска.

Почему это удобнее, чем просто Telegram?

Я делал проект для себя, поэтому сразу вырезал всё, что меня бесит в современном вебе:

• Никаких регистраций вообще. Никаких вводов почты, подтверждений по SMS и придумывания паролей «с одной заглавной буквой и спецсимволом». Ввел ID — работаешь.

• Живой поиск и фильтры. Когда постов становится много, вы можете искать по ключевым словам прямо в браузере. Всё фильтруется на лету, без перезагрузки страниц.

• Личные заметки прямо на карточках. Можно дописать к посту дедлайн, свои мысли или вычеркнуть выполненные пункты. Текст сохраняется автоматически, как только вы убираете курсор из поля.

• Конфиденциальность. Ваши посты подгружаются динамически. Никто другой вашу доску не увидит.

Кому это пригодится?

Изначально я думал о ребятах из крипты (охотники за Airdrop, тестнеты, DeFi-инвесторы), которым нужно по пунктам выполнять сложные активности с ПК, найдя их в мобильном телефоне.

Но в процессе понял, что штука закроет боли многих:

• Контент-мейкеров и исследователей: собирать выжимки, инсайты и референсы в одном месте.

• Студентов: скидывать материалы для курсовых и дипломов, чтобы потом структурировать на десктопе.

• Да и вообще всех, кто использует Telegram как базу знаний и устал от хаоса в «Избранном».

Инструмент абсолютно бесплатный, без скрытых подписок и ограничений. Пользуйтесь, упрощайте себе жизнь.

Буду рад здоровой критике в комментариях! Чего вам не хватает в таком функционале? Что стоит добавить в первую очередь?

Безопасность для «чайников»: зачем обычному тестировщику знать про уязвимости

На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Гринатом поделился простыми, но важными вещами: «На волне вайб-кодинга безопасность стала проявлять себя всё ярче. Тестирование безопасности постепенно внедряется в процессы обычных тестеров».

Узнай, как QA может влиять на безопасность продукта.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.

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 разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.

Открытый проект T3MP3ST превращает ИИ‑агентов в системы для поиска уязвимостей в IT‑проектах:

• это мультиагентная система, которая ищет любые уязвимости в сервисах;

• нужно только указать цель и агенты сами проведут разведку, найдут баги и предоставят отчёт;

• результаты — из 104 тестовых задач ИИ нашёл уязвимости в 90% с первой попытки.

• удобный инструмент для изучения кибербезопасности на практике.

YouTube научили проверять факты прямо во время просмотра — представлено бесплатное расширение для Chrome под названием Popup Fact Check, которое анализирует субтитры с помощью ИИ и сразу сверяет спорные утверждения с надёжными источниками. Пока что проект лучше всего работает с английскими субтитрами. Также решение умеет работать с прямыми эфирами.

Один из топовых генераторов фонов для сайтов, приложений и презентаций стал бесплатным — Paper Shaders открыли исходный код. Теперь проект можно свободно использовать в любых веб-задачах, создавать собственные инструменты, плагины и даже коммерческие продукты, объявил СЕО Paper Shaders.

Открытый проект CAPTCHA Solver — CloakBrowser + 2Captcha/CapSolver имитирует поведение человека и проходит почти все проверки на ботов. Инструмент умеет:

• решать на раз‑два более 30 видов капчи, имитирует поведение человека, чтобы обойти любые ограничения.

• ставится локально, в сервисе не надо регистрироваться и устанавливать дополнительное ПО..

Как собрать тестовый стенд, если опыта нет, а железо разное?

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. Можно адаптировать под свой стек. 

Если вы еще не писали свой первый QA-скилл, рекомендуем почитать большой разбор от Битрикса, чем скилл отличается от RAG, Tools и MCP. Дает полное понимание архитектуры и поможет избежать ошибок новичка при написании кастомных скиллов. 

💼 Для карьеры
ISTQB выпустила обновленную версию сертификации Certified Tester AI Testing (CT‑AI) v2.0, что де-факто означает появление общепризнанного стандарта использования ИИ в тестировании и тестирования самих ИИ-систем. Кому актуально, можно получить сертификат и использовать его как аргумент в переговорах с HR. 

Еще нашли бесплатный 100-страничный учебник по тестированию — удобно учиться самим и использовать для онбординга.

Вот список крупных европейских и отечественных мероприятий по разработке и тестированию.

Ну и открытая вакансия Fullstack QA у нас в Cloud.ru.

👉Подписывайтесь, будем вместе повышать качество своего ПО и разбираться, чем полезны ИИ и агентные системы. 

РБПО по ГОСТ Р 56939—2024: вебинар №28 из 30 — Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST (Frontend Application Security Testing)". На YouTube. Слайды.

Frontend-приложения (личные кабинеты, онлайн-банки, маркетплейсы, сайты, лендинги и т. д.) выполняются в браузере пользователя — традиционной "слепой" зоне для безопасности. В вебинаре рассмотрены актуальные угрозы, крупнейшие инциденты, построение модели угроз и то, как применение анализатора класса FAST (Frontend Application Security Testing) снижает риски и делает frontend-приложения безопасными. Объясняется, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессах РБПО по ГОСТ Р 56939—2024.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Прошло почти два месяца с публикации статьи.

Разраб действительно поправил часть олдовых багосов, но, как оказалось, снова забыл про базовую безопасность дев-инфры.

На одном из хостов (привет, 89.167.7.127!) наружу торчит почта: 220 mimolet ESMTP Exim 4.97 Ubuntu

После EHLO сервер сам несет на блюдечке:

• 250-CHUNKING

• 250-STARTTLS

• 250-AUTH PLAIN LOGIN CRAM-MD5

Переход в TLS оставляет CHUNKING доступным.

Некими проверками выясняется, что набор признаков указывает на наличие CVE-2026-45185 с CVSS 9.8. Повезло, что уязвимость свежая, сканеры не дремлют.

Друзья-кодеры, безопасность - не мелкие фиксы, а полный пересмотр всего.

Писал разрабу в очередной раз, ЧСВ у него знатное, до сих пор считает что дыры - база, фиксы я вряд ли увижу.

Тестирование в 2026: API, UX, QA Lead и ИИ

Тестирование давно перестало быть просто поиском багов. Сегодня 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: каталог, карточки товаров, корзина, оформление заказа, оплата и ошибки на пути пользователя.}

Больше уроков по тестированию, разработке, искусственному интеллекту и не только смотрите в дайджесте.

Пока выбираете урок, обратите внимание на материалы по тестированию:

• Как ИИ меняет работу тестировщика уже сегодня

• Навыки QA-инженера, которые остаются востребованными независимо от инструментов и трендов

• Property-based testing на практике: как находить баги, о которых вы не подумали

• Мы дали ИИ написать код и тесты: что обнаружило мутационное тестирование

Представлена мощную опция автоматизацию для 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

• when done fix every logistical error or ux error

• test every user behaviour again post fix

Как тестировать связку продуктов, не сойдя с ума?

В этом докладе рассказали, как выстроить «танец команд»: от smoke-планов до совместной стратегии развития. Обмен экспертизой, интеграционные кейсы и живые воркшопы — всё, чтобы совместимость не хромала.

• Смотреть запись доклада

Ещё больше о мероприятиях — в нашем TG-канале.

Тестовое задание для тестировщика AI-приложений

Ранее меня просили рассказать про 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, который рассказывает историю рисков и их минимизации.

Это перевод моего англоязычного поста A take-home assignment for an AI QA role (другие переводы)

Как построить фронтенд-тесты от перехвата payload до кастомных отчётов?

В этом докладе — полный путь: выбор инструментов (Playwright + TypeScript), первые тесты, внедрение в CI/CD и расчёты покрытия. Без воды, только практика и реальные боли, с которыми столкнулись и которые решили.

• Смотреть запись доклада

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Рутина убивает? А если её возглавить?

Эксперт ИнфоТеКС на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех представил методику двойной матрицы рисков: как оценить рутинные процессы, не выгореть и понять, что автоматизировать, а что оставить.

• Смотреть запись доклада

Доклад будет полезен, если ты устаёшь от бесконечной рутины, но не знаешь, с чего начать её оптимизацию и как сохранить себя и команду.

Ещё больше о мероприятиях — в нашем TG-канале.

Один день тестировщика AI-приложений (разумеется, без нарушения NDA!)

09:30 – 10:30 Смена архитектуры
Начала день с синка по нашему агентскому воркфлоу (agentic workflow). Команда разработки представила нового агента.

Задача: мне нужно убедиться, что появление нового агента не повлияло на качество системы. Предстоит сравнить старую версию системы с новой.

11:00 – 12:00 Споры о метриках
Встретились с ML-командой, чтобы решить, как мы будем оценивать этого красавца. Мы уже выходим за рамки простой точности (accuracy).

Итог: остановились на Faithfulness (отсутствие галлюцинаций) и Efficiency (не делает ли агент 10 шагов там, где достаточно двух?).

12:00 – 14:00 Python
Пора приступать. Добавляю метрики в пайплайн с помощью Python-библиотек или подхода LLM-as-a-Judge — посмотрим, что сработает лучше. Здесь я работаю напрямую с кодом проекта, а не с AQA-кодом. И должна признать: это на порядок сложнее того, к чему я привыкла. AQA-код обычно базируется на отдельных фреймворках типа Selenium, его проще понять и написать. Так что изначально для меня это был серьезный вызов.

14:00 – Обед! 

15:00 – 16:00 Посмотрим свежим взглядом
Финальный взгляд на код, прогон юнит-тестов (чтобы убедиться, что я ничего не сломала) и пуш на ревью.

(Представим, что коллеги поревьюили мой код сразу же после пуша :)). Прилетела пара комментов по поводу edge cases для неанглийских запросов.

16:30 – 17:30 Фикс
Доработала логику, закрыла комментарии и получила то самое заветное «LGTM». Мердж в main!

17:30 – 18:30 Запуск пайплайна оценки
(Идея в том, чтобы сравнить старую и новую версии системы на заранее подготовленных данных).
Прогоняю новый набор тестов на обеих версиях на разных датасетах. Чтобы учесть фактор недетерминированности, каждый прогон делаю несколько раз. При первичном анализе наткнулась на странность: новая версия «ест» меньше токенов, но работает дольше. Пытаюсь понять, в чем подвох.

18:30 – 19:00 Отчеты
Завершаю день презентацией Evaluation-отчета команде. Обсуждаем результаты в чате.

это перевод моего англоязычного поста Working day of AI QA engineer (другие переводы)

Открытый проект Python library for interacting with the Solvecaptcha API (captcha‑solving service) — это легковесная библиотека на Python, которая проходит самые популярные проверки через Solvecaptcha.

Обходит большинство самых мощных и популярных капч:

• reCAPTCHA v2 и v3;

• Cloudflare Turnstile;

• FunCaptcha (Arkose Labs);

• GeeTest и GeeTest v4;

• Amazon WAF;

• KeyCaptcha;

• Grid, ClickCaptcha, Rotate, Canvas;

• обычные текстовые и графические капчи, в том числе аудио.

Библиотека небольшая, работает стабильно, разработчики её поддерживают, добавляя новые виды капч. Можно настраивать таймауты решения капч, чтобы имитировать поведение человека.

FixProtocol: как тестировать то, о чём мало кто слышал?

Эксперт B2Broker на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех рассказал, с какими неочевидными сложностями столкнулась его команда при работе с FixProtocol и как они нашли выход. Без скучной теории — только реальный кейс и рабочие решения.

Сталкиваешься с редкими или непопулярными протоколами и ищешь подходы к их тестированию без готовых решений? Этот доклад точно будет полезен тебе.

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Привет! На связи QA-сообщество 2ГИС. Пробуем ввести новую рубрику — регулярные новости из мира разработки и тестирования. И вот первый дайджест свежих релизов.

PEP 831 — “Build CPython with Frame Pointers by Default”

Новый PEP предлагает включить frame pointers по умолчанию во всех сборках CPython. Это обеспечит корректные стеки вызовов для профайлеров, дебаггеров и eBPF‑трейсинга без необходимости пересобирать Python вручную.

→ https://peps.python.org/pep-0831/

Playwright 1.60

HAR‑запись теперь доступна напрямую через tracing.startHar() / stopHar(), появился locator.drop() для эмуляции drag‑and‑drop, а также новый метод test.abort() для мгновенного прерывания теста.

→ https://playwright.dev/docs/release-notes#version-160

TestRail 10.3.1

Вернулся тёмный режим, добавлен AI Evaluation Template с дашбордом Quality Insights — теперь можно оценивать качество LLM‑функций не только «проходит/падает», но и по показателям эффективности, безопасности и любым другим метрикам, которые нельзя привести к бинарному результату.

→ https://support.testrail.com/hc/en-us/articles/48316772215956-TestRail-10-3-1-Default-1009

Chrome DevTools 148

Теперь по умолчанию отобржается полное дерево доступности (Full accessibility tree), добавился новый раздел Crash report в Application, в Network появилась новая колока Request order (показывает порядок запросов).

→  https://developer.chrome.com/blog/new-in-devtools-148?hl=en

tox 4.54.0

В релизе добавлен экстра tox[testing] для легкой установки зависимостей плагина tox.pytest, плюс исправлены погрешности в TOML‑схеме для таблиц replace.

→ https://tox.wiki/en/latest/changelog.html#v4-54-0-2026-05-12

Добавляйте свои новости в комментарии. И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.

Тестировщик докапывается — и это не баг, а фича

Тестировщиков иногда упрекают в том, что они всё время сомневаются и докапываются. Но что, если это не особенность характера, а главный профессиональный инструмент?

В новом выпуске «Не воспроизводится» Оля Шнайдер и Сережа Атрощенков разбирают тестирование не как набор действий, а как способ мышления. Почему QA ищет не подтверждение своей правоты, а подтверждение реальности? В чём разница между «душнилой» и внимательным инженером — и как донести эту разницу до коллег? Как поиск сложных багов превращается в настоящий квест, и почему отсутствие результата — это тоже результат? И наконец, как справляться с ощущением, что «что-то не так», даже когда работа сделана хорошо.

Слушайте выпуск на всех подкаст-платформах:

🎧 Яндекс Музыка
🔵 VK Видео 
📺 YouTube
Ⓜ️ Mave

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

Открытый проект SecretScanner помогает парсить пароли, API‑ключи, токены и другие ценные данные из приложений. Сервис проверяет Docker образы и файловую систему, чтобы отыскать секреты. Внутри у каждой программы есть целая база важной инфы — можно почерпнуть множество полезностей.