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

Всем привет, меня зовут Андрей Матвеев, я разработчик в команде платформы надёжности Яндекс Такси. Если проще — я занимаюсь тем, чтобы Такси работало стабильно. А ещё я техлид проекта virtual‑orders — это наша система нагрузочных учений. Изначально она была для Такси, но теперь мы активно внедряем её в Еду и Лавку.

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

15-20 минут на ручное тестирование. После каждого коммита. 47 состояний диалога. Бесконечные «а этот edge case я проверил?». Flaky тесты с реальным API. Rate limits от Telegram. Проблема не в коде - проблема в том, как вы его тестируете. Ручное тыканье в Telegram не масштабируется. Тесты с реальным API - медленные и flaky. Свои моки писать - неделя работы. Я нашёл способ лучше: 50 интеграционных тестов за 2 секунды. Без сети. Без токенов.

«Сколько платят в QA» — вопрос не про цифры, а про роль. Анализ зарплат QA-вакансий за 2025 год по данным 2500 объявлений показывает, почему manual и junior остаются в нижнем сегменте рынка, а automation и fullstack-специалисты получают существенно больше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Axiom — это недостающий тестовый runtime для Go, который добавляет фикстуры, шаги, хуки, retry, плагины, метаданные и структурированное выполнение поверх стандартного testing, оставаясь полностью совместимым с ним. Минимум магии, максимум инфраструктуры.

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

Хочу рассказать, как мы применяем ИИ в процессе найма QA-специалистов. Без обещаний революции и без страшилок про «всех заменят». Просто покажу, какие инструменты сделали, где они реально помогают, а где пока спотыкаются. Если вы проводите или проходите собеседования — welcome. Если просто хотите посмотреть, как ИИ работает не на маркетинговых слайдах, а в боевых условиях — тоже пригодится.

В этой статье я собрал девять самых частых задач из live-coding этапов собеседований на Python — от декораторов и замыканий до GIL и паттернов. Эти задачи регулярно встречаются в компаниях разного уровня, и их знают те, кто часто участвует в найме.

Мы разберём каждую задачу: как её формулируют интервьюеры, какие типичные ошибки делают кандидаты, и как выглядит корректное решение с пояснениями. Цель статьи простая — помочь разобраться в базовых механизмах Python, которые важны как на собеседованиях, так и в реальной работе.

Здравствуйте! Меня зовут Владислав Донченко, я ведущий специалист по тестированию в Альфе. Хочу поделиться опытом преобразования огромного монолитного репозитория с автотестами в модульную структуру.

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

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

Вчера до вершины популярности Hacker News добрался этот пост Джоны Гловера:

Может ли Claude воссоздать веб-сайт Space Jam из 1996 года? Нет. Или, по крайней мере, не с моими навыками промптинга. Требуется помощь, потому что я хочу сохранить этот веб-сайт навечно, но это никак нельзя сделать, кроме как попросить Claude воссоздать его из скриншота. Поверьте мне, я менеджер по разработке со степенью по computer science. Пожалуйста, помогите 😞

Чтобы уточнить подробности своей просьбы, Джона передал Claude Code (Opus 4.1) скриншот лэндинга, папку с изображениями и следующий промпт:

Я даю тебе:

1. Полный скриншот страницы лэндинга Space Jam.

2. Папку с сырыми графическими ресурсами**, извлечёнными с исходного сайта

Твоя задача — максимально точно воссоздать страницу лэндинга в полном соответствии со скриншотом.

С подобными задачами кодинг-агенты справляются идеально. Как я часто говорю, все задачи — это задачи поиска, но этот принцип не всегда просто применить на практике. Однако в данном случае применить его очень просто! У нас есть скриншот, поэтому diff пикселей сильно упрощает работу!

Вообще, можно сказать, что сам по себе Claude Code не смог бы с этим справиться. Но Claude с конфигурациями nori¹ просто обязан это сделать.

Так что вызов принят.

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

Мы покажем, как одна логическая ошибка в продукте может привести к полному захвату аккаунтов, и объясним, как действовать, когда находишь подобный «подарок» в своей инфраструктуре.

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

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.

Когда ты тестируешь интернет-магазин, пропущенный баг — это съехавшая вёрстка. Но если ты тестируешь высоконагруженную СУБД — это остановка бизнеса федерального масштаба. Разбираем внутреннюю кухню QA в Postgres Professional: от борьбы с утечками памяти через ASAN и Valgrind до «вайб-кодинга» с ИИ. Узнайте, как выстроить процессы качества так, чтобы не уронить прод, когда цена ошибки исчисляется миллионами.

Привет! Меня зовут Юра Байков, я ведущий ведущий QA-инженер и много раз проводил собеседования на позицию тестировщика в свою команду. Да, на Хабре много постов о том, как проходят такие встречи и как к ним подготовиться. Но сегодня хочу поделиться именно своим опытом: подскажу, какие книги прочитать, чтобы укрепить базу, — шок-контент, но их всего две. А еще расскажу, о чем я спрашиваю джунов на собеседовании.

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