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

По последним данным статистики (данные W3Techs за 2025 год), в настоящий момент 43,1% сайтов в интернете работают на CMS Wordpress. Это самая массовая система управления содержимым. Этот факт автоматически делает эту CMS приоритетной целью для злоумышленников: широкое использование CMS дает возможности для массовых воспроизводимых атак при обнаружении любой уязвимости. 

По статистике Wordfence за 2024 год, количество обнаруженных уязвимостей в плагинах и темах выросло на 68% год к году. Причём Wordfence фиксирует, что значимая доля уязвимостей длительное время остаётся непропатченной — в том числе из-за заброшенных расширений, которые администраторы нередко продолжают держать активными.

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

Под катом мы поговорим о WPScan — инструменте, которому, на мой взгляд, уделено незаслуженно мало внимания на Хабре — всего две статьи за все время, да еще в трёх-четырёх этот инструмент упоминается вскользь. Помимо освещения практического использования самого сканера, мы разберём куда более фундаментальные вопросы: как обстоит вопрос с уязвимостями в WP и как вообще строить процесс управления уязвимостями. 

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

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

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

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

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

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

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

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

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

Какие инструменты и методы спасут от крушения в момент пика. И как выстроить устойчивость в мире маркетинга и распродаж.

Привет! Меня зовут Владислав Миронов. Я отвечаю за внедрение LLM в процессы QA Яндекса и в этой статье расскажу, каких результатов мы достигли — от генерации тест‑кейсов и автотестов до помощи в ручном тестировании. Поделюсь не только успехами, но и тем, какие компромиссы и организационные решения понадобились, чтобы всё это заработало.

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

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

В последние годы спрос на 2D/3D-инструменты в веб-сервисах растет довольно стремительно, технологии развиваются, появляются новые подходы и библиотеки — а вместе с ними растёт и путаница: что где использовать, где грань между похожими решениями и почему у разработчиков часто возникают противоположные мнения?

Так что я решила устроить небольшой тест 2D-решений: посмотреть, на что они реально способны, понять, почему результаты местами вызывают большое удивление, и ответить себе (и вам) на вопрос: а WebGPU вообще зачем?

Спойлер: всё далеко не так очевидно, как кажется.

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

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

Калифорнийский стартап 1X, бросив вызов таким гигантам, как Boston Dynamics, начал принимать предзаказы на своего человекоподобного робота NEO.

Это одна из первых серьезных заявок на создание коммерческого андроида для дома. NEO, управляемый голосом и искусственным интеллектом, обещает автоматизировать рутину: убираться, мыть посуду, стирать и даже общаться.

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

Генеральный директор 1X Бернт Бёрних прямо заявляет, что для достижения истинной автономии необходимо собрать огромный массив данных из реальных домов. Это означает, что первые владельцы NEO по сути станут участниками масштабного полевого эксперимента. Их жилища превратятся в тестовые полигоны.

Этот подход иллюстрирует фундаментальный вызов, стоящий перед всей индустрией: как можно теоретически построить систему тестирования для машин, которым предстоит работать в самой сложной и непредсказуемой среде — в человеческом доме?

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

Первоначальный энтузиазм быстро сменяется осознанием: тестирование робота — это проверка его способности взаимодействовать с хаотическим миром. И самый сложный вопрос — не «как тестировать?», а «что именно и в каком объеме нужно тестировать?».

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

Классическая ситуация:

«Я данные отправил!»

«А я не получил!»

«А они зависли где-то, потому что формат не тот!»

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

Всем привет! Я Катя, QA Tech Lead в MD Audit.

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

Список не про генерацию тест-кейсов или чек-листов — про это уже написаны километры текстов.

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

В жизни каждого фронтендера наступает момент, когда приходится перейти от родного привычного десктопа на разработку мобильной версии веб-приложения или даже начать работать над mobile-first решением, или еще страшнее — PWA-приложением.

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

Привет! На связи Полина, фронтенд-разработчик в Selectel. Раньше я тоже думала, что адаптив в десктопном браузере абсолютно такой же, как на телефонах. Да и вообще мобильный браузер — это просто браузер поменьше (спойлер — нет). В этой статье я расскажу об их различиях, что с этим делать, как прокинуть localhost на реальный телефон и получить DevTools от браузера в смартфоне, чтобы ловить поменьше багов на проде.

Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.

Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад.

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

Получаю компьютер, креды для доступа, мне подробнее рассказывают про проект, присылают ссылки на минимальный набор сервисов, что нужно будет локально поднять для работы и отправляют настраивать окружение. В первый же день я сломал заботливо предустановленную мне убунту 😂 (удалил «не ту» версию питона, которая, как выяснилась, очень нужна), ну да ладно, мелочи, с кем не бывает?

Установил минт, начал настраивать IDE, окружение, забрал себе нужные сервисы, вроде все хорошо, НО в одном из сервисов стабильно падает один и тот же тест. Запускаю отдельно — все хорошо и стабильно. Запускаю через сборщик (mvn test) — падение. Пытаюсь разобраться, что происходит — ничего не понятно. Тест падает из‑за мока, которого вообще нет в этом тестовом сценарии. Больше того, смущает ситуация, что ни на ci, ни у кого из коллег такого не происходит. Тест стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.

Привет, Хабр! Меня зовут Александр Кувакин, я backend-инженер в команде Engineering Excellence в Авито. В этой статье разберём, как backend-разработчикам выстраивать систему тестов на бэкенде и разберём основные проблемы. Речь пойдет прежде всего о тестах, которые проверяют бизнес-логику.

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

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

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