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

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

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

Наш продукт позволяет клиенту подать заявку на нецелевой кредит под залог недвижимости.

Надоело, когда после сотни зеленых unit-тестов приложение падает на тестовом стенде? Когда рефакторинг превращается в кошмар из-за необходимости переписывать полсотни тестовых классов? Мне тоже надоело и я нашел решение. В статье покажу, как за два-три рабочих дня внедрить Testcontainers и начать писать тесты, которые действительно работают. В докладе вы найдете production-ready решение с PostgreSQL, Kafka и WireMock, которое выявит реальные проблемы еще до деплоя, честное тестирование реального поведения приложения.

Нагрузочный тест показывает «в среднем 800 мс», а распределённый трейс приложения упорно говорит «300 мс» — и начинается традиционная игра в ручную корреляцию. В этой статье разбираем, как связать нагрузку и наблюдаемость: запускать Locust с OpenTelemetry так, чтобы каждый запрос теста оставлял трейсы и метрики, продолжал Trace ID в сервисах и давал картину транзакции «от генератора до базы». А заодно, почему самый важный кусок времени часто прячется ещё до входа в приложение.

Всем привет! Меня зовут Александр, я старший инженер по верификации в YADRO. В блоге уже были статьи о том, как мои коллеги из других отделов мучают наши дисковые массивы, — одна из них тут. Наш отдел тоже работает с системами хранения данных, но без издевательств над массивами: мы проводим сертификационное тестирование. Результат трудов — сертификат, подписанный с обеих сторон и подтверждающий совместимость нашего изделия и стороннего программного продукта или аппаратного средства. Для коммерческих и государственных организаций такие сертификаты — серьезный аргумент при планировании закупки оборудования или ПО.

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

Apidog позиционирует себя как универсальная платформа для работы с API: проектирование, тестирование, mock-сервер, документация. Всё в одном флаконе. Звучит как маркетинг, но интерфейс выглядел приятно, в общем решил сам проверить на практике.

Пройдём полный цикл: от создания проекта до запуска тестов. Со скриншотами и личными впечатлениями.

Рынок QA давно вышел за пределы «тестирования кнопок». Анализ 2500 вакансий показывает, какие технологии сегодня считаются базовым минимумом — и почему этот минимум далеко не junior-уровня.

В этой статье я представил концепцию многофункционального тестового стенда с ии-агентом QA, предназначенным для эффективного и качественного решения любых задач тестирования бэкенда. Это решение позволяет создавать, запускать, отлаживать и хранить тестовые сценарии для сервиса без необходимости заботиться о инфраструктуре, контрактах API и других характеристиках сервиса. Важным преимуществом приложения является автономный ии-агент QA, который может решать до 85% задач тестировщика и в перспективе может полноценно заменить QA в команде разработки бэкенда.

Есть несколько практик в разработке ПО, которые, с одной стороны, являются практически неотъемлемой частью пейзажа, а с другой - довольно уродливы, если вдуматься, и сильно вредят всем (некоторые вредят AI Code-ассистентам). В этом посте я хочу поныть про автоматические тесты - священную корову разработки ПО последних как минимум 10 лет. И особенно поныть про unit-тесты.

Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. В динамичных проектах тест‑кейсы часто превращаются в «мёртвый груз»: они быстро теряют актуальность из‑за изменений в функционале, интерфейсе или бизнес‑логике. Результат — устаревшая документация, на поддержку которой тратится больше времени, чем на реальное тестирование. Разберём принципы и техники, позволяющие создавать долговечные тестовые артефакты.

Вдохновлено Михаилом Ивановым, коллегой и товарищем, который напомнил про "Мир искусства"

Вы точно хотите это читать? Это длинная и местами сложная статья. Здесь философы XVII-XX веков, проблема индукции и ни одного туториала. Если всё же решитесь - читайте частями и старайтесь осмыслить. Не говорите, что вас не предупреждали.

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

Прямое. Но не потому, что я умею "понимать людей" или "находить подход к разработчикам". Дело в другом предмете из учебного плана.

1) Задача и исходные предпосылки

Требуется организовать двусторонний аудиоканал между двумя устройствами Magewell Pro Convert Audio DX поверх сети на базе SRT. Формулировка выглядит простой, однако за ней обычно скрывается типичная путаница между тремя разными сущностями:

1. Аудиоканалы (например, стерео = 2 канала L/R).

2. SRT‑потоки / SRT‑сессии (каждая сессия переносит медиапоток в одном направлении).

3. Сетевые роли Caller/Listener (кто инициирует соединение и как это проходит через NAT/динамические IP).

Euclid Lab провела воспроизводимый эксперимент на базе Pro Convert Аudio DX : подтвердить одновременную двустороннюю передачу стерео‑аудио (full‑duplex) между двумя устройствами, используя простой и прозрачный метод контроля — USB Audio + две копии VLC на каждом ПК.

Крылатый гений сидит среди инструментов. Циркуль, весы, молоток, рубанок. Всё под рукой. Но он бездействует, подперев голову. Не от лени. Он видит проблему и понимает: имеющиеся инструменты не дают ответа.

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

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

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

Как тестируют железо на заводе, а как — в радиочастотном центре? Что общего у тестовых стендов двух крупных компаний? Что лучше: работать из дома или ездить в офис? Быть или не быть hardware-тестировщиком в новом году? На эти и другие экзистенциальные вопросы ответили инженеры YADRO, ИнфоТеКС и Яндекса. А мы собрали под катом записи докладов и дискуссии «QA в 2025: что сработало, а что — нет».

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

Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг‑репорт, киваю, вроде всё логично... но что‑то не так, как будто где это уже читал. Слова правильные. Причинно‑следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема — ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз — с трудом продираюсь через текст с каким‑то смутным понимаем того, что написано.

И тут до меня доходит - как обухом по голове.
Мои дорогие гении из техподдержки и продакт менеджер нашли «идеальный» способ сэкономить на обсуждении технической стороны проблемы со мной. И действительно, зачем? Клиент что‑то спросил. Они прогнали это через ИИ. И ИИ вник. Глубоко. Старательно. Затем сгенерировал текст, старательно объясняя мне что нужно добавить, починить и даже каким образом это сделать (не имея даже понятия о нашей кодовой базе).

И вот тут я реально взбесился. И не тихо так, а очень даже громко.

Привет всем! Меня зовут Аркадий Воронов, старший специалист по качеству. В команде у меня гибридная роль: ручной тестировщик и TestOps. О второй ветке моего развития расскажу подробнее.

В статье будут затронуты темы:

— контекст ИБ: что и зачем мы тестируем;
— основные боли и ограничения,
— инсталляционное и конфигурационное тестирование,
— матрица совместимости,
— инструменты, которые укрощают «зоопарк стендов»,
— путь развития TestOps.

Привет, Хабр! Меня зовут Дмитрий Федосов, я руковожу отделом наступательной безопасности в Positive Technologies. В этой статье мы с ведущим специалистом нашего отдела Владиславом Дриевым расскажем про автоматизацию рутины в пентесте на основании нашего опыта построения результативной безопасности.

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

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

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

Вместе со специалистами Selectel мы собрали полезные материалы для тестировщиков. В список вошли ресурсы, которые помогают развивать практические навыки, системное мышление и уверенно расти в профессии — от начального уровня до Middle.

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

В этом туториале разберем, как настроить тестовую среду и выполнить ручное тестирование IAP на Android с использованием тестового аккаунта и sandbox-режима.

В этой статье я расскажу о способе написания тестов для LLM-приложений с использованием инструмента DeepEval. Рассмотрены базовые концепции данного инструмента, а также приведен пример его использования на реальном приложении c RAG. Будет теория и много примеров на Python.

Сразу вкратце отвечу на вопрос заголовка: выбрал Suno, поскольку ему уступают Udio, Tad и Yolly.

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

Вдохновившись мемом "Вася Тестировщик", я решил реализовать этот шутливый замысел мемодела: воплотить картинку в звук.

И сделал, бонусом узнав много интересного про ИИ-генераторы. Этим и поделюсь!