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

Всем привет! Меня зовут Андрей Бровко, я руководитель тестирования Авито Авто. 

ИИ-агенты генерируют код за секунды, но скорость генерации кода не означает качество продукта. Если процессы разработки выстроены слабо, агенты просто быстрее доставляют дефекты.

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

Локально Testcontainers запускается за секунды, тесты стабильно зелёные, а в CI тот же набор начинает падать в трёх запусках из ста и каждый раз по новой причине.

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

У нашей команды тестирования есть множество устройств, работающих под управлением ОС "Нейтрино". В том числе есть и редкие девайсы, которые бывают нужны не только тестировщикам, но и разработчикам, которые регулярно обращались с просьбой одолжить ту или иную плату «на часок-другой» и ничего на ней временно не запускать.

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

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

В этой статье расскажем о том, как мы реализовали такой сервис.

«У нас было две горячих ноды, 75 дев-стендов, 5 видов тестов, горка внешних сервисов, и целое множество тест-кейсов всех сортов и расцветок, а также CI/CD, core-модель, пачка customer-модулей и DBUnit. Не то чтобы это был необходимый запас для интеграционного тестирования. Но если начал делать свой тестовый фреймворк, становится трудно остановиться. Единственное, что вызывало у меня опасение – это Excel. Нет ничего более беспомощного и обреченного, чем тестировщик, который вынужден заполнять 20 листов записей вручную. Я знал, что рано или поздно мы перейдем и на эту дрянь». © Хантер Томпсон, если бы работал гонзо-тестировщиком

Привет, Хабр! Меня зовут Настя Кензина, я – QA-инженер в компании HFLabs и занимаюсь тестированием CDI (Customer Data Integration) — системы управления клиентскими данными. В этой статье я расскажу, какие сложности накопились у нас за годы эксплуатации и развития тестового фреймворка, в чем минусы табличного хранения тестовых данных, и какое итоговое решение выявленных проблем мы для себя нашли.

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

В статье разберём, как deterministic simulation testing помогает управлять временем, сетью и отказами, воспроизводить сложные сценарии по seed и проверять системные инварианты на примерах FoundationDB и TigerBeetle.

При анализе кода с помощью LLM всегда есть соблазн закинуть в модель всё сразу — и пусть сама разбирается. Но на больших объёмах кода стоимость и время такого «пусть разбирается» быстро приводят нас в чувства и заставляют искать пути более экономной траты токенов.

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

Представьте: в вашей организации сотни, а то и тысячи компьютеров под управлением Windows и разных дистрибутивов Linux. Управлять этим зоопарком классическими средствами вроде Microsoft SCCM становится невозможно, особенно с учётом тренда на импортозамещение. Здесь на сцену выходит система для централизованного управления устройствами и приложениями в гетерогенной инфраструктуре из «единого окна» Колибри-АРМ.

А теперь усложним задачу: мы не хотим держать сервер в душном серверном помещении и тратить бюджет на его железо и обслуживание. Мы хотим получить отказоустойчивую, масштабируемую и безопасную инфраструктуру в аренду за разумные деньги, что может предложить российское публичное облако Cloud.ru. В этой статье покажу, как правильно подойти к развертыванию Колибри-АРМ в облаке, избежав типичных ошибок новичков.

Одноразовая ссылка сработала только один раз, старый пароль больше не подходил, а все проверки прошли. И всё же пользователь снова потерял доступ к аккаунту.

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

В статье разберём, как Pact закрывает этот разрыв между модульными и E2E‑тестами, как устроены consumer‑driven контракты, Pact Broker и can-i-deploy, и что нужно учесть, чтобы contract testing действительно останавливал несовместимые релизы, а не создавал новую точку боли.

Искусственный интеллект уже ускорил написание кода, а способность систем безопасно принимать изменения осталась прежней. Отсюда – аккуратные пулл-реквесты, зелёные тесты и инциденты, которые проявляются только в продакшене. В статье разбираем, где возникает этот разрыв и какие инженерные guardrails помогают удержать скорость без роста хрупкости.

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

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

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

При этом удобного открытого инструмента для модификации и воспроизведения такого трафика фактически нет. Коммерческие решения существуют, но зачастую либо оказываются слишком дорогими, либо не покрывают все необходимые сценарии тестирования. 

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

Мы много раз сталкивались с этой проблемой, поэтому решили разработать Attack Replay — открытую утилиту для воспроизведения и модификации сетевого трафика при тестировании СЗИ. Она объединяет в одном интерфейсе функции нескольких популярных инструментов и автоматизирует рутинные операции, связанные с подготовкой и запуском тестов.

В статье покажем, какие задачи решает Attack Replay, как устроен инструмент и какие результаты он уже дал в реальных проектах. А в конце поделимся ссылкой на GitHub с исходным кодом проекта и набором готовых pcap-файлов.

Снаружи всё выглядит рабочим: история оценена, спринт собран, релиз уже стоит в календаре. Но одно число в Jira часто скрывает объём работы, который никто не обсудил, поэтому к концу итерации тестирование внезапно становится узким местом. Разбор семи типовых ошибок поможет понять, где возникает этот разрыв и что менять в процессе, чтобы прогноз меньше зависел от интуиции.

Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать.

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

Пайплайны редко тормозят из‑за одной большой проблемы — чаще минуты незаметно съедают неработающий кэш, тяжёлые образы, очереди и лишние зависимости между джобами.

Разберём шесть типичных ошибок в настройке GitLab Runner и посмотрим, как найти узкое место до того, как команда привыкнет ждать сборку по двадцать минут.

Всем привет! Я Марго, QA-инженер команды МС в Банки.ру. 

Этой весной мы с командой автоматизировали подготовку Acceptance Criteria (это по сути такой чек-лист, по которому команда проверяет, готова ли задача) с помощью ИИ. Это сократило рутинную работу и ускорило тестирование. Ниже расскажу, как мы это сделали.

Доброго времени, Хабр! Меня зовут Эдвард Аджей, я QA Head в Т-Банке. Год назад в одном из управлений было 17 команд с нулевым уровнем зрелости QA. Возникали сложности с автоматизацией, не велась работа с метриками качества и не было роадмапа развития процессов, накапливался техдолг по тестированию. Бесконтрольно формировался бэклог дефектов. 

За три квартала мы внедрили внутреннюю модель зрелости QMM — живой инструмент, который помог снизить количество пропущенных дефектов в проде в разы, поднять автоматизацию на 30—40% и сэкономить до 15% времени QA-инженеров. Работа функции по обеспечению качества стала управляемой и прозрачной.

Но самое неожиданное — не метрики. А то, как модель изменила культуру: команды перестали ждать указаний и сами начали проводить оценку по QMM, активно формировать планы развития.

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

Я работаю автоматизатором на Python в одном российском банке, устроился относительно недавно и уже начал писать знакомым, мол, качественно зарефералю. Времена нынче странные, так что возможность рефералки — в моём представлении благо. Ну и денежный бонус вкусный, что уж скрывать.

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

От чего не мог бы? С радостью.

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

Начал я ему объяснять — задача будет такая, возможно спросят о стоимости алгоритма, ещё вот такая задача, и спросят про структуры данных такие‑то, и почитать книгу можно такую‑то, порешать задачки там‑то, но... не вдохновил я этим Колю, а только, как будто, отпугнул.

Много. Сложно. Непонятно. А от лайв‑кодинга ещё и трясёт потом после собеса.

За последние 4 месяца мне и самому пришлось пройти несколько собеседований, в том числе технических с решением задач в формате лайв‑кодинга. И мне тоже было страшно — дело же не в том, что я, по словам Коли, больше кодом занимался в своей практике, а в том, что все эти собеседования они как ЕГЭ. То есть это просто шаблоны, которые заучиваются — а ещё лучше, понимаются. Ведь программирование — не квантовая механика, не зря в IT сферу пришло так много людей за последние лет 10.

В начале 2026 года я решил проверить одну простую гипотезу: насколько сложно сегодня найти проблему безопасности в современном веб-приложении крупной компании, имея только браузер и DevTools.

Для этого в рамках одной из программ Bug Bounty я провёл ручной Black Box-анализ клиентской части веб-приложения одной из крупных российских IT-компаний.

Пару месяцев назад я попросил агента проверить форму обратной связи после рефакторинга. Через несколько минут получил отчёт: все проверки пройдены, форма работает корректно. Зелёные галочки, уверенный тон.

Я тогда только начинал отдавать тестирование агенту, поэтому работал по схеме «доверяй, но проверяй»: следом прошёл форму руками, с открытой вкладкой Network. Снаружи всё честно: валидация зелёная, кнопка активная, тост «Спасибо!» показывается, сервер отвечает 200. А в payload вместо темы обращения уходит строка [object Object]. Агент проверил всё, кроме того, что реально уходит на сервер.

Я QA‑инженер, тестирую web (десктоп + мобильный адаптив), совмещаю ручное тестирование и автоматизацию на Playwright. Моя цель — максимум автоматизации и минимум ручной работы, поэтому полгода я перекладываю рутинную часть тестирования на Claude Code. Схема всё та же: агент прогоняет, я параллельно проверяю руками, и каждый его пропуск превращаю в правило — через скиллы и замечания, как дообучают стажёра. Из этих правил вырос пак скиллов, который я выложил в открытый доступ: ссылка в конце статьи. Расскажу, что внутри, и покажу демо на настоящем баге. В конце — честный список того, где это всё не работает.

ИИ уже умеет генерировать тесты пачками, но зелёный пайплайн по‑прежнему может врать. В статье разбираем на примере Java и JUnit, как отличить тест, который действительно ловит баги, от теста, который просто создаёт иллюзию проверки.