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

Привет! Я работаю в компании «ЛАНИТ Экспертиза» тест‑лидом на проектах по внедрению систем электронного документооборота и хочу поделиться практическими наработками в области формирования тестовой модели с использованием средств визуализации. В профессиональной деятельности часто встречаются ситуации, когда необходимо быстро погрузиться в систему или часть функционала и приступить к тестированию. Однако сделать это может быть невозможно по ряду таких причин, как фрагментированное описание, высокая сложность и многомерность процессов, отсутствие коммуникации с экспертами по системе. В этом случае одним из способов решения задачи быстрого погружения и старта может стать формализация процессов системы в графический вид или их комбинации, удобные для актуализации, использования и масштабирования количества участников процесса тестирования.

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

Разработка в Газпромбанке — это процесс, в котором задействовано более 3500 инженеров, пять департаментов, 59 стримов и 200+ кросс-функциональных команд.

При этом был период, когда наши команды создавали ПО разрозненно, стандарта разработки не было, практики и технологии у всех свои. Велосипеды, как в анекдоте, были у всех, но ездили по-разному. Билды проходили тесты, которые не должны были пройти, и возвращались «на доработку» едва ли не перед запланированным релизом. Что же делать, как же быть?

Да. Нужен стандарт. И нужны автоматизированные средства поддержки стандарта.

Нам не подошли ни одни из существующих Quality Gates — мы сформировали собственный набор практик проверки качества продукта (билда, сборки — всего того, чему требуется многоуровневое тестирование). Теперь у нас выросшая в семь раз частота деплоев и шикарные фильтры, построенные на тестах.

Почему мы не купили готовое решение? Что сделали? Как? Расскажем.

Привет, Хабр! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.

Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.

Ручное тестирование нового ПО АТМ трудозатратно, требует много времени и ресурсов. Зачастую действия повторяются и QA выполняет одни и те же тест-кейсы. Нашей целью было высвободить ресурс QA, уйдя от рутинного ручного тестирования к более творческим задачам путем роботизации ручного тестирования.

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

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

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

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

Меня зовут Вадим Лунин, и в обычной жизни я возглавляю команду тестирования в Альфа-Банке(Беларусь). Но есть у меня одна вредная привычка - в свободное время, которое я с трудом выкраиваю между работой и сном, я упорно мучаю свою библиотеку для автоматизации дебага Playwright тестов playwright-ai-auto-debug.

Началось всё с простой мысли: "А что если научить AI помогать с падающими тестами?" Теперь это превратилось в полноценный проект с Dependency Injection, стратегиями, фабриками и прочими словами, которые заставляют меня чувствовать себя настоящим архитектором (хотя по факту я просто тестировщик, который не может остановиться).

И вот, свет увидела версия 3.2.4. Что в ней такого особенного? Давайте разбираться!

Недавно прошла конференция Яндекса по ИИ и облачным технологиям. Впечатлила работа с AI Studio, демонстрирующая возможность создавать агентов «на лету», даже не используя программирования.

Естественно, любую вещь надо попробовать, и я принялся за дело.

Захожу в студию, выбираю модель — Qwen 3 выбрал, пишу промпт. Агент будет выполнять роль сотрудника отдела аренды, рассказывать о наличие помещений, их стоимости, площади, условиях использования и оплаты. Чтобы не усложнять, прямо в промпте в формате Json информацию и начинаю тестировать, задавая вопросы. Список вопросов прямо из записей облачной АТС, чтобы было всё по‑взрослому.

В целом ответы агента устраивают, вполне живой разговор получается.

Всем привет. Меня зовут Аня (SavAnna) я работаю AppSec и как хобби занимаюсь багбаунти. Багбаунти - отличный способ отдохнуть от своих сервисов и сменить фокус с "защиты" на "нападение". Не всегда баги ищутся целенаправленно - иногда это происходит случайно. Хочу показать, что много странных и простых багов может найти каждый.

Я устал вести таблички с серверами и сделал сервис, который теперь помогает другим.

В последние 8 лет я работал над множеством IT проектов и стартапов: от телеграм ботов, до высоконагруженных Web-сервисов. От ТЗ до MVP — в роли разработчика, тимлида, и даже продакта. И для всех этих проектов нужна была инфраструктура, которую, как правило, выбирал и поддерживал я в одиночку.

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

Привет, Хабр! На связи Галина Чупрова, главный инженер по тестированию в Рунити. Сегодня расскажу, как мы в компании пришли к тестированию документации — и почему этот шаг повысил эффективность тестирования и сэкономил команде нервы.

Инструменты вроде OpenSearch, Elastic или Kibana давно стали стандартом для поиска и визуализации логов благодаря удобству и мощной поисковой системе. Однако, когда речь заходит о сложном анализе — агрегациях, парсинге, выявлении сложных закономерностей — их встроенные средства быстро достигают предела возможностей. Особенно сложно становится, если структура логов далека от идеала: например, как у нас — всё содержимое свалено в одно поле Message в формате JSON.

Меня зовут Игорь Щегловитов, я работаю экспертом по тестированию в QC облачной инфраструктуры и веб-порталов. Раньше наша команда решала такие задачи кастомными утилитами на C#, которые выгружали логи из ELK и анализировали их локально. Однако каждое новое требование превращалось в мини-проект: доработать код, написать новые парсеры, скрипты агрегации и фильтрации. Работа замедлялась, техдолг рос.

Я решил использовать связку AI-агентов с кастомными промптами, собственный сервисный слой (MCP) для доступа к логам и LLM-модель, чтобы превращать пользовательские запросы в автоматический алгоритм анализа. Так, кейсы вроде «Посчитай уникальных пользователей за сутки» или «Проанализируй ошибки за период» решаются без ручного кодинга.

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

Недавно вышло видео “Playwright v1.56: From MCP to Playwright Agents” и на первый взгляд оно выглядит как революция:
ИИ-агент, который сам понимает, что тестировать, сам пишет тесты, сам их чинит. Никаких локаторов, никаких апдейтов при каждом изменении DOM - просто запускаешь и смотришь, как тесты выполняются.

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

"Запахи" в тестах — это полезные сигналы, которые важно уметь распознавать, чтобы писать удобные и легко поддерживаемые тесты. Мы уже писали про "запахи" в E2E-тестах; сейчас же рассмотрим распространённые ошибки, которые возникают при написании модульных тестов.

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

В книге Джерарда Месароша о паттернах в xUnit есть полезные главы о «запахах тестов», и в интернете можно найти много других полезных материалов по этой теме. Нам же показалось интересным подойти к этой проблеме не со стороны теории, а со стороны практики: какие частые ошибки можно встретить в тестах, как их исправлять, и почему именно тесты нужно писать так, а не иначе?

Мы разберём всё это на примере: напишем один модульный тест на JUnit, и по ходу дела будем исправлять возникающие ошибки. Код примера доступен на GitHub.

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

1) Статусы сценариев в Allure и как их можно использовать.

В Allure предусмотрены следующие статусы для сценариев:

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

Как за полчаса подключить автоматическое ревью кода с помощью AI Review и локальной LLM Ollama прямо в CI/CD — без токенов и VPN.

Представьте, что аутентификация — это ключ от дома, а авторизация — список комнат, в которые этот ключ открывает дверь. В современных приложениях простой ключ-пароль заменяется сложными системами: токенами, OAuth 2.0 и OIDC.

Я, Екатерина, QA Lead в «Лиге Ставок», покажу, как с помощью инструментов тестирования проводить базовые проверки: тестировать валидность токенов, отслеживать их обновление и проверять корректность прав доступа.

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

Часть 1: Эволюция аутентификации

От Basic Auth к токенам: как развивались методы проверки подлинности и почему простой авторизации стало недостаточно.

Часть 2: Современные стандарты

Single Sign-On (SSO), OAuth 2.0, форматы токенов — разбираем основные протоколы и механизмы авторизации.

Часть 3: Практика для QA

Реальные примеры тестирования: инструменты и методы для базовые проверки безопасности аутентификации и авторизации.

Привет, дорогой читатель! Я, Владимир Зиновьев, ведущий тестировщик в ИТ-команде «Северстали». Если тебя заинтересовала эта статья, то скорее всего ты такой же тестировщик, как и я, и задаёшься вопросом, как эффективно выстроить свою работу. Здесь я поделюсь долгим путём нашей команды со всеми «шишками» и успехами тестирования наших систем в большом MES-проекте. Особенно я бы порекомендовал обратить внимание на раздел с тестированием «Legacy-системы», так как там применялись довольно нестандартные и интересные подходы, по-моему мнению, конечно. Давай погружаться.

Модульные тесты, conformance по 3GPP и нюансы российского законодательства. Добавьте к этому автомобиль-лабораторию и разъезды по лесу — и получите обычный день QA-инженера в телекоме. Об этом и о многом другом поговорим на митапе по тестированию в телекоме 9 октября (воскресенье) в 18:00. Для участия в онлайн-трансляции достаточно зарегистрироваться на сайте.

В сентябре 2025 года Apple выпустила очередную версию своей настольной ОС — macOS Tahoe 26. Все ждали новых возможностей, улучшенного интерфейса и инновационный Liquid Glass. Но, уверен, никто не ожидал, что столкнется с проблемами утечки памяти, причем из-за таких базовых приложений, как «Калькулятор» и «Сообщения».

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