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

Привет, Хабр! Это продолжение серии про QA-собеседования.

Если при слове «контейнер» в голове только грузовые суда — эта статья для вас.

Привет! Я Стас, уже долгое время работаю в тестировании. В статье расскажу, почему я вдруг начал изучать ИИ, как далеко зашёл в этом процессе и как он связан с ростом в сторону SDET.

Ещё покажу способ быстро создавать API-заглушки для тестирования с пайплайном на бесплатном софте. После прочтения сможете собрать такой же для своего проекта.

Как перевести продакшен-проект на рельсы agent-driven development - когда LLM-агенты становятся полноценными участниками разработки, а не просто подсказчиками в автокомплите ? Реальный опыт на реальном проекте !

Продолжаем улучшать Feedback Loop. В предыдущей статье я ускорил прогон тестов в 6 раз. Теперь — следующий шаг: LLM-агент генерирует тесты. Два подхода (sprint-driven и coverage-driven), шестиуровневый pipeline верификации, двух-агентная архитектура, оптимизация feedback loop — и 68 тестовых файлов на выходе с acceptance rate 86.8% при ревью живыми разработчиками.

В статье — конкретика: как анализировал покрытие и свежесть документации, как ускорял компиляцию для агента, на чём экономил токены, и что сказала команда на code review.

Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.

В этой статье я хочу поделиться личным опытом эволюции UI-тестов в AQA-проекте. Речь пойдет о том, как из типичных простыней с assertEquals(), множественными прямыми вызовами методов страницы и деталями реализации можно прийти к более выразительному и читаемому подходу — внутреннему DSL поверх Page Object.

Всем привет! На связи Карпенко Савелий, специалист по тестированию на проникновение из группы по борьбе с уязвимостями в компании ТехВилл.

В рамках нашей работы мы регулярно тестируем Active Directory (AD). Это центральный сервис аутентификации и управления доступом во многих корпоративных сетях. С практической точки зрения ошибки в конфигурациях AD часто становятся главной причиной взлома, среди проблемных аспектов можно назвать неверное назначение прав, доступов и использование устаревших механизмов аутентификации. Наличие недостатков в конфигурациях даёт атакующему возможность последовательно поднимать уровень своих привилегий. Ниже собраны типовые ошибки конфигурации, которые чаще всего встречаются на проектах, и показано, как они складываются в цепочки компрометации.

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

Как устроен процесс собеседования QA-инженера в 2026 году? Из каких этапов он состоит и чем интересуются интервьюеры на каждом из них? В этом гайде я разложил всё по полочкам: что спрашивает HR (и как он оценивает ваши ответы), какие блоки теории нужно повторить manual-инженерам, а какие — automation-инженерам на Java, и как проходит секция с задачами на логику и лайвкодингом.

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

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

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

Как тестировать микросервисы, чтобы не было мучительно больно на проде? Разбираем пирамиду тестирования, интеграционные тесты с Testcontainers, контракты с Pact и нагрузочные испытания. Расскажу, какие практики реально работают в крупных проектах...

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

Дисклеймер: в статье нет технических деталей, так что матерые RTL-разработчики могут заскучать. А еще в ней нет лайфхаков, которые помогут за секунду определиться с карьерой и за три дня стать Илоном Маском. Зато есть реальный жизненный опыт.

Я написал этот текст для ребят, которые не определились с карьерой после вуза или уже твердо решили связаться с «аппараткой», но пока выбирают между разработкой и верификацией. Надеюсь, он поможет сориентироваться.

Последние полгода слежу за тем, как AI-агенты заходят в сферу тестирования. Делюсь честной картиной: что реально работает, где ещё болит, и как это меняет роль QA-инженера.

У автомобилистов есть пословица: «Если не знаешь, какой автомобиль купить – купи фольксваген». У ИБ специалистов тоже есть похожее: «Если не знаешь, как обеспечить безопасность облачной системы – поставь WAF (Web Application Firewall – фаерволл веб-приложений)». Который призван эффективно отсекать атаки злоумышленников на подступах к облачным приложениям и заранее распознавать потенциальные угрозы путем сигнатурного и поведенческого анализа входящего трафика.

Привет! Меня зовут Карина, я QA-инженер в hh.ru. Наша компания растёт, а вместе с ней — число команд, вовлечённых в разработку и функционал. Появляются новые сервисы, базы данных, очереди. Каждый компонент требует слаженной работы и надёжной поддержки на тестовых стендах.

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

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Поиск работы в IT часто выглядит похожим образом: десятки откликов, постоянные собеседования, новые команды, разные проекты и условия.

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

Собеседований много, информация начинает смешиваться. По итогу в голове остаётся только одно — предложенная зарплата.

В результате решение об оффере принимается почти вслепую.

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

За время регулярных выходов на рынок я выработал несколько простых практик, которые позволяют существенно снизить вероятность подобных сюрпризов.

Поделюсь основными из них, надеюсь, что всем будет полезно 👇

Пробуем написать своё приложение для удалённого рабочего стола.

Начал замечать, что на Хабре часто появляются статьи в духе «Я написал замену AnyDesk, бесплатный, но платный. И тут мне пришла мысль: а что, если попробовать самому? Хотя я не программист».

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

Хотелось бы менять часть кода «на лету», без перезапуска всего теста, прямо в редакторе Visual Studio Code. Чтобы синтаксис проверялся, tslinter‘ы всякие работали, автодополнение и прочий AI. Напечатал

await page.getByRole("search", {name : "Search"});

 Выделил строчку и запустил. Посмотрел на реакцию, поправил

 await page.getByRole("searchbox", {name : "Search"});

Запустил снова. И так много раз, если надо. Можно несколько команд сразу запускать, если хочется. Модули импортировать на лету. Чтобы scope запоминался, если выполнил

Привет, Хабр! Делюсь ниже статьей моего коллеги Игоря Резцова, ведущего системного инженера в К2 Кибербезопасность.

На связи Игорь Резцов. За 15 лет опыта в ИТ, из которых 8 лет в ИБ, я видел как требования к сетевой безопасности менялись и усложнялись. Одно можно сказать точно — NGFW давно стал базой. Согласно нашим данным, 88% российских корпораций активно используют его для защиты сетей. 

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

Привет, Хабр! Прошло 1,5 года с нашего первого разбора рынка оборудования для ЦОД. Тогда задачей было просто понять куда уходить с «циски» и дать заказчикам шорт-лист доступных производителей с ключевыми характеристиками железа. 

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

Все это легло в обновленный обзор рынка решений для ЦОД, который мы упаковали в формат быстрого гайда: сравнительных таблиц с характеристиками вендоров. Смотришь колонку — и понимаешь, подходит ли вендор под твои задачи. А для тех, кто устал от онлайна и готов встретиться и пообщаться с коллегами по цеху - оставил ссылку в конце статьи.