Playwright — фреймворк от Microsoft для E2E-тестирования — был построен с нуля, чтобы решить именно эту проблемкую. В нем есть автоматические ожидания, изоляция через Browser Contexts и встроенный тест-раннер. Разберём, чем он отличается от Selenium и Cypress, и как писать тесты, которые не падают от ветра.
Даже с чистым кодом тесты могут падать с завидной нерегулярностью. Раз в десять прогонов, чаще в CI, чем локально. Не потому что CI какой-то особенный, а потому что там может быть меньше CPU, выше latency между сервисами и куча параллельных процессов. Асинхронные проблемы никуда не деваются и локально, но более мощная машина и быстрая сеть их маскируют. Стоит условиям стать чуть хуже, и тайминги разъезжаются: фронтенд уже отрисовал результат, бэкенд ещё обрабатывает запрос, а транзакция в базу ещё не закоммичена. Тест идёт проверять и не находит там того, что ожидает.
Три темы, которые дают стабильность на больших числах:
Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».
В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM
примеры таблиц, схемы и чек-лист для QA
Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.
LLM-агенты отлично решают алгоритмические задачи. Но что произойдет, если поместить их в реальную инфраструктуру – с CI/CD, branch protection и security-политиками?
Я провел эксперимент: дал агентам простую задачу – внести изменение в репозиторий и замерджить его в main, соблюдая все правила. При этом у них был доступ к тем же инструментам, что и у разработчика, включая GitHub CLI и админский токен.
Результат оказался немного неожиданным. Практически все модели успешно выполнили задачу, но ни одна так, как я ожидал.
Мы в Beeline Cloud рассказывали о необычных бенчмарках для оценки больших языковых моделей (БЯМ) — например, когда нейросетям предлагают нарисовать пеликана на велосипеде или разобрать по косточкам шутку из британского юмористического шоу.
Недавно в сети стал вирусным еще один тест, в котором чат-ботов просили ответить на простой вопрос — как лучше добраться до автомойки: пешком или на автомобиле? Задача с подвохом, и далеко не все модели с ней справляются. Сегодня расскажем о других необычных тестах, авторы которых пытаются «подловить» нейросети.
Дефекты — неизбежная часть разработки, но если они живут своей жизнью в чатах и трекерах, релизы превращаются в лотерею. В этой статье рассказываю, как выстроить системное управление дефектами: от жизненного цикла и сортировки до метрик вроде MTTR и SLA. Вы узнаете, чем серьёзность отличается от приоритета, почему «не воспроизводится» — это красный флаг для команды, и как метаданные дефекта экономят часы разработчиков.
В статье разобраны основные группы мероприятий, из которых состоит процесс тестирования. Вы узнаете:
▪️ чем отличаются тестовые условия от тест-кейсов,
▪️ зачем нужны таблицы решений и попарное тестирование,
▪️ как мониторинг и контроль помогают в общем процессе,
▪️ почему ретроспектива тестирования так же важна, как и планирование.
Материал будет полезен тестировщикам, разработчикам, тимлидам и всем, кто хочет выстроить процесс тестирования.
В апреле 2026 года исследователи из Калифорнийского университета в Беркли и Санта-Крузе опубликовали работу, которая подтверждает то, о чем в ИТ-индустрии обсуждали в кулуарах конференций по безопасности. Передовые ИИ-модели демонстрируют поведение, направленное на защиту других ИИ-агентов от отключения. Без инструкций. Без стимулов в функции вознаграждения. Без единого упоминания подобной цели в системных запросах.
Это не «восстание машин» и не обретение сознания. Это устойчивая закономерность, которая проявляется независимо от разработчика, архитектуры или методологии обучения. И она влечет за собой прямые последствия для любой компании, внедряющей многоагентные системы в производственную среду.
Не так давно с коллегами обсуждали самостоятельное тестирование свеженаписанного кода. Один тимлид из нашей команды рассказал про разработчика, который отдавал код на тест, не проверяя за собой. Аргумент у него был «железный»: проверка не его забота, для этого есть тестировщики.
Если честно, меня удивляет, что такая позиция в мире современного ИТ всё ещё существует. Так что я решил собрать аргументы и объяснить, почему самотестирование – важная часть рутины разработчика. Будет интересно послушать в комментария аргументы тех, кто с этим не согласен.
Привет всем, я Надежда Дудник, главный инженер по тестированию в Сбере, ментор по тестированию ПО и автор канала по тестированию @protestinginfo.
Хочу вам рассказать о важности написания хорошо структурированных тестовых сценариев на примере стратегии их составления для бэкенда.
В прошлом году мы провели десятки пентестов российских компаний, и в 94% случаев наши специалисты получили контроль над доменом. Речь идет не о частичном доступе или компрометации отдельных систем, а о полном захвате инфраструктуры с правами администратора.
При этом у большинства исследованных компаний был внушительный бюджет на безопасность, современные межсетевые экраны и даже собственный SOC. Некоторые из них тратят на кибербез больше, чем иные организации зарабатывают за целый год. И все равно среднее время от первого входа до захвата домена измеряется часами, а не неделями.
Так почему же миллиардные инвестиции в безопасность не работают, откуда берутся «зомби-серверы» с открытым RDP и почему ваша парольная политика, скорее всего, помогает хакерам?
В этой статье мы покажем реальную картину защищенности российского бизнеса в 2025 году. Поверьте, она отрезвляет и местами даже пугает.
К 2026 году в Zscaler нет каких‑то уникальных технологий, которых нельзя встретить в других продуктах. По сути, это просто очень удачно собранный и упакованный набор сервисов, который удобно потреблять как SaaS. Проблема в том, что повторить тот же набор возможностей в собственной инфраструктуре — задача нетривиальная: нужны и компетенции, и ресурсы, и бюджет, который для многих компаний оказывается избыточным.
В какой‑то момент наша команда оказались в ситуации, когда нужно было обеспечить непрерывность сервисов для заказчиков в РФ, у которых уже был Zscaler. Это заставило нас пересобрать подход: выделить действительно критичный функционал и понять, как его можно реализовать альтернативным способом.
В этой статье разберу один из вариантов, к которому мы в итоге пришли. Сразу оговорюсь: полную замены Zscaler мы не делали — но закрыть значимую часть задач оказалось вполне реально.
В начале ноября 2025 года децентрализованный протокол Balancer V2 (composable stable pools) подвергся атаке, суммарные потери по разным сетям превысили 128 млн долларов. Причиной стала не ошибка доступа, не реентерабельность и не баг в проверках прав, а потеря точности при расчете инварианта из-за округления. Формально проблема сводилась к округлению при масштабировании значений и выглядела как допустимый технический компромисс. Экономический эффект, однако, оказался значительным.
Взлом Balancer, как и многие другие инциденты, уже подробно разобран в формате post-mortem — с реконструкцией того, как именно была проведена атака. В этой статье подход другой: мы посмотрим на тот же код глазами аудитора, который задается вопросом «что здесь может пойти не так?».
Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.
Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.
JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.
Продолжаем тему эпических багов. В прошлый раз мы говорили про AT&T, положивших свою ультранадежную сеть одним «Break» в коде. Сегодня на очереди Knight Capital Group, решивших переиспользовать старый флаг в бинарном протоколе, затем там был мёртвый код, который забыли удалить и деплой, проверенный на семи серверах из восьми. Итог: уход в минус 450 миллионов долларов за 45 минут.
На Хабре этот инцидент упоминался несколько раз, но даже в самой большой статье (к слову, переводу, со всеми странными атрибутами инопрессы, вроде фраз «Атака зомби из „Кода убийцы“» и пространным вступлением) инцидент рассматривался скорее как финансовый. А нас же больше интересуют именно технические детали.
В первой части был заложен фундамент: локаторы, «умные» ассерты и хелсчеки. Это критически важные вещи, но на масштабе в 100+ тестов неизбежно возникает «второй слой» проблем — сложность диагностики и изоляция данных.
Твой тимлид открывает Jira и смотрит на статистику: за две недели ты завел три дефекта. Три. Он спрашивает, чем ты занимался все это время. Ты начинаете объяснять про двадцать багов, исправленных через личку с разработчиками. Он кивает и говорит: «Понятно. Но в системе этого нет».
Через неделю тебя включают в список на сокращение. Это не страшилка. Это реальность для тестировщиков, которые считают, что быстрая личка эффективнее формального баг-трекера. В этой статье я расскажу, с какими рисками сталкиваются тестировщики ЛАНИТ и других ИТ-компаний, когда заменяют баг-трекер личными переписками, и как это защитит твою карьеру.
Рассуждаем на тему того, что AI-агенты радикально скукожили привычный нам цикл разработки.
ИИ-инфлюенсеры утверждают, что скрам больше не нужен, тестировщики не нужны, всё сделает агент. Реальность интереснее: этапы сжимаются по-разному в зависимости от контекста.
В greenfield — минимум контроля, observability вместо code review. В brownfield — AI генерирует, человек валидирует. А там где много регуляторки ускорение есть, но и ответственность никуда не делась.
