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

Привет, Хабр! С вами Карлен, Lead Fullstack разработчик в ITFB Group.

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

В этой статье я хочу сосредоточиться на практических приёмах, которые ежедневно использую сам. Мы пройдём путь от эффективной работы с консолью до анализа производительности и эмуляции реальных условий. Готовы выйти за рамки console.log? 😊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет! Меня зовут Марина, я QA в компании Банки.ру и сейчас занимаюсь продуктами личного кабинета, но успела поработать и в других командах. 

В IT все по-разному представляют работу тестировщика:

– Кто-то видит человека, который по 8 часов кликает на кнопки (я, честно говоря, так же представляла разработку, что уж скрывать…).
– Кто-то – душного охотника на баги, который только и делает, что пытается что-нибудь сломать.
– Кто-то вообще считает, что это просто начальная ступень в IT, чтобы потом пойти в разработку.

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

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

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

Меня зовут Арина Волошина, я AppSec-инженер в YADRO и занимаюсь тестированием безопасности телеком-продуктов: базовой станции, контроллера базовых станций и системой управления элементами сети. Мы внедрили много разных видов тестирования в эти продукты, но этого оказалось недостаточно. В своих научных исследованиях я занималась генетическими алгоритмами, поэтому решила применить академические знания на практике и реализовать генетику в фаззинге. Что из этого вышло — читайте под катом.

Тестировщикам часто приходится работать в условиях, когда бэкенд ещё не готов, API нестабильно или внешние сервисы недоступны. В таких ситуациях тестирование либо откладывается, либо превращается в угадывание «на словах».

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

Мы разберём связку Mockoon + ngrok:
— как создавать mock endpoints;
— как эмулировать 200 / 404 / 500 и другие ответы;
— как тестировать фронт и интеграции без реального бэкенда.

Статья ориентирована на QA-инженеров и подойдёт даже тем, кто никогда не писал backend.

Анализ 2500 QA-вакансий за год показывает, почему junior и manual-позиции почти не формируют спрос и на кого рынок QA реально ориентирован в 2026 году.

Сейчас на позициях любых грейдов, включая лидовские, у QA всё чаще работодатели требуют навыки разработки. Иногда это нужно, потому что позиция full-stack. Иногда это просто требование, чтобы отобрать технически подкованных ребят.

Я — Женя, QA-лид. У меня 6 лет опыта в профессии, в том числе 3 года я нанимаю и обучаю команду. Решил составить свой список того, что нужно делать QA, чтобы подготовиться к этапу технического собеседования с лайв-кодингом.

Это было интересное приключение.

Сразу оговорюсь: FlexMock не нужен всем подряд. Он вырос из моих собственных задач — когда нужно откуда-то получать разнообразные данные для собеседований, когда фронтенд уже в работе, а бэкенд ещё не готов, или когда нужно быстро собрать демо/прототип и не тратить вечер на мок-сервер.

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

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

Автоматизированное тестирование API часто начинается с простых решений в виде коллекций Postman или скриптов на коленке. Такой подход работает на старте, но быстро исчерпывает себя.

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

Статья поделена на три части.

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

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

Flaky-тесты — это вполне измеряемая форма недетерминизма, вокруг которой в исследованиях накопился свой язык. В разных статьях одни и те же слова могут означать чуть разное: где-то считают переходы pass↔fail, где-то смотрят на энтропию истории прогонов, где-то обсуждают карантин и компромисс FR против LFD. В этой статье — короткий словарь самых ходовых терминов, чтобы говорить о нестабильности тестов точным языком.

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

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