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

Привет, Хабр! Я Полина, продакт платформы «Своё вино» в РСХБ — цифровой платформы, которая объединяет производителей вина, потребителей, сомелье, критиков и всех любителей российского вина. Когда гость на дегустации говорит «С вином что-то не так», я слышу примерно то же, что тимлид в пятничном сообщении «У нас все упало». В целом посыл понятен, но информации ноль.

Когда гость на дегустации говорит «С вином что-то не так», я слышу примерно то же, что тимлид в пятничном сообщении «У нас все упало». В целом посыл понятен, но информации ноль.

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

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

Статья о том, как развести тестовые данные и код проверок в Java + TestNG. Пять способов — от параметров сборщика до Test Data Factory. С примерами, схемами и разбором ограничений. Для тех, кто только начинает писать автотесты на Java.

Недавно у меня была итерация тестирования. Задача — проверить функционал, для которого нужно было создать 50+ сущностей. Однотипных, с разными названиями.

Обычно такое делаю через интерфейс. Открываю форму, заполняю поля, сохраняю. Потом ещё раз. И ещё. Пятьдесят раз. Я замерял: на одну сущность уходит примерно 20 секунд. Умножаем на 50 и получается больше 15 минут однотипных действий. А времени на итерации всегда мало.

Я уже собирался начать делать это руками, но вспомнил про fetch. Ту самую функцию, которая живёт в DevTools на вкладке Console. Пару минут на скрипт и 50 сущностей созданы за минуту. Итог: я сэкономил больше 15 минут. И заодно освоил инструмент, который теперь использую регулярно.

В статье расскажу, как это работает. Покажу шаблон запроса, научу копировать его из DevTools, отправлять пачками и параллельно. Будем использовать только браузер.

Привет! Меня зовут Алексей, я автотестер в hh.ru. У нас около 3000 запускаемых классов с e2e (UI) тестами на Java. Они прогоняются по несколько раз в день и служат основным quality gate. Но тесты периодически флакуют — становятся нестабильными, и с этим приходится работать.

Для борьбы с этим у нас работает карантин, а точнее автоматический карантин. Если тест становится нестабильным, крон исключает его из прогонов и создаёт задачу в Jira на владельца теста с просьбой разобраться в проблеме.

Подробнее о том, как мы работаем с flaky-тестами и устроили автоматический карантин, уже рассказывали на Хабре.

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

Сегодня расскажу, как мы реализовали эту задачу, почему классический RAG с векторным поиском не дал нужного результата и как в итоге пришли к подходу, в котором LLM сама определяет, какой код ей нужен для анализа.

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Общение с агентом у меня давно стало обыденным делом. И в какой-то момент я заметил, что работа тестировщика превратилась в ежедневное объяснение ему одного и того же: «прочти задачу», «составь критерии приёмки», «сделай баг-репорт», «сделай отчёт за сегодня».

Готовых QA-скиллов под мой стек на find-skills не нашлось, поэтому я собрал свои: 10 скиллов для Claude Code — от критериев приёмки и деплоя до логов, баг-репортов, тест-кейсов в Allure и отчёта. Каждую ошибку агента я превращаю в правило внутри скилла. В статье рассказал, как устроен этот QA-конвейер, где агенту нужны мои апрувы, и опубликовал скиллы в открытый репозиторий.

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

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

Q, хабряне! На связи Максим Тучков, инженер по разработке ПО в YADRO. Сегодня я хочу вам рассказать о тестировании T-RAID — одного из центральных компонентов семейства СХД TATLIN. Пройдем путь от тестирования на виртуальных машинах с легковесным образом до комплексного системного тестирования на железном окружении. Вместе разберемся, сколько требуется QA-инженеров, чтобы уверенно сказать: «T-RAID работает как надо».

Мой опыт включает изолированное тестирование T-RAID и его проверку в составе комплексных релизов СХД TATLIN.UNIFIED. За моими плечами вклад в компонентное, интеграционное, системное тестирования, тестирование производительности и проверку сервисных процедур продукта. Из раза в раз новая область тестирования открывала для меня не столько новый принцип взаимодействия с T-RAID, сколько новые критерии приемки, инструменты и сценарии тестирования. Я проследил, как меняется тестирование T-RAID на каждом из уровней, и собрал свой опыт в этой статье.

Привет! Меня зовут Александр Чернышев, я занимаюсь тестированием мобильных приложений hh.ru, и за последние полгода моя рабочая рутина кардинально поменялась благодаря ИИ-инструментам, которые мы активно используем в HeadHunter. В моём случае это Claude Code с моделью Opus 5 — по моему опыту, она лучше всего справляется с рабочими задачами. Оговорюсь: у меня подписка Max, поэтому лимитов хватает с запасом. Сейчас я подключаю агента к большинству своих задач. Основа рабочего процесса — это скиллы: инструкции, которые задают агенту последовательность действий и не дают ему каждый раз импровизировать. Вместе с ними я использую MCP-серверы и плагины, через которые агент может взаимодействовать с внешними инструментами, например с Figma (figma-mcp).

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

Привет, Хабр! Меня зовут Михаил Новотарский, в Сбере я руковожу внедрением ИИ-практик в трайбе внутренних продуктов Workspace примерно на тысячу человек, а ещё развиваю профессиональное сообщество тестировщиков.

За карьеру я успел побыть почти во всех ролях, которые есть в QA: ручное тестирование, автоматизация, full stack и менеджмент. Поэтому мне особенно интересно наблюдать, как меняется сама профессия, и хочется обсудить, изменится ли её роль в будущем. Чтобы поговорить об этом предметно, введём персонажа — QA-киберагента. Это тестировщик, который не боится нового, постоянно развивает свои навыки и пытается понять, что будет дальше.

В статье разберем, как через LFR-уязвимость во внешнем сервисе облачной инфраструктуры удалось полностью скомпрометировать облако.

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

Собрал 6 сервисов с бесплатным или стартовым доступом к LLM API и проверил их. Какие модели реально работают, что дают после регистрации, сколько уходит баланса и какие лимиты встречаются — всё на реальных запросах.

Тестирование API часто сводится к одному: отправить запрос и убедиться, что сервер ответил 200. На собеседовании этого хватает на пару минут, а в проде именно здесь всплывает то, чего статус-код не ловит: чужой заказ в ответе, молчаливый 500 вместо ошибки валидации, товар, который не списался со склада.

Разберём 20 базовых проверок, которые отличают QA, тестирующего API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы — на одном сквозном сценарии, с примерами на curl и в Postman. Начинающий выстроит последовательность, опытный сверится и поймёт, куда расширять набор тестов.

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

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

Всем привет! Сегодня хочу рассказать об особенностях автоматического тестирования крупного проекта на Django, в котором тесты написаны в разных стилях и есть много пересечений моделей данных. Поговорим о том, как привести всё к единому знаменателю без риска получить непредсказуемое поведение тестов. Также разберём конфигурацию pytest, параметры его запуска, работу с фабриками моделей и стили тестирования в двух парадигмах (Django и чистый pytest).

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

Меня зовут Михаил, в Ozon занимаюсь тестированием и автоматизацией финансовых сервисов маркетплейса. До этого за шесть лет мне довелось поработать в шести компаниях и получить опыт в проектах разного масштаба. Многие из них проходили нижеописанные этапы развития, хотя различались продуктами, командами и технологическим стеком. В этой статье я разделю этот путь на четыре условных уровня и покажу, какие метрики сигнализируют о необходимости роста, а также разберём этот процесс на всех уровнях: от архитектуры фреймворка до выстраивания процессов и TestOps.

Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.

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

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

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

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

Но тест-кейс — не синоним тестирования. Модель работает только с тем контекстом, что ей передали: не знает незафиксированные правила и может принять баг в коде за норму. Кейсов становится больше, а контроля качества — нет.

Разбираем, что ИИ реально снимает с QA, где создаёт лишь видимость покрытия и почему сгенерированный набор всё равно приходится проектировать и проверять человеку.

За последнюю пару лет появилось множество приложений на основе ИИ и ИИ‑функций. Чем больше появляется таких приложений, тем любопытнее мне становится изучить их внутреннюю работу. Надеюсь, мне удастся узнать что‑то новое; по крайней мере, почерпну какие‑нибудь знания о разработке десктопных приложений.

В то же время я заметил, что каждый месяц всё быстрее исчерпываю свои кредиты Copilot. Это заставило меня выбрать его в качестве главного кандидата для моих экспериментов. Я решил подробно исследовать VS Code и Copilot.

Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.

Что останется делать людям, когда код будут писать машины? Практика показывает — на удивление много, без работы никто не останется. В двух статьях мы опишем реальный опыт создания внутреннего агента для исправления багов в команде ТестОпс. Расскажем, сколько такой агент экономит, как его отлаживать, и чем автоматическая правка отличается от диалога с Claude Code.

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

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

Переход с Selenium на Playwright часто заканчивается теми же флаками, долгими прогонами и ручными ожиданиями.

Разбираем семь ошибок Java‑миграции и показываем, как перестроить тесты под возможности Playwright.