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

Как в реальности тестируют телеком-оборудование, проверяют его на соответствие стандартам и используют искусственный интеллект, чтобы ускорять работу инженерных команд? На недавнем митапе специалисты YADRO и Сбера показали закулисье такого тестирования: от выездной лаборатории, которая ездит по городу и измеряет качество связи, до строгих conformance-проверок по 3GPP и инструментов ИИ, помогающих экономить время на рутине. В статье мы собрали записи трех докладов и разобрали, что полезного можно из них вынести.

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

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

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

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

Привет! Меня зовут Евгений Семенюк — я Test Manager, Quality Architect и специалист по внедрению AI-подходов в SDLC.
В тестировании я уже 11 лет, занимаюсь построением процессов, внедрением практик качества, автоматизацией и развитием QA-организаций. Обладаю полным набором сертификатов ISTQB Expert Level Test Management, а всего у меня 9 ISTQB сертификатов от Foundation до Expert.

За последние годы на волонтерских начала я помог 100+ инженерам подготовиться и успешно сдать ISTQB.

И чем больше я работал с людьми, тем лучше понимал одну вещь:

ISTQB — это не про “знать больше”, а про “думать иначе”.

Ниже — короткие и честные советы, которые действительно работают.

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

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

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

Я даю тебе:

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

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

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

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

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

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

Часто в работе возникает потребность жестко выдерживать тайминг при заслушивании серии докладов: при защите проектов, программ развития, дипломных работ и прочее. Если в повестке дня какого-либо мероприятия 10+ докладчиков, то без строгого соблюдения регламента невозможно не выбиться из графика. Как правило, это приводит к тому, что запланированное время мероприятия увеличивается кратно. А докладчикам, выступающим последними, фактически не достаётся должного внимания.

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

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

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

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

По последним данным статистики (данные 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 переосмыслил эту философию.