QA против разработчиков: как перестать конкурировать и начать работать вместе
Есть древнее поверье, якобы разработчики и тестировщики недолюбливают друг друга. Первых раздражают бесконечные проверки, которые тормозят релиз, вторых — узкий взгляд на продукт и поверхностные фиксы. Но насколько это противостояние реально? Почему оно возникает?
В новом выпуске подкаста «Не воспроизводится» разберёмся с этим предубеждением на собственном опыте и поговорим о том, как построить коммуникацию так, чтобы сохранить дружбу и нервы.
В гостях: Илья Шорин, фронтенд-инженер, и Михаил Рогозин, бэкенд-инженер.
Ещё больше экспертизы собрали для вас насайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
PostgreSQL в «железной коробке»: как выжимать производительность, когда ресурсы ограничены
Когда под рукой нет бесконечного железа, а требования к отклику высоки, инженеру по производительности приходится искать нестандартные решения. На митапе «Гонка за производительностью» специалист ИнфоТеКС поделился опытом исследования PostgreSQL в условиях жёстких ограничений.
Разобрали, как изучать продукт, собирать стенд, готовить данные и тестировать — от hit-based до сценарных подходов. Какие инструменты реально работают и как выстроить мониторинг через Telegraf, InfluxDB и Grafana. И главное — с чем на самом деле сталкивается инженер в процессе.
Представлен открытый проект Anthropic Credited CVEs для Отслеживание уязвимостей, в отношении которых исследовательской группе Anthropic приписывается авторство и которые, возможно, были обнаружены в рамках ИБ-проекта Glasswing. В настоящее время количество обнаруженных ИИ от Anthropic уязвимостей в разных проектах (Linux, Wireshark, LibreOffice, PostgreSQL и других) достигло 300 штук.
В комментариях мне возразили: проверять ИИ бессмысленно, модель меняется каждый год, и любой стандарт устареет раньше, чем его утвердят. Если речь о том, чтобы один раз сертифицировать модель и дальше ей доверять, с этим я согласен. Но проверять можно результат на своей задаче, и здесь смена модели мешает меньше, чем кажется.
Пример из метрологии. Часы за триста с лишним лет прошли путь от маятника до атомных. Определение секунды за это время меняли несколько раз: сначала через продолжительность суток, потом через продолжительность года, с 1967 года через излучение атома цезия-133. При каждой замене новое определение подбирали так, чтобы секунда осталась той же величиной, просто стала точнее.
Модель ИИ в этой картине похожа на часы: она будет меняться. Постоянным можно сделать то, что мы проверяем. Это работает для задач, у которых есть проверяемый правильный ответ. Например, сумма в счёте или дата в договоре.
В метрологии для такой проверки есть понятие стандартного образца. Это объект с заранее установленным значением, по которому проверяют прибор. Для ИИ стандартными образцами будут реальные документы из вашей работы, для которых правильный ответ уже проверен человеком.
Как я бы это устроил:
Собрать набор реальных входов. Обязательно с трудными случаями, на которых модель чаще ошибается: таблицы, плохие сканы.
Подобрать размер набора под нужную уверенность. Если на 30 документах ошибок нет, реальная доля ошибок всё равно может доходить примерно до 9,5%. На 300 документах без ошибок она будет около 1%.
Прогонять набор при каждой смене модели или промпта.
Обновлять набор, когда меняются формы документов или сама задача. Стандартный образец устаревает вместе с задачей, смена модели на него не влияет.
Проверять можно и в рабочем потоке. В аналитических лабораториях для этого шифруют контрольные пробы: аналитик не знает, какая проба контрольная, а контролёр знает и записывает результат в журнал. С ИИ можно делать так же, только результат по контрольной задаче нельзя пускать дальше в работу. Иначе тестовый счёт однажды попадёт в бухгалтерию.
У подхода есть предел. Для стратегии или свободного текста правильного ответа заранее нет, и стандартный образец собрать не получится. Там проверять приходится сами ограничения: что агенту разрешено делать и можно ли откатить его действия. Об этом напишу отдельно.
На что вообще смотрят рекрутёры, когда нанимают тестировщиков в 2026 году? Как собрать заметное резюме, когда вокруг одни ИИ-фильтры?
Серёжа Атрощенков и Оля Шнайдер во втором выпуске подкаста «Не воспроизводится» пригласили тест-лида Авито Путешествий Ивана Алексеева
Ещё пару лет назад многие говорил, что в IT проще всего попасть через тестирование. Но в 2026 порог входа на вакансии теперь совсем другой. Ребята делятся наблюдениями и личным опытом: какие стратегии помогают найти работу, как готовиться к собеседованиям и на что на самом деле смотрят нанимающие команды.
🎧 Слушайте выпуск подкаста на всех подкаст-платформах:
Как не уйти в занос на 30 000 пользователей: детектив нагрузочного тестирования 1С
На митапе «Гонка за производительностью» инженер Postgres Professional разобрал, как готовить инфраструктуру, автоматизировать запуски и настраивать Postgres под 1С. А ещё — на какие грабли можно наступить (и как их обойти).
Тест 1С:ERP на 30 тысяч пользователей — это 11 часов имитации реального рабочего дня. Пройти его — значит доказать, что СУБД готова к крупнейшим системам страны.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Разобрал, как устроена observability xk6-sip — расширения k6 для нагрузочного и функционального тестирования SIP-звонков. Всё на реальном прогоне: 100 одновременных звонков, 10 минут, 2000 звонков, 6,1 млн RTP-пакетов.
Внутри: • ASR, SEER (RFC 6076), ALOC и SLA на native histograms — перцентили за окно, а не за весь тест • первый ответ на INVITE и ретрансмиссии: как увидеть перегрузку АТС до первого 503 • one-way audio, джиттер и потери RTP по плечам звонка • CPU, память и трафик самого генератора: АТС тормозит или тест упёрся в себя • почему закрытая модель нагрузки прячет потолок АТС
Дашборд Grafana и стек Prometheus лежат в репозитории, прогон повторяется двумя CLI командами.
Как проверить, что после обновления АТС люди слышат друг друга — без двух телефонов и тестировщика
Сделал расширение для k6, где абоненты - объекты в скрипте: звонят друг другу через АТС и проверяют АОН, переводы и слышимость. Один скрипт — и регресс в CI, и нагрузка на тысячи звонков. Под картинкой - настоящий вывод: лесенка SIP сигнализации одного звонка из trace() и метрики расширения.
Почему мониторинг, SRE и автотесты перестали работать по отдельности?
Digital Immune System (DIS) или Цифровой Иммунитет — это способность инфраструктуры почувствовать, что с ней что-то не так, и починить себя раньше, чем это заметит пользователь.
В новом выпуске «В SREду на кухне» Андрей Волхонский, Андрей Колесников и Василий Осипенко разбирается что такое DIS, из чего он состоит и почему это не просто модное словосочетание, а способ пересобрать подход к надёжности.
Гость выпуска: Михаил Савин, руководитель отдела SRE в H3LLO CLOUD
Выделенный сервер на Xeon E3: разбираем варианты переезда
Часто при выборе выделенного сервера, многие сразу смотрят на топовые мощные конфигурации. Но на практике веб-проекту редко нужен последний Xeon, а чаще важнее предсказуемость и правильный баланс ресурсов.
В SpaceWeb мы держим линейку на Xeon E3-1270 v3 — процессоре не новом, но зато проверенном годами. Варьируя лишь объем RAM и тип накопителей, можно решить почти любую задачу: от легкого сайта до файлового хранилища на терабайты.
Какую выбрать конфигурацию:
Сайт или несколько веб-проектов. 16 ГБ RAM и пара SSD — база для Битрикса, WordPress или интернет-магазина. Если проектов больше, тогда берем 32 ГБ.
Интернет-магазин или портал с контентом. Тот же процессор, но диски побольше: под базы, картинки и логи.
Бэкапы, архивы, почта. Здесь скорость SSD не нужна, поэтому ставим HDD на терабайты. Дешевле, а задачу решает.
Сайт и файлы на одном сервере. Гибрид: SSD под приложение, HDD под документы. Удобно для корпоративных порталов и Bitrix24.
Посмотреть полные характеристики и заказать нужную конфигурацию можно на сайте SpaceWeb. А если не нашли подходящий вариант — просто напишите нам на почту dedic@sweb.ru, мы поможем подобрать решение вручную.
В команде Cloudflare представили скилл Security Audit Skill, который учить нейросети искать уязвимости. Проект запускает целый рой агентов, которые ищут разные уязвимости в проекте, а затем другие ИИ-агенты перепроверяют все находки и отбрасывают ошибочные срабатывания. В итоге получается полноценный ИБ-отчёт с обнаруженными проблемами.
Модульный фреймворк для гибкого тестирования на Go — Testo
Если у вас десятки тысяч тестов, сложные сценарии, а тестам не хватает наглядных отчетов – наше опенсорс-решение может вам помочь
Testo — это слой над testing.T внутри экосистемы Go. Мы наполнили его плагинами, чтобы гибко адаптироваться под потребности и быстро создавать тесты под любую задачу.
Техническая рутина — лишь часть задач, с которыми ИИ помогает тестировщикам. Его подключают и там, где нужно глубже разобраться в изменениях, понять причину дефекта или найти пропуски в уже проведенных проверках.
Даша и Катя, тестировщики Naumen, рассказали, как встроили ИИ в работу, где он действительно экономит время и почему его результат все равно приходится проверять.
Делегировать техническую рутину
Даша, младший тестировщик в команде релизного тестирования SMRM:
Я делегирую ИИ почти все общение с командной строкой: обновить локальный репозиторий, выполнить скрипт, переключиться на ветку, установить агента. Сама я потрачу на это больше времени.
Еще часто прошу ИИ написать скрипт для тестирования, чтобы не тратить на это время разработчика.
Подключить дополнительную проверку
Катя, тестировщик в команде релизного тестирования SMRM:
Перед составлением тест-плана сначала анализирую задачу с ИИ. Потом сама внимательно все продумываю и еще раз возвращаюсь к нему, чтобы проверить, не пропустила ли что‑то.
После тестирования тоже разбираю с ИИ проведенные проверки — смотрю, все ли учла.
Анализировать изменения и дефекты
Даша, младший тестировщик в команде релизного тестирования SMRM:
С помощью ИИ анализирую изменения в задаче и смотрю, какие части системы они могли затронуть прямо или косвенно. Еще разбираю с ним причины дефектов.
Когда не получается подобрать название дефекта, отправляю в ИИ свои идеи. Он помогает их структурировать, а итоговое название я формулирую сама.
Использовать готовых ИИ-помощников
Катя, тестировщик в команде релизного тестирования SMRM:
У нас в команде уже есть несколько готовых ИИ-помощников. Один может пройтись по дефекту и подсказать, что стоит поправить. Другой анализирует покрытие автотестами — подсвечивает, что уже покрыто, а что нет.
Есть и ревьюер тест-кейсов, который помогает находить в них недочеты.
Важно: результаты ИИ тоже нужно проверять
Даша, младший тестировщик в команде релизного тестирования SMRM:
Пока ИИ не меняет процесс тестирования радикально. Но помогает не тратить время на долгий поиск информации и быстрее разбираться в сложном.
Для меня особенно важно критически подходить к ответам ИИ. Он может галлюцинировать, поэтому я использую его как помощника, а не как источник, которому можно полностью доверять.
Катя, тестировщик в команде релизного тестирования SMRM:
При анализе логов я проверяю, все ли файлы ИИ действительно прочитал. При долгом разборе он иногда начинает что‑то придумывать. Это бывает редко, но его работу обязательно нужно контролировать.
Автоматическое сравнение профилей нагрузки: как не потеряться между тестом и продом
Запустить нагрузочный тест мало — важно понять, что именно ты измеряешь и с чем сравниваешь. Эксперт Dodo Engineering на митапе «Гонка за производительностью» показал, как выстроить мониторинг профиля нагрузки и какие метрики реально работают.
Разобрали, почему без учёта исключений мониторинг теряет смысл, и при чём тут база данных. А главное — как сравнивать тестовый профиль с продакшеном и получать бинарный результат, а не просто «что-то пошло не так».
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Документация Python официально на русском. Перевод опубликован на docs.python.org и сделан сообществом. Теперь джуниоры могут ссылаться на официальный русский источник. Также появился общий стандарт переводной терминологии. Перевод будет обновляться параллельно с оригинальной документацией.
Основные улучшения в SQL: кэширование общих табличных выражений, корректная обработка join и подзапросов. Поддержка Iceberg расширена за счёт эволюции схем и других возможностей. Исправлены проблемы с вложенными списками в Arrow. Частично deprecated устаревшие параметры.
Теперь учитывается Cache‑Control индекса, что влияет на обновление недавно опубликованных пакетов. Добавлены флаги для изолированных сборок, поддержка Python 3.15, а также исправления безопасности.
Test Locks и новые API. Появилась возможность создавать именованные lock для тестов. Тесты с одним lock не запускаются параллельно. Улучшен поиск элементов во фреймах. Добавлен метод .visible() в локаторы, расширены параметры тестовых шагов и отчётов. Обновлены браузеры и исправлены баги.
Кто уже попробовал работать с lock в Playwright? А кто впервые увидел python docs на русском? Дайте знать, что оказало влияние именно на вашу практику! И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.
🎬 «Как ИИ уже изменило тестирование ПО» 14 сентября, 18:00–19:00 (Мск). Разберём, что реально делегировать, где нужна экспертиза человека и сколько это стоит. Отдельно обсудим роль QA как дирижёра ИИ-процессов, контроль стоимости токенов и логирование, а также инфраструктурные задачи и кейсы автоматизации рутины. В финале — риски: безопасность данных в LLM, рост затрат, организационные сложности и снижение компетенций при чрезмерной зависимости от ИИ. ✍️ Записаться
Пока вы наслаждались последними деньками лета, мы скроллили аналитические отчеты и изучали лучшие практики от коллег, чтобы принести вам урожай из того, что действительно стоит знать.
📊Рынок Вышел 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. Цены на участие немного кусачие, поэтому если хотите попасть, самое время начать согласовывать затраты с руководством.
У нас появилась целая пачка горячих вакансий, которая ждет ваших откликов:
Как не провалить пилот ESB: разберем два реальных сценария на онлайн-конференции
Когда компания выбирает новую интеграционную шину, почти всегда возникает идея: сначала провести пилот. На бумаге все выглядит просто — взять несколько интеграций, проверить платформу и понять, подходит ли она под текущий ИТ-ландшафт.
На практике вопросов гораздо больше.
Что именно включать в пилот?
Какие сценарии действительно показательны?
Нужно ли проверять только функциональность или еще производительность, мониторинг и удобство сопровождения?
Стоит ли отдавать пилот интегратору или пробовать силами внутренней команды?
15 сентября в 11:00 вместе с DATAREON проведем онлайн-конференцию «Архитектурная лаборатория: как выбрать ESB под вашу ИТ-архитектуру». Разберем не только возможности платформы, но и то, как организовать пилот так, чтобы он действительно помог принять решение.
Что будет в программе
Сергей Скирдин, технический директор «Белого кода», расскажет:
как сегодня выглядит российский рынок шин данных;
какие критерии стоит учитывать при выборе ESB;
в чем преимущества DATAREON Platform;
зачем пилотировать платформу на реальном ИТ-ландшафте;
какие задачи стоит закладывать в пилот.
Иван Макушов, аналитик Ikon Tyres, поделится опытом пилота с внешним подрядчиком:
как в компании подходили к выбору новой интеграционной платформы;
какие технические требования сформировали;
какие сценарии включили в пилот;
на что стоит обратить внимание при работе с интегратором..
Дмитрий Сидоренков, архитектор 1С «Уральской Агропромышленной Группы», расскажет про другой путь — пилот и дальнейшее внедрение внутренними силами:
почему одного обучения недостаточно, чтобы начать реальный проект;
какие специалисты нужны внутри команды;
почему хотя бы один человек должен быть глубоко погружен в проект;
где самостоятельной команде все же полезна внешняя экспертная поддержка;
как перейти от первого работающего обмена к самостоятельному развитию интеграций.
По сути, сравним два сценария:
пилот с подрядчиком и пилот внутренней командой.
Если вы сейчас выбираете ESB, планируете пилот DATAREON или пытаетесь понять, сколько своих ресурсов придется в него вложить, думаю, этот разговор будет полезен.
Еще одна интересная форма тупости у нейросеток (сначала Claude Sonnet 5, потом Claude Opus 5): оно не понимает, что если устройство (нетривиальное, то есть у которого есть внутреннее состояние) выдало глюк на тесте в первую секунду работы, то бесполезно минимизировать количество глюков, которое оно выдаст в следующий час. Оно уже глючное, нужно исправлять первый глюк. Прогресс - это не “было 100 глюков в час, стало 80”, а “был глюк на первой секунде теста, а теперь глюк появился только на второй”.
Дал нейросетке задание: исправить ошибку в сгенерированном ею модуле на языке описания аппаратуры SystemVerilog. Модуль погружен в тестовое окружение которое проверяет работу модуля против его модели (тоже написанной на SystemVerilog). На вход и модуля и модели подаются одни и те же входные транзакции (stimuli), после чего у них сверяется ответы. Ответы могут приходить в несколько разное время, но это не имеет значения, потому что перед проверкой они складируются в очередях. Как и исходные транзакции до отправления, чтобы не сравнивать детали латентности handshake-ов.
И у модуля, и у его модели имеется внутреннее состояние, поэтому ответ на первую и сотую транзакции может быть разный, даже если входящие транзакции идентичны. Из этого должно быть и коню понятно, что после того как ошибка произошла, дальше все идет вразнос - потому что отныне состояние у модуля и модели разное.
И вот оно провело ночь гоняя симуляции и минимизируя счетчик глюков. Ну первую ночь я бы простил. Я сказал “мерило прогресса - не счетчик глюков, а что первый глюк возникает позже”. Но оно потом это забыло и снова провело ночь минимизируя счетчик глюков.
Это из той же оперы как “если ты услышал что часы на башне пробили 13 раз, то скорее всего неверным является не только 13-й удар колокола, но и 12 предыдущих”. Или если у тебя syntax error в коде на Си в строке 100, то зачем проводить всю ночь пытаясь минимизировать количество syntax errors в последующих строках?
