Инжиниринг качества (Quality Engineering) — это современный подход к созданию надёжных и востребованных продуктов, основанный на проактивных методах, автоматизации и анализе метрик. Он помогает компаниям предотвращать ошибки на ранних этапах и обеспечивать высокий уровень качества на всём жизненном цикле разработки.
Сейчас TMS на рынке условно можно разделить на два подхода.
Первый — классический. Система работает как слой управления ручным тестированием: хранит тест-кейсы, формирует прогоны, фиксирует статусы и результаты. Вся логика выполнения при этом остается за пределами TMS.
Второй — с поддержкой автотестов. Здесь появляются интеграции с CI: система умеет связывать автотесты с тест-кейсами, подтягивать результаты запусков, отображать историю и статусы. Иногда добавляется возможность инициировать запуск, но фактическое выполнение и управление пайплайнами по-прежнему остаются в CI.
В новом релизе DoQA 4.0 как раз добавили сценарий с запуском автотестов прямо внутри TMS. Давайте разберем, как это ребята реализовали.
Playwright 1.59 — не очередное инкрементальное обновление. Это заявка на то, куда движется автоматизация тестирования, и это направление глубоко агентное. Если вы ждали, когда инструменты догонят AI-driven воркфлоу, о которых все говорят, этот релиз закрывает разрыв.
Разберём каждую крупную фичу и, что важнее, как каждую из них можно применить немедленно.
Долгое время своей уютной компанией сидели на телеграме. Клиенты, заказчики, лёгкие боты для уведомлений, беседы отделов и прочие прелести всем известного мессенджера. В этой статье поделюсь недостатками, которые мешают нормальному переходу тысяч людей на отечественный MAX (по крайней мере в качестве рабочего мессенджера).
Важная оговорка. Я работаю в малом бизнесе. Тратить лишние несколько тысяч рублей на битрикс или другие аналоги можно, но не хочется. К тому же телеграм закрывал все возникающие вопросы и проблемы. Если уж тысячи людей оставили без выбора, отечественный аналог может просто скопировать функционал телеграма, проверенный годами работы. К сожалению, МАХ является лишь копией ICQ NEW (в последствии VK Teams), застрявших в 2016 году. Некое понятие о работе кода я имею, но программистом не являюсь. Поэтому ниже пойдёт чистый "пользовательский" опыт.
И введём термина Б50 - бухгалтер пятидесяти лет. Вообразите себе обычную трудягу, которой поставили приложение МАХ. Она им пользуется каждый день, не разбирается ни в коде, ни в костылях, ни в банальных вещах по типу "перенесите иконку на панель задач". Под этот термин попадают и узкопрофильные специалисты - в трафаретной печати или деколи они просто асы. Но когда дело доходит до компухтеров - они предпочитают позвать сисадмина или любого молодого человека, по возрасту своему умеющего разбираться с технологиями.
Привет, Хабр!
На связи Олег Уланов (aka brain), багхантер и ведущий подкаста «Начинаем в багбаунти». Кстати, по итогам 2025 года стал топ-1 площадки Standoff Bug Bounty.
Этот материал мы подготовили вместе с Дмитрием Прохоровым, пентестером из PT SWARM (в мире багхантинга Дима известен как ratel_xx).
В статье речь пойдёт о поиске уязвимостей через загрузку файлов. Вы узнаете, как устроен механизм multipart/form-data, какие защитные механизмы ставят разработчики и как их обходить. Я покажу на практике, что можно сделать с расширениями файлов, Content-Type, magic bytes, а заодно затрону эксплойты типа race condition, zip-слайп и нестандартные векторы вроде загрузки .htaccess. Статья подойдёт для начинающих багхантеров, поэтому даже если у вас мало опыта смело заглядывайте под кат!
В мире микросервисов и сложной продуктовой логики наступает момент, когда классические E2E-тесты превращаются в проблему. Количество пользовательских сценариев исчисляется сотнями, каждый новый конфиг требует десятков тестов, а регресс вместо быстрой проверки становится многочасовым процессом.
Но если сценарий становится нелинейным (появляются развилки, выбор пользователя ведёт на разные экраны) всё усложняется. С этим E2E-тесты ещё справляются: пишем несколько тестов, каждый под свой путь. Сложнее, но решаемо.
Мы столкнулись с этим при работе с платформой в Услугах Авито: пользователь заполняет форму заявки, переходя между экранами. Логика переходов между экранами зависела от категории услуги, типа экрана и выбранных опций. Сценариев стало попросту слишком много. Пришлось искать другой путь.
Меня зовут Константин Горностаев, QA в Авито, в этой статье я расскажу о подходе, который позволил нам решить эту задачу и получил название «система фейков».
Смена технологической области кажется рискованным шагом: новые термины, другая инженерная культура и ощущение, что придется начинать почти заново. Но на практике переход может оказаться гораздо более плавным.
Меня зовут Любовь Молчева, я руководитель группы unit-верификации дивизиона разработки полупроводниковых продуктов YADRO. До этого вся моя карьера была связана с программной разработкой и тестированием. Перейдя в верификацию полупроводников, я обнаружила, что многие управленческие и инженерные навыки остаются нужными, а требования новой роли во многом совпадают с уже накопленным опытом. В этой статье разберу, какие навыки из software оказываются полезны в hardware, с какими сложностями сталкиваешься в первые месяцы и как выстроить погружение в новую область без ощущения, что начинаешь карьеру с нуля.
Разбираю как выглядит нормальный QA-пайплайн в GitHub Actions: от линтинга до E2E тестов на Playwright. С рабочими конфигами, кэшированием и уведомлениями о падениях.
Мы привыкли винить LLM‑агентов в галлюцинациях, бесконечных циклах и слитых бюджетах на API. Но что, если проблема в инфраструктуре, которую мы им скармливаем? Я написал детерминированный CI‑сканер для оценки качества MCP‑серверов и прогнал через него 30 публичных пакетов. Результат оказался интересным: почти половина серверов убивает агента ещё до старта, а официальные инструменты дают ИИ гранату в руки. Под катом - хардкорный разбор костылей экосистемы, графики и Open Source инструмент, который защитит ваш продакшен.
Как тестировать систему, если половина её компонентов — это «чёрные ящики» с уникальными протоколами, а стандартные API-mocks не справляются? С точки зрения готовых решений — тупик…
Меня зовут Дмитрий, я AQA-инженер в ИнфоТеКС. Мы с командой столкнулись с этой проблемой и создали собственные API-mocks, которые не просто отвечают шаблонными сообщениями, а ведут себя как настоящие компоненты системы. В этой статье — наш путь от идеи до работающего решения, которое можно адаптировать под ваши задачи.
Привет, Habr.
Обычно найм представляют довольно просто: есть вакансия, есть кандидат, есть несколько этапов собеседования, после которых человек либо получает оффер, либо отказ. Такая картина хорошо смотрится в HR-отчётах и презентациях, но в реальности всё устроено заметно сложнее.
Если чуть дольше повариться в рынке, становится видно, что вокруг собеседований уже давно существует отдельная инфраструктура. Речь про слитые вопросы, базы по компаниям, закрытые чаты, документы и каналы, где собирают и передают друг другу реальные этапы найма. Причём это уже давно не история про редкие “утечки” или единичные случаи. Для части рынка это вполне рабочий инструмент подготовки.
Сразу уточню важный момент. Эта статья не про мораль, не про публичные разоблачения и не про попытку назначить кого-то злодеем.
Мне интереснее разобрать само явление: почему рынок слитых собеседований вообще появился, как он работает и почему стандартные процессы найма сами неплохо помогают ему жить.
Потому что проблема тут не только в кандидатах, которые хотят пройти собес по короткому пути. Проблема ещё и в том, что многие компании годами проводят одни и те же интервью почти в одном и том же виде, а значит рано или поздно этот процесс начинает жить своей отдельной жизнью.
Как правило, разработчики, да и тестировщики не всегда могут заранее предусмотреть, какие именно некорректные входные данные придут в их веб-приложение. Привычные методы тестирования — ручные, интеграционные и даже unit-тесты — хорошо справляются с ожидаемыми сценариями. А вот для проверки непредсказуемых нужны другие подходы.
Привет, Хабр! Меня зовут Алексей Ломай, я младший системный инженер отдела DevOps в IBS. В этой статье расскажу о фаззинге как о мощном инструменте тестирования безопасности веб-приложений. Поговорим об истории и развитии подхода, о доступных инструментах и двух вариантах реализации в CI/CD.
Самый дорогой регрессионный набор не тот, который долго выполняется, а тот, которому команда перестала верить. Когда команда внедряет автоматизацию, она быстро приходит к соблазнительной идее: если автотесты ускоряют проверки и исключают человеческий фактор, значит автоматизировать нужно всё, до чего можно дотянуться. Но здесь и начинается ошибка. Автоматизировать всё, что можно, и автоматизировать то, что действительно нужно, не одно и то же.
Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.
В этой статье разберём логику приоритизации: что автоматизировать в первую очередь, что не стоит тащить в обязательный регресс совсем, и как выбрать уровень проверки. Если вам ближе автоматизация с расчётом на пользу и стоимость, а не всё подряд, сначала стоит разобраться, почему автоматизация без стратегии почти неизбежно превращается в набор дорогостоящих и малополезных проверок. Этот материал будет полезен тестировщикам, разработчикам, менеджерам и всем, кто связан или только знакомится с автоматизацией тестирования.
Привет! Это снова Михаил Федоров. В предыдущей статье я рассказал об архитектуре QA Assist — системе из 11 AI-агентов, которая берёт на себя 80% рутины QA-инженера. Среди метрик была строчка: «Подключение тестирования на новый проект — ~4 часа настройки, первые баги уже в бэклоге».
Красиво, правда? Прямо слайд для презентации. Давайте проверим эту цифру на реальном проекте — и посмотрим, насколько я был честен с вами (спойлер: не совсем).
Привет, Хабр! Я Полина Ященко, старший инженер по разработке ПО в YADRO. Мы с командой тестируем гипотезы и активно применяем искусственный интеллект, чтобы усовершенствовать процессы разработки. Так, недавно мы зарелизили AI-ревьюера — бота-помощника, который помогает искать проблемы в стиле и логике кода.
Мы разработали бота, чтобы упростить процесс ревью пулл-реквестов. В команде есть стажеры, которые совершают базовые ошибки, включая открытие очень больших PR, и иногда просто не хватало сил, чтобы вовремя их смотреть. Как мы выбирали модель и разрабатывали серверную часть, расскажу под катом. Отмечу, что наш бот не отличается высокой производительностью, зато отлично решает свою задачу — помогает инженерам находить и исправлять повторяющиеся ошибки.
Мы разобрались с асинхронщиной, идемпотентностью и моками. Код выглядит хорошо. Тесты проходят. Но когда проект вырастает до тысячи тестов, начинают падать вещи которые падать не должны, и причина почти никогда не в логике теста.
Причина в архитектурных минах которые заложили месяц назад и забыли. В этой части разберём самые частые из них и настроим ESLint чтобы робот ловил их вместо лида на ревью.
Примеры кода намеренно упрощены для наглядности. Фокус на идее, не на архитектуре.
Когда код уже написан, половина багов уже не исправить. Парадокс? Нет — статическое тестирование. В этой статье разбираю, как находить дефекты ещё на этапе требований, почему «большой взрыв» интеграции — это путь в никуда, и зачем знать про заглушки, драйверы и уровни от компонентного до UAT.
Наш тестовый фреймворк перестал масштабироваться с ростом сервисов. Мы переработали архитектуру, ввели разделение на слои, упростили масштабирование автотестов и подготовили фреймворк к интеграции SDK и использованию AI
Когда мне пришла идея написать эту статью, я предполагала, что это будет хроника ошибок, от которых мы бы хотели предостеречь техническое сообщество: как мы наивно полагались на «синтетику», а «видовое многообразие» сервисов раскрыло нам глаза.
Но по мере подготовки материала пришло осознание, что проблема не в том, что мы ошиблись в методике, а в том, что для core-системы, пропускающей сотни тысяч разнородных запросов в секунду, достичь точного воспроизведения боевой нагрузки практически невозможно.
Под катом рассказ о том, как мы двигались от упрощенных моделей к глубокому изучению специфики поведения системы, а по пути осознали, что нужно не выбирать между крайностями, а комбинировать подходы и учитывать риски.
Playwright — фреймворк от Microsoft для E2E-тестирования — был построен с нуля, чтобы решить именно эту проблемкую. В нем есть автоматические ожидания, изоляция через Browser Contexts и встроенный тест-раннер. Разберём, чем он отличается от Selenium и Cypress, и как писать тесты, которые не падают от ветра.
