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

К 2026 году в Zscaler нет каких-то уникальных технологий, которых нельзя встретить в других продуктах. По сути, это просто очень удачно собранный и упакованный набор сервисов, который удобно потреблять как SaaS. Проблема в том, что повторить тот же набор возможностей в собственной инфраструктуре — задача нетривиальная: нужны и компетенции, и ресурсы, и бюджет, который для многих компаний оказывается избыточным.

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

В этой статье разберу один из вариантов, к которому мы в итоге пришли. Сразу оговорюсь: полную замены Zscaler мы не делали — но закрыть значимую часть задач оказалось вполне реально.

В начале ноября 2025 года децентрализованный протокол Balancer V2 (composable stable pools) подвергся атаке, суммарные потери по разным сетям превысили 128 млн долларов. Причиной стала не ошибка доступа, не реентерабельность и не баг в проверках прав, а потеря точности при расчете инварианта из-за округления. Формально проблема сводилась к округлению при масштабировании значений и выглядела как допустимый технический компромисс. Экономический эффект, однако, оказался значительным.

Взлом Balancer, как и многие другие инциденты, уже подробно разобран в формате post-mortem — с реконструкцией того, как именно была проведена атака. В этой статье подход другой: мы посмотрим на тот же код глазами аудитора, который задается вопросом «что здесь может пойти не так?».

Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.

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

JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.

Продолжаем тему эпических багов. В прошлый раз мы говорили про AT&T, положивших свою ультранадежную сеть одним «Break» в коде. Сегодня на очереди Knight Capital Group, решивших переиспользовать старый флаг в бинарном протоколе, затем там был мёртвый код, который забыли удалить и деплой, проверенный на семи серверах из восьми. Итог: уход в минус 450 миллионов долларов за 45 минут.

На Хабре этот инцидент упоминался несколько раз, но даже в самой большой статье (к слову, переводу, со всеми странными атрибутами инопрессы, вроде фраз «Атака зомби из „Кода убийцы“» и пространным вступлением) инцидент рассматривался скорее как финансовый. А нас же больше интересуют именно технические детали.

В первой части был заложен фундамент: локаторы, «умные» ассерты и хелсчеки. Это критически важные вещи, но на масштабе в 100+ тестов неизбежно возникает «второй слой» проблем — сложность диагностики и изоляция данных.

Твой тимлид открывает Jira и смотрит на статистику: за две недели ты завел три дефекта. Три. Он спрашивает, чем ты занимался все это время. Ты начинаете объяснять про двадцать багов, исправленных через личку с разработчиками. Он кивает и говорит: «Понятно. Но в системе этого нет».

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

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

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

В greenfield — минимум контроля, observability вместо code review. В brownfield — AI генерирует, человек валидирует. А там где много регуляторки ускорение есть, но и ответственность никуда не делась.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data. В Beeline Cloud у нас есть место для экспериментов — и я этим пользуюсь. Недавно я работал над шахматным ботом для игры по переписке в Телеграм. Одна из ключевых задач — генерация изображений шахматной доски из FEN-нотации.

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

Практика быстро показала, что это не так. В статье я собрала мифы о тестировании, в которые я сама верила, и то, как все оказалось на самом деле.

Привет! Меня зовут Николай, я SDET в SimbirSoft. Это продолжение серии материалов о современных подходах к разработке и тестированию, и в этот раз мы поговорим о том, как искусственный интеллект меняет повседневную работу инженера.

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

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

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

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

Мне нравится писать тесты. Написание теста и последующее обновление кода для его прохождения — всегда увлекательный процесс.

Но нет ничего хуже, чем выяснение того, что проверяют существующие тесты (раньше я сам часто был автором таких тестов).

Представляю вашему вниманию мои советы по написанию высококачественных тестов для фронтенда.

Меня зовут Семён Ремезов, я Senior QA в компании «Гринатом» (мы пишем софт для «Росатома»).

Про такие вещи обычно говорят шёпотом в курилках либо громко обсуждают, только когда уже «прилетело».

Можно, конечно, наклепать синтетических моков, но в сложных системах это мало что даст. У нас в «Гринатоме» крутятся огромные системы. Это не просто «магазин с корзиной». Это продукты с чудовищным уровнем вложенности, тоннами информации и зависимостями, которые переплетаются между собой, как корни столетнего дуба. Данные пересекаются везде и всюду.

Синтетика — это стерильная лаборатория. Моковые данные — это то, как разработчик представляет себе данные. А их реальный массив — это то, как пользователи на самом деле кошмарят систему.

Мы внедрили у себя security-лейблы в Postgres Pro Enterprise для анонимизации, и этот путь был, мягко говоря, тернистым. Если вы думаете, что анонимизация — это просто скрипт UPDATE users SET name = 'Ivan', то у меня для вас плохие новости.

Давайте разберём, как мы построили процесс, почему отказались от дорогих «коробочных» решений и как заставили Postgres 15-й версии работать нормально.

Недавно я участвовал в корпоративном хакатоне по обходу ИИ-песочниц. Задача: пройти закрытый бенчмарк PAC1, где ИИ-агенту нужно работать с виртуальной файловой системой (чтение логов, поиск файлов, отправка писем) и обходить ловушки безопасности (Indirect Prompt Injections).

Но реальность оказалась суровой: хваленые reasoning-модели постоянно галлюцинировали, ломали структуру JSON на выходе (выдавая свои "мысли" вместо чистого ответа) и просто сжигали бюджет на API, зацикливаясь на одной ошибке.

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

Чтобы человек доверял ИИ, а тот не имел возможность обманывать людей, необходимо решить проблему объяснимости, то есть описать, как нейросеть пришла к тому или иному выводу. Похожая проблема существует и в мышлении человека, который далеко не всегда может объяснить, как он приходит к тем или иным выводам (вспомним таблицу Менделеева). Решить ее, и довольно успешно, пытался еще Федор Михайлович Достоевский в рамках своего специального проекта «Дневник писателя».

Проблеме объяснимости рассуждений и выводов нейросетей посвящено множество исследований, в частности, книга «Взломать все. Как сильные мира сего используют уязвимости систем в своих интересах?», написанная экспертом по кибербезопасности, криптографом, гарвардским профессором Брюсом Шнайером.

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

Тем не менее, он считает, что «Система ИИ должна не просто выдавать ответы, но объяснять ход своих рассуждений в формате, понятном человеку. Это необходимо нам как минимум по двум причинам: чтобы доверять решениям ИИ и чтобы убедиться, что он не был хакнут с целью воздействия на его объективность». Кроме того, «аргументированное объяснение … считается основным компонентом идеи надлежащей правовой процедуры в соответствии с законом».

Как убедиться, что в аппаратном дизайне нет багов? Результаты обычных тестов иногда сигнализируют только о том, что ошибки не нашлись, а не о том, что их нет вовсе. На помощь приходит формальная верификация — метод, который проверяет все состояния системы в поисках ошибки. Для промышленной верификации есть три решения: VC Formal от Synopsys, Cadence от JasperGold и коммерческая часть Yosys. Проприетарные инструменты проверены «в бою», но доступны далеко не всем.

Меня зовут Борис Новосёлов, я младший инженер по верификации в YADRO, и я изучил альтернативы с открытым исходным кодом: CIRCT, Slang, Synlig и другие. Вы узнаете, как работают эти инструменты и на что обратить внимание при выборе решения для своего проекта.

Сразу сделаю чистосердечное признание: я ручной тестировщик. Я не умею писать код с закрытыми глазами, и да — эту статью мне тоже помог структурировать ИИ по моим промптам. Зато я умею декомпозировать задачи, выстраивать логику продукта и ломать то, что уже написано.

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

Я решил, что мне нужен инструмент, который превратит выбор фильма из рутины в развлечение. Бюджет — 0 рублей. Команда — я и нейросеть (Gemini 3.1 Pro).

В IT сейчас активно спорят про «вайбкодинг». Кто-то считает это абсолютным злом и костылестроением, кто-то — неизбежным будущим. Я решил проверить этот подход на практике и за выходные собрал MVP своего сервиса.

Открыл Postman, потыкал эндпоинты, всё ответило 200 — вряд-ли хорошее тестирование Разбираю что на самом деле нужно проверять в API, показываю примеры на Postman и Jest, и даю чеклист который можно взять и использовать прямо сейчас.

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

Я Анна Круглова, в Диасофт занимаюсь развитием инструментов автоматизации тестирования на базе искусственного интеллекта.

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

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!