Тестирование

Ближайшие бесплатные вебинары:

🎬 «Как ИИ уже изменило тестирование ПО»
14 сентября, 18:00–19:00 (Мск).
Разберём, что реально делегировать, где нужна экспертиза человека и сколько это стоит. Отдельно обсудим роль QA как дирижёра ИИ-процессов, контроль стоимости токенов и логирование, а также инфраструктурные задачи и кейсы автоматизации рутины. В финале — риски: безопасность данных в LLM, рост затрат, организационные сложности и снижение компетенций при чрезмерной зависимости от ИИ.
✍️ Записаться

🎬 «Один SQL над Iceberg, PostgreSQL и ClickHouse: как Trino выполняет федеративные запросы, и где они начинают тормозить»
15 сентября, 17:00–18:00 (Мск).
Один SQL над Iceberg, PostgreSQL и ClickHouse: как Trino выполняет федеративные запросы и где они тормозят. На живом примере с EXPLAIN ANALYZE — план выполнения и способы ускорения, от фильтрации и материализации до вычислений в источнике. В финале — сравнение с PostgreSQL/Greenplum, ClickHouse и Spark SQL и что меняется в проде.✍️ Записаться

Пять болевых точек 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)

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

РТЛабс на Moscow QA #26

Ведущий разработчик Кирилл Куратов принял участие в митапе от сообщества тестировщиков и QA-инженеров Москвы. Он рассказал, почему автоматизация тестов заканчивается там, где начинаются тестовые учётные записи

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

QA-эксперт Авито о том, почему вход в IT через тестирование больше не работает

Всем привет! Гостья нового выпуска AviTalk — Соня Каребина, QA-эксперт Центра экспертизы обеспечения качества в Авито. До IT у неё были инженер-нефтяник и администратор фотостудии — то есть путь в тестирование получился совсем не прямым. Ведущий выпуска — Виктор Раев, руководитель разработки юнита Services Base.

Говорим о том, почему в тестировании нет универсального ответа «релизить или не релизить» и как QA оценивает риски для пользователей и бизнеса. Разбираемся, почему умение договариваться для тестировщика важно не меньше технической экспертизы, и каким становится процесс, когда человек и AI работают в связке. А ещё — про волонтёрство, эмоциональное выгорание, вязание, двести комнатных растений, мечту о Марсе и принцип, который в своё время помог Соне сменить профессию.

Смотреть выпуск:

🔵 VK Видео
📺 YouTube
📌 RuTube

AviTalk — шоу толковых людей. Приглашённые гости — сотрудники Авито из разных дирекций и команд, которые делятся экспертизой и рассказывают о своём профессиональном пути.

В Parano1d адреса можно получить из фотографии.

Кошелёк превращает исходный файл в 256-битный секрет и создаёт из него адрес. Никакой seed-фразы, пароля или набора слов. Чтобы восстановить тот же адрес, достаточно сохранить оригинальный файл без изменений.

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

Документация: https://docs.parano1d.org/wallet/photo-key
Релиз: https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

Публичная тестовая сеть Parano1d v2 запущена. Текущий релиз v2.0.1.
https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

Parano1d совершенно новая архитектура блокчейна. Здесь всё устроено иначе.

Зачем?

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

Новая архитектура и отказ от подписей и эллиптических кривых позволили сделать Parano1d постквантовым уже сегодня. Безопасность всей цепочки проверки, от genesis до любой высоты формально доказана на уровне NIST PQC Category 1.

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

Настоящее должно доказывать прошлое. Теперь оно это делает.

Документация: https://docs.parano1d.org/
Исследования: https://lab.parano1d.org/

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

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

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

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

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. Добавлены новые форматы комментариев для подавления предупреждений и улучшен вывод исправлений.

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

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

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

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

{
  "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 руками и автотестов у вас нет, расскажите в комментариях, как вы ловите такие расхождения. А если захочется посмотреть на инструмент вживую, напишите мне, я покажу и дам доступ, он бесплатный.

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

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

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

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

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

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

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

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

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

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

Энтузиаст электроники и ПК под ником Uwoslab собрал внешнюю «батарею» из 192 обычных пальчиковых батареек AA (высокотоковые щелочные Pookell) и заставил на ней работать ПК без подключения к сети, без штатного блока питания.

В начале проекта Uwoslab запланировал использовать 400 батареек: закупил четыре упаковки по сотне и 50 групп по восемь элементов. В процессе работы конструкция вышла проще. На всё ушло 192 батарейки. Энтузиаст распределил элементы по трём блокам, по 64 штуки в каждом. Ток от этой такой мегабатареи идёт напрямую в материнскую плату через переходник 12V DC-to-ATX.

По прикидкам Uwoslab, именно сборка из 400 таких батареек могла бы выдавать около 160 Вт на протяжении десяти часов. Характеристики ПК: система на сокете AM4 со встроенной графикой и без накопителя. ОС грузится прямо с флешки - Hannah Montana Linux на базе Debian.

На старте батарейный блок выдавал около 13 В, а под нагрузкой встроенного теста stress-ng, когда процессор загрузили на 98%, напряжение просело лишь до стабильных 11,95 вольта — ПК работал штатно. По остаточному заряду автор предположил, что она могла бы протянуть ещё пару часов, прежде чем напряжение упадёт слишком сильно. Также энтузиаст запустил на таком ПК FreeDoom.

Тёмные века в теории тестирования

Всем привет, хочу поделиться некоторым наблюдением над инфополем в тестировании. На мой взгляд, после имперского расцвета мы лет 10-15 как вступили в тёмные века. В начале 2000-х Рекс Блэк и компания знатно потрудились над пропагандой единого глоссария, он стал общеупотребимым и более-менее исчерпывающим.

Если раньше раздробленность в терминологии и классификациях можно было встретить только в тестировании производительности, каждый крупный вендор (Microsoft, IBM, Google) придумывал свою иерархию, то теперь каждая заметная статья и/или перевод оной стремится ввести свой "уникальный" термин. Если в "имперские времена" можно было только у Microsoft прочитать про Capacity testing, за этим просматривалась некоторая логика - вендоры предлагали с терминологией свои фреймворки и подходы - то сейчас все чаще ловлю себя на мысли, что затруднительно сделать вывод о том, зачем совершенно не новаторские процессы описывают новыми терминами. Тем временем многие до сих пор путают integrated и integration...

Может мне кто-нибудь объяснить в чем "shift left" отличается от забронзовевшего раннего тестирования (early testing)? Чем модный концепт "quality gates" не просто набор "exit criteria"? T-shaped модель вполне укладывается один из 7 базовых принципов концепции тестирования - тестирование зависит от контекста, знание контекста (в том числе предметной области) необходимо для составления грамотных тестов.

Примеры можно множить и множить. А как вам кажется, имеет ли смысл кипа новых или относительно новых терминов?

Невидимый балласт: тесты, которые уже мертвы

«Иллюзия безопасности» — когнитивное искажение, заставляющее нас цепляться за мёртвые тесты. Мы боимся удалять, потому что кажется: они ещё пригодятся. На самом деле они только засоряют прогоны и снижают доверие к оставшимся проверкам.

Эксперт из Nexign на QA-days разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.

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

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

Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»

Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.

Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.

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

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.

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