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

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

Хотел бы поделиться способами отправки отчетов в один агрегированный запуск Allure TestOps из нескольких Jenkins джоб. В статье описано два способа, как это сделать. Сразу хочу отметить, что через стандартный плагин withAllureUpload это сделать не получится или не получилось у меня. Может есть какой-то секретный способ, как с ним работать и/или как настраивать. Но в интернете и в документации Allure TestOps такого решения не нашел.

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

Да, у нас есть стандартные коды 400, 404, 500 и прочие популярные ошибки, но есть и куча других. Не знаю как вы, а мне периодически приходится выяснять, что значит та или иная http-ошибка и как их воспроизводить. А когда приходят задачи из категории «проверить логирование ошибок запроса ....», то иду гуглить, как их провоцировать.

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

Привет, Хабр. Меня зовут Антон, я работаю в группе нагрузочного тестирования ЮMoney и занимаюсь исследованием производительности. В статье расскажу про xk6-browser — что у нас было до него, какие у этого решения преимущества и метрики.

Дизайн-ревью —достаточно важная вещь, которая требует внимания, когда фронтенд-разработчик сверстал новую фичу, блок или целую страницу. Вовсе не для pixel perfect, который «как задизайнили, так и сверстали» — пиксель в пиксель. Pixel perfect в десктопе — это чушь, потому что нельзя сверстать так, чтобы с разных браузеров (привет, Safari) и разрешений всё смотрелось идеально. Но ошибки, которые сразу бросаются в глаза, сразу подмечаю, структурирую и обсуждаю это с разработчиком, может, появились какие-либо ограничения и прочее. Поэтому никогда не жалею время на дизайн-ревью и через DevTools сам проверяю то, что сверстал разработчик.

Все инструменты и функциональность, о которых пойдёт речь в этой статье, можно найти в браузере в «Инструментах разработчика» (клавиша F12 / Ctrl + Shift + I (на Windows) или ⌘ + ⌥ + I (на Mac), или клик правой кнопкой мыши в любом месте страницы -> Выбор пункта меню — «Просмотр кода страницы» (или «Исходный код страницы») — это и есть DevTools).

Основной элемент для работы с девтулзами — «Инспектор» (Ctrl + Shift +C на Windows и ⌥+⌘+I на MacOS) — это инструмент поиска элементов на странице браузера.

В мире, где скорость релизов и стабильность продукта становятся конкурентными преимуществами, последовательное тестирование превращается в узкое горлышко. Параллельное тестирование с использованием Selenium Grid предлагает решение: одновременное выполнение тестов на различных конфигурациях, что значительно сокращает время проверки без потери качества.

В этой статье подробно рассмотрим, как эффективно внедрить параллельное тестирование, избежать распространённых ошибок и интегрировать его в существующие процессы CI/CD. Будет особенно полезно начинающим тестировщикам.

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

Четыре года назад я упёрся в стену. Я работал QA инженером, изучал инструменты, автоматизацию, базы данных — но карьерного роста не было. Мне хотелось развиваться, двигаться в сторону тест-менеджмента, но одних технических навыков оказалось недостаточно. Тогда я впервые осознал, что не только харды определяют успех.

Soft skills стали тем, что помогло мне выйти на новый уровень. Я научился планировать, делегировать, вести переговоры, работать с командой. Всем привет! Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке и в этой статье я расскажу, какие soft skills действительно важны, как их развивать и почему без них сложно расти в IT.

По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.

С выходом .NET 9 пакет Swashbuckle.AspNetCore выпилили из шаблона Web API. Это означает, что при создании нового приложения ASP.NET Core Web API у нас больше нет привычного зеленого пользовательского интерфейса Swagger для тестирования endpoint-ов. В статье — краткий разбор, почему это произошло, и обзор альтернативы Scalar.

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

IP сообщает, откуда пришёл запрос, и на этом всё. Он не сообщает, какой язык нужен пользователю, на каком языке он говорит и какой язык понимает. Подобная система постоянно ломается — VPN, путешествия, эмиграция, страны с несколькими официальными языками. Это не умное, а раздражающее решение.

Меня зовут Роман. Я SDET-специалист в компании SimbirSoft. В этой статье поделюсь своим опытом создания тестового фреймворка с нуля для одного из наших внутренних проектов. Материал будет полезен для начинающих или уже действующих специалистов в области тестирования, которые хотят больше узнать: 

– о построении процесса автоматизации с самого начала; 

– о сложностях, с которыми может столкнуться автоматизатор;

– об инструментах для подходящего решения поставленных перед ним задач.

Также рекомендую свою статью тем специалистам, которые уже обладают базовыми знаниями Python и Docker и стремятся углубить свои навыки в автоматизации тестирования.

Для большинства разработчиков очевидно, что сначала должен появляться код, а только потом тесты для проверки работоспособности этого кода. Но в этой статье мы рассмотрим обратный процесс — Test Driven Development. В простом понимании это означает написание тестов перед написанием кода, но на самом деле этот подход гораздо шире. Тесты перед реализацией заставляют вас больше думать о том, что на самом деле ожидается, а «как» приходит позже, и «как» — это деталь реализации, которую можно изменить с помощью рефакторинга.

В этой статье, написанной на основе публикации Rogério Chaves «The complete guide for TDD with LLMs» мы рассмотрим использование больших языковых моделей (LLM) для Test Driven Development.

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

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

С каждым годом тестирование API становится всё важнее в разработке, особенно с ростом популярности Agile и DevOps. В отличие от тестирования UI, которое может быть медленным, API-тесты позволяют быстро проверять взаимодействие компонентов и получать обратную связь, что ускоряет весь процесс разработки. Эти тесты помогают не только повысить качество приложения, но и гарантируют его стабильность.

В этой статье мы расскажем о лучших open-source инструментах для тестирования API в 2025 году. Вы узнаете, какие из них подойдут для разных типов тестирования — от функционального до нагрузочного, и как выбрать подходящий инструмент для вашего проекта.

В 2006 году я захотел стать разработчиком. Учился, брал небольшие заказы, откликался на вакансии, проходил собеседования. В итоге на 10 лет застрял в эникее: ставил винду, настраивал сеть, чинил принтеры. Денег не хватало, ипотека давила, жена предлагала поехать на вахту. Но я продолжал вкатываться в IT и в итоге оказался в тестировании.

Привет! Меня зовут Виктор, я Senior QA в Outlines Tech. Если вы не можете найти себя в IT или у вас тупик в карьере — возможно, моя история покажет, что выход есть. Ниже нет инструкции, как быстро сменить профессию. Я просто расскажу, почему у меня не получилось с разработкой, как вкатился в тестирование через техподдержку и есть ли повод жалеть о потраченном времени.

В современной разработке программного обеспечения роли четко распределены: разработчики пишут код, системные аналитики формируют требования, а QA‑инженеры обеспечивают качество. Но что происходит, когда компания решает нарушить это равновесие и нанять опытных разработчиков без QA бэкграунда в отдел тестирования? Наш опыт показал, что это может привести к неожиданным результатам.

Первая статья цикла про работу AI-QA-инженера (но написана без использования AI)

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

Принять участие в AI-лихорадке я заранее не планировала. Но за последние полгода без какой-либо инициативы со своей стороны мне пришлось поучаствовать в тестировании сразу нескольких коммерческих AI-проектов (не путать с использованием AI-инструментов для тестирования). 

А каждый шестой QA-джун из наблюдаемых мной начал свою карьеру сразу в AI-компании.

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

Вам когда‑нибудь казалось, что ваша система по результатам нагрузочного тестирования «летает», а в реальном бою — вдруг не выдерживает нагрузку?

На графиках всё красиво: среднее время отклика минимальное, ошибок почти нет. Но на деле сервис падает в самый неподходящий момент.

В чём подвох? Часто проблема кроется в том, когда и как именно мы снимаем метрики во время тестирования.

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

В первой и второй частях нашего гайда мы — техлид backend-команды Rustore Григорий Рябов и руководитель команды разработки RuStore: направление платежей Александр Котельников, прошлись по всем подготовительным этапам — от Kick-off до разработки и тестирования.

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

Сегодня говорим о pytest.raises. Не о его наличии в экосистеме — это известно каждому, кто хоть раз писал тесты. Говорим о правильном использовании. Потому что между «тест проходит» и «тест действительно что-то проверяет» — пропасть.