Тестирование

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

Я тогда только начинал отдавать тестирование агенту, поэтому работал по схеме «доверяй, но проверяй»: следом прошёл форму руками, с открытой вкладкой Network. Снаружи всё честно: валидация зелёная, кнопка активная, тост «Спасибо!» показывается, сервер отвечает 200. А в payload вместо темы обращения уходит строка [object Object]. Агент проверил всё, кроме того, что реально уходит на сервер.

Я QA‑инженер, тестирую web (десктоп + мобильный адаптив), совмещаю ручное тестирование и автоматизацию на Playwright. Моя цель — максимум автоматизации и минимум ручной работы, поэтому полгода я перекладываю рутинную часть тестирования на Claude Code. Схема всё та же: агент прогоняет, я параллельно проверяю руками, и каждый его пропуск превращаю в правило — через скиллы и замечания, как дообучают стажёра. Из этих правил вырос пак скиллов, который я выложил в открытый доступ: ссылка в конце статьи. Расскажу, что внутри, и покажу демо на настоящем баге. В конце — честный список того, где это всё не работает.

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

Привет, Хабр! Меня зовут Андрей, я SDET-специалист в компании SimbirSoft. В этой статье мы разберём, какие метрики действительно применимы к специалисту по автотестированию и как их корректно использовать. Будет полезно для тимлидов команд по обеспечению качества, автотестировщиков и любых специалистов, которые хотят оценить метрики автотестирования.

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

Однако возникает вопрос: как оценить вклад конкретного специалиста по автотестированию?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет, Хабр! Меня зовут Артур Валиев. Я продолжаю делать свой VST3-плагин Mix Teacher AI.

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

Но довольно быстро стало понятно, что анализировать только одну дорожку мало.

Потому что в сведении часто проблема не в одной дорожке.

Кик сам по себе нормальный.
Бас сам по себе нормальный.
Вокал сам по себе нормальный.
Барабаны вроде тоже нормальные.

А вместе всё почему-то не звучит.

И вот тут начинается самая интересная часть: конфликты между дорожками.

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

Я веду свой блог и обычно пишу про кодеки и про удаленный доступ. Эта статья — немного особенная: она не только как разработчика, но и как музыканта.

Сейчас с нейросетями стало проще писать решения. Ну, «проще» - это громко сказано. Скорее, стало проще быстрее доходить до прототипа, проверять идеи, не бояться больших кодовых баз и собирать вокруг своей боли рабочий инструмент. Но сама боль от этого никуда не исчезает.

Теперь рассказываю от имени электронного продюсера:

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

Когда я был моложе и писал музыку во FL Studio, я часто задавался вопросом: почему у меня во Fruity Loops звук такой жирный, а в других DAW — какой-то другой? Почему одни сэмплы сразу звучат «мощно», а другие теряются? Почему пресет в синтезаторе вроде бы крутой, но в миксе всё разваливается?

Со временем я понял неприятную вещь: очень часто дело не в магии DAW, не в секретном плагине и не в «аналоговом тепле». Дело в громкости, gain staging и клиппинге. В перегрузе. В том, что сигнал уже на входе почти упирается в цифровой потолок.
Сэмплы, которые мы скачиваем, часто нормализованы почти в 0 dBFS: -0.1, -0.05, иногда вообще около -0.01. Пресеты в синтезаторах могут быть перегружены ещё до того, как вы повесили первый EQ. Потом сверху добавляется компрессия, сатурация, лимитер, ещё один «улучшайзер», и внезапно микс вроде громкий, но не звучит.

Я устал постоянно вручную следить за уровнями, пиками, RMS, динамикой и частотными зонами. Поэтому начал писать свой плагин — Mix Teacher AI.

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

Какова ситуация в мобильном тестировании в 2026-м году?

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

На протяжении следующих 5 лет участвовал в запуске более 10 приложений – от MVP до многомиллионных. Я учился на ошибках, пропускал через себя сотни релизов, «съел собаку» в ручном тестировании, понял, как работают платформы, сети, железо. Хочу поделиться своими мыслями о мобильном тестировании как человек, который знает сферу изнутри.

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

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

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

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

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

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

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

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

Если коротко, то APEX — программа, которая пригодится всем, кто работает с Android-приложениями: тестировщикам, разработчикам, специалистам по безопасности и просто в случае необходимости проверить свой телефон на активность.

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

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

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

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

Итак, представьте, что вы инженер по нагрузке...