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

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

Самая дорогая модель оказалась самой быстрой: 341 секунда против 395 у самой дешёвой, потому что ей нужно меньше ходов и вдвое меньше текста. Четыре задачи из пяти решили все, 32 прогона из 32. А на пятой младшая модель написала баг и отчиталась двумя галочками подряд, вторая из которых опровергает первую.

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

SQL‑инъекция через декомпиляцию: от JAR‑файла до захвата пароля

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

Корпоративная Java‑система: складской учет, веб‑интерфейс, HTTPS. Внутри — SQL‑инъекция без аутентификации в одном GET‑запросе, из‑за строки «... WHERE ID=» + параметр.

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

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

Меня зовут Миша Соколов, я старший специалист по тестированию в Контуре. Расскажу, как у нас трансформировалась система оценки QA-инженеров. Спойлер: это был путь от плоской Excel-таблички со скиллами из актуальных вакансий на рынке до разветвлённой структуры из пяти треков развития и распределённого матричного управления для 270+ QA-инженеров.

Flaky‑тесты становятся проблемой задолго до того, как их количество начинает измеряться сотнями. Один нестабильный тест способен скрыть реальный баг, замедлить CI и заставить команду тратить время на повторные прогоны. В статье разберём, почему привычные решения вроде ретраев и sleep() часто маскируют проблему, как искать скрытые источники нестабильности и какие подходы помогают сделать автотесты предсказуемее.

Осторожность кажется полезной настройкой для ИИ-агента. Но три прогона на 100 реальных багах из SWE-bench дали обратный результат: «правила дисциплины» по мотивам советов Карпати снизили число исправлений примерно на 13%. Разберём результаты эксперимента и посмотрим, в какой момент разумные ограничения превращаются для агента в тормоза.

Привет, Хабр!

Меня зовут Кирилл Кайданов, я старший инженер-программист в компании «Гарда». Я несколько лет занимался исключительно багами, достаточно редко брал какие-либо другие задачки. И так получилось, что в целом эта сфера по-прежнему осталась любимой частью работы.

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

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

Под катом делюсь мануалом, который помогает мне быстрее вычислять баги. Хотя основная часть моей практики связана с C++, но предлагаемый в статье подход универсален и не зависит от языка программирования или стека. Гарантирую, что он будет работать даже в ситуации, когда нужно разбираться с системой на незнакомом языке.

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

После большого релиза я задал себе неприятный вопрос: что именно я доказал? Что могу довести приложение до работающего состояния — да. Что людям нужна каждая из реализованных функций и они готовы возвращаться — уже не факт.

Со вторым проектом я решил поменять порядок работы. Не начинать с большого roadmap и каталога возможностей, а сначала сформулировать одно повторяемое действие, которое можно проверить. Так появился Prosnix — Telegram Mini App для личных экспериментов после пробуждения.

Это не история успешного запуска. Пользователей пилота и подтверждённых результатов пока нет. Это история о том, как попытка сделать более узкий MVP изменила мои технические решения — и почему даже одна простая продуктовая метрика потребовала state machine, нескольких версий и отдельного отношения к исходным данным.

Генератор учебных заданий положил «маши…ый» в правильную корзину, а проверка переложила слово в неправильную. При этом модель-арбитр в своём же объяснении написала «машинный». Разбираем по сохранённым ответам три сбоя проверяющей модели: что пошло не так в процессе, что поменяли в коде и чего эти правки не доказывают.

Код skillmem прошёл два независимых ревью, и я считал его чистым. Потом две модели с разных сторон — Claude и GPT — сорок раундов подряд читали его враждебно, обязанные воспроизводить каждую находку командой. Шесть P1 и около двадцати пяти P2 в коде, который «уже был отревьюен», и главный урок: каждый второй фикс рождал регрессию, которую ловил только следующий раунд.

Привет, меня зовут Евгений Когтев, я руководитель направления разработки в команде дизайн-системы «LUNA» в Домклик. Расскажу про то, как у нас появилась идея упростить создание тестов с помощью Codegen: просто ходишь по сайту, как обычный пользователь, а в соседнем окне послушно рождается аккуратный, подсвеченный синтаксисом код. Никакой магии — сплошная инженерия, подумали мы.

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

В статье разберём типичные ошибки при работе с unittest.mock, особенности patch, spec и autospec, а также когда лучше использовать фейки вместо моков.

После серьёзного инцидента часто возникает вопрос: почему проблему не удалось обнаружить заранее?
Нагрузочное тестирование помогает ответить на него, но только если это не просто запуск набора запросов.
В статье разбираем методологию НТ: от требований и профиля нагрузки до проведения тестирования и интерпретации результатов.

В одном из проектов я с нуля собирал BI-аналитику платных медицинских услуг. В отчёте нужно было показывать динамику доходов и помогать находить расхождения в данных. Когда первые страницы были готовы, визуально всё выглядело вполне убедительно: показатели считались, графики строились, фильтры переключались, явных ошибок на экране не было.

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

Но «похоже на правду» для аналитического отчёта - довольно опасный критерий. Особенно если речь идёт о финансовых показателях.

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

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

Мы в Синтеке разрабатываем софт для строительства, а отрасль сейчас переживает сложный период. Когда тяжело стройке, это довольно быстро чувствуют и компании, которые делают для неё ИТ. Поэтому в начале года у нас появилась общая задача от руководства и инвесторов: пересмотреть внутренние процессы и искать способы экономить время и ресурсы без потери качества. Отдельно попросили посмотреть, где в этих процессах можно использовать нейросети и AI-агентов. 

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

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

Собрали несколько историй с митапа в один обзор. В детали здесь специально не уходим — наиболее интересные кейсы разберём отдельно.

Hardhat 3 выбросил mocha и chai и теперь тесты гоняет родной node:test, а с контрактом разговаривает viem. Гайды по миграции подробно рассказывают про конфиги и почти ничего не говорят про то, как теперь писать сами тесты. Я пишу свой учебный проект на новом стэк и собрал рецепт целиком: каркас теста, ассерты на события и кастомные ошибки, проверка балансов с учётом газа и пять ошибок, на которые успел наступить сам

Выкатили новую фичу, а потом бэкендер со своим Firefox пишет, что у него что-то не работает? Или пользователь с Safari жалуется на неудобства? Ничего страшного: поищу причину в интернете, починю баг и продолжу использовать для разработки Chrome </sarcasm>.

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

Один open‑source тайм‑трекер на Symfony имеет 4343 теста, и все они проходят. При этом каждое сохранение записи времени отправляет в базу три дополнительных SELECT запроса: ставку самой записи, ставку проекта и ставку активности. Если в одном flush() 50 записей, а столько строк показывает страница массового редактирования, только за ставками уходит 150 запросов. Тесты этот код покрывают, но ни один не падает, в них нет ни одной проверки проблем с запросами к базе данных.

Для решения этой проблемы сделал инструмент, которого в конце августа ещё не существовало. Правда, ещё до проверок сторонних проектов на N+1, он успел несколько раз обмануть меня самого, и всегда одинаково, показывал зелёное там, где на самом деле не работал.

Три способа тихо сломать приложение сборкой зависимостей: два пула к базе, не тот кэш, разъехавшиеся ветки конфигурации. Компилятор их не ловит — типы верные. Рантайм-контейнеры ловят половину и приносят свои отказы. Про diogen — compile-time DI для Go: внедрение зависимостей на этапе компиляции, обычный Go-код на выходе, без рантайм-контейнера и без рефлексии.

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

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