Если в случае классических приложений нефункциональное тестирование часто переносят в разряд “было бы неплохо” и оставляют на потом, то при тестировании AI-приложений так уже не получится.
В подразделении, где я работаю, есть традиция - новичку при онбординге вручается ссылка на Wiki с легендарными багами, приведшими к заметным последствиям. Недавно мне пришла в голову идея сделать такую же страницу, но уже со ссылками на Хабр, потому что на русском о багах пишут с бОльшим огоньком. Но, увы, оказалось, что каскадному падению серверов AT&T 15 января 1990 года внимание как-то не уделено. А ведь история получилась, прямо-таки эпическая.
Итак, 15 января 1990 года из-за одной строчки кода телефонная сеть AT&T получила 9 часов даунтайма, 70 миллионов несовершенных звонков, а общий убыток насчитали в $60 миллионов еще не инфляционных долларов. И нет, там не было неудачного релиза, развернутого сразу и везде. Все было гораздо интереснее.
Привет, Хабр! Это продолжение серии про 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 запоминался, если выполнил
