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

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

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

Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало. Помните эту старую хохму?

Когда в новостях вспоминают о кибератаках на розничные сети, то обычно говорят про слитые базы данных, DDoS и шифровальщиков. Но что, если злоумышленник войдет в магазин с ноутбуком в рюкзаке и внимательно посмотрит по сторонам?

На связи Иван Глинкин, руководитель отдела прикладных исследований в Бастионе. Сегодня расскажу вам историю про Хакера в супермаркете, который получил доступ к конфиденциальным данным, прослушал переговоры сотрудников и даже инициировал возврат денег на чужую карту.

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

Итак, приходит Хакер в магазин и обнаруживает: 

• Кассы-трансформеры и терминалы самообслуживания — лицо современного ритейла и его ахиллесова пята.

• Кнопки вызова сотрудников — радиопередатчики с фиксированным кодом, который можно перехватить и воспроизвести.

• Беспроводные трубки стандарта DECT, которые до сих пор используют в торговых залах.

• Терминалы сбора данных — Android-устройства без пароля, с доступом к настройкам Wi-Fi.

• Сетевые провода, которые приглашают к знакомству с внутренней сетью.

Привет, Хабр! Мы протестировали zVirt 5.0 с функциональностью, которой нет в ванильном oVirt. Главное, что нужно знать: в 5.0 на каждом узле меняется гипервизорная операционная система, фактически выполняется переустановка хостов и системы управления. В статье подробно разберу, почему переход на новую версию – это не рядовое обновление пакетов, а отдельный проект со своими особенностями и подводными камнями.

Чек-лист для тестирования поисковых и RAG-систем — от базовой работоспособности поискового движка до качества генерации, агентных сценариев и поведения на неполных данных. Шесть уровней проверок, сводная таблица с инструментами для каждого уровня и глоссарий из 50+ терминов. Проверку стоит организовывать по порядку, нет смысла гонять RAG-метрики, если система не проходит Уровень 0, то проблема может быть в том, что поиск не находит документ из-за опечатки в запросе, а не в качестве генерации.

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

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

Привет, Хабр! На связи Максим Кацал, руководитель направления автоматизированного тестирования в РТЛабс.

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

В статье расскажу, как мы научились генерировать тесты прямо из JSON-схемы услуги. JUnit 5 + @TestFactory + рекурсивный обход графа маршрутов. Фреймворк, который сам прокладывает путь пользователя по приложению-конструктору, а потом проигрывает его в браузере.

Ниже раскрою архитектуру, код, подводные камни, опишу плюсы и минусы такого подхода.

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

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

Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже успели поговорить про анализ требований, создание тестовой документации и автотесты, т.е. разобрали весь shift-left с ИИ. Но у QA-инженера есть много других задач, с которыми ИИ также может помочь.

И одной из таких задач является актуализация тестовой модели. Когда она может потребоваться? Когда продукт существует уже не первый год, тест-кейсов накопилось много, они написаны разными людьми в разное время по разным шаблонам, а требования к продукту успели поменяться. В TMS накапливаются дубликаты, устаревшие шаги и кейсы, которые логичнее было бы объединить. Разбирать всё это вручную долго и дорого, и редко когда у команды есть ресурс на такой разбор. Вот тут-то вам может пригодится ИИ.

Юнит-тесты, интеграционные и Playwright E2E ловят баги в интерфейсе, но бессильны против вопроса «а не выгоднее ли просто положить стартовый капитал на депозит и ждать?». Рассказываю, как я заменил часть ручного тестирования браузерной космостратегии крошечной нейросетью-автопилотом — 49 тысяч параметров, чистый TypeScript без ONNX, и пять граблей от потолка точности 67% до сети, которая наглухо замирала при 99.7%.

Тест на List.AsQueryable() зелёный, а на проде всплывают LINQ-трансляция, null, collation, unique index и два воркера, забравшие один платёж. Разбираю, где in-memory тесты помогают, а где начинают врать.

Я плотно работаю с финтехом и ритейлом, а это как раз те сферы, где грядёт подключение к платформе цифрового рубля. Готовиться начал заранее, так как 1 сентября 2026 года тестовый контур уже обязан быть в порядке. Полгода собирал базу, расспрашивал знакомых из финтеха, ходил на вебинары – даже на те, что делали для бухгалтеров. Я даже прочитал документы Банка России. В итоге сложилась нормальная методологическая основа.

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

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

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

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

У меня есть внутренний дашборд, который собирает список рабочих копий проекта (git worktree) и показывает по каждой последнюю активность. В какой-то момент пришло сообщение: «разные ветки, а последнее сообщение и время везде одинаковые». Я открыл дашборд — и правда: каждая копия отображалась пять раз подряд, с идентичными данными. При этом тесты были зелёные, строчное покрытие — сто процентов, а мутационный прогон по этому куску показывал 97,8%. То есть все три метрики, которым принято доверять, дружно сказали «всё хорошо».

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

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

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

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

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

Привет, Хабр! Меня зовут Анатолий, я руковожу группой автоматизации и управления тестового оборудования в YADRO.

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

Хаотичная работа с тестовыми стендами — это проблема, и я пришел в компанию, чтобы ее решить. Так в YADRO появилась автоматизированная система бронирования тестовых стендов, она же Automated Testing Facility (ATF). В статье расскажу, что она умеет, на каких технологиях основана и почему под наши задачи не подошел Jenkins

Привет! Меня зовут Елена Поплоухина. Я отвечаю за развитие сообщества тестировщиков в ГК «Юзтех». В этой статье я хочу поделиться набором инструментов, которые полезны для ручного тестирования веб-приложений. Этот список собран на основе рекомендаций участников нашего сообщества.

Все ссылки и информация по инструментам актуальны на момент выхода статьи.

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

В статье разбираем практический маршрут на REST Assured 6.0.0 и JSON Schema: как закрыть структуру ответа одной проверкой, как сделать схему по-настоящему строгой и где в этой связке спрятан капкан, из-за которого схема с условной логикой выглядит рабочей, но не проверяет ничего.

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