Всем привет! Меня зовут Дмитрий Неверов, я руковожу направлением анализа защищенности внутренней инфраструктуры в Бастионе. Сегодня представлю метод локального повышения привилегий на Windows 10.
Сам подход не новый и уже после его тестирования я обнаружил статью, в которой описывается нечто похожее, но с использованием C2 и стороннего хоста. В моем случае есть только один хост.
Дизайн-ревью —достаточно важная вещь, которая требует внимания, когда фронтенд-разработчик сверстал новую фичу, блок или целую страницу. Вовсе не для pixel perfect, который «как задизайнили, так и сверстали» — пиксель в пиксель. Pixel perfect в десктопе — это чушь, потому что нельзя сверстать так, чтобы с разных браузеров (привет, Safari) и разрешений всё смотрелось идеально. Но ошибки, которые сразу бросаются в глаза, сразу подмечаю, структурирую и обсуждаю это с разработчиком, может, появились какие-либо ограничения и прочее. Поэтому никогда не жалею время на дизайн-ревью и через DevTools сам проверяю то, что сверстал разработчик.
Все инструменты и функциональность, о которых пойдёт речь в этой статье, можно найти в браузере в «Инструментах разработчика» (клавиша F12 / Ctrl + Shift + I (на Windows) или ⌘ + ⌥ + I (на Mac), или клик правой кнопкой мыши в любом месте страницы -> Выбор пункта меню — «Просмотр кода страницы» (или «Исходный код страницы») — это и есть DevTools).
Основной элемент для работы с девтулзами — «Инспектор» (Ctrl + Shift +C на Windows и ⌥+⌘+I на MacOS) — это инструмент поиска элементов на странице браузера.
В мире, где скорость релизов и стабильность продукта становятся конкурентными преимуществами, последовательное тестирование превращается в узкое горлышко. Параллельное тестирование с использованием Selenium Grid предлагает решение: одновременное выполнение тестов на различных конфигурациях, что значительно сокращает время проверки без потери качества.
В этой статье подробно рассмотрим, как эффективно внедрить параллельное тестирование, избежать распространённых ошибок и интегрировать его в существующие процессы CI/CD. Будет особенно полезно начинающим тестировщикам.
Четыре года назад я упёрся в стену. Я работал QA инженером, изучал инструменты, автоматизацию, базы данных — но карьерного роста не было. Мне хотелось развиваться, двигаться в сторону тест-менеджмента, но одних технических навыков оказалось недостаточно. Тогда я впервые осознал, что не только харды определяют успех.
Soft skills стали тем, что помогло мне выйти на новый уровень. Я научился планировать, делегировать, вести переговоры, работать с командой. Всем привет! Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке и в этой статье я расскажу, какие soft skills действительно важны, как их развивать и почему без них сложно расти в IT.
По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.
Многие разработчики и начинающие тестировщики считают регрессионное тестирование рутинной и скучной работой. Максим Атлашкин, руководитель отдела регрессионного тестирования РСХБ-Интех, готов развеять этот миф.
Из интервью вы узнаете, как за 2,5 года пройти путь от джуна до лида регрессионного тестирования. Максим расскажет реальные истории о спасении релизов благодаря тестированию и поделится инсайдами о процессах тестирования в крупном банковском IT-проекте.
Максим, как ты пришёл в сферу тестирования?
Пришел в тестирование 20-м году из сопровождения первой линии другого банка, где во время процесса перехода на новую систему ДБО (другими словами клиент-банк) мой отдел начал изучать систему раньше пользователей и находил ошибки. Делали мы это исследовательским путем, ошибки записывали по шагам и передавали письмом (багтрекера для сопровождения не было) в отдел разработки. Мне этот процесс понравился, особенно когда была обратная связь и ошибки действительно исправляли, и нужно было сделать ретест. Тогда-то и начал интересоваться тестированием в целом, искал информацию в интернете по типу «Как тестировать», прошел несколько бесплатных курсов и решил, что нужно профессионально идти в тестирование, параллельно продолжая изучать эту сферу.
Что тебя вдохновило заняться именно регрессионным тестированием?
Цели идти именно в регрессионное не было. У меня не было опыта, и я не до конца понимал, как это работает на тот момент. Я оказался в РСХБ-Интех и изначально попал в команду регресса ДБО для юридических лиц. Только месяц-два изучил, как и что тут работает, как пришла пора «распиливать» монолит на микросервисы, появились продуктовые команды разработки, и колесо фортуны закинуло меня в одну из них, да еще и с очень критичным продуктом платежей и переводов. Там я на практике познакомился с большим количеством инструментов (Postman, Swagger, BrowserStack, DBeaver, Fiddler и др.). Впервые поработал в гибкой методологии agile, ранее был знаком только с waterfall-ом. Моему счастью не было предела. Шутка =)
Привет! Я Андрей Сташок, бэкенд-разработчик в KTS. В этой статье я расскажу о запуске параллельных тестов через pytest-xdist.
Почему это важно?
Объясню на нашем примере. При разработке продуктов мы постоянно выполняем юнит-тестирование. Раньше мы проверяли все последовательно, и с расширением тестовой базы время проведения испытаний заметно возрастало. Распараллеливание через pytest-xdist помогло нам сильно ускориться, и сегодня я хочу поделиться этим трюком с вами.
Я расскажу, как запускать параллельные тесты для реляционной БД PostgreSQL (с драйверами asyncpg и psycopg2) и key-value БД Redis. Для подключения к реляционной БД мы будем использовать SQLAlchemy, а для Redis — библиотеку redis. Кроме того, я рассмотрю, как автоматизировать выполнение миграций при каждом запуске тестов с использованием alembic.
Меня зовут Роман. Я SDET-специалист в компании SimbirSoft. В этой статье поделюсь своим опытом создания тестового фреймворка с нуля для одного из наших внутренних проектов. Материал будет полезен для начинающих или уже действующих специалистов в области тестирования, которые хотят больше узнать:
– о построении процесса автоматизации с самого начала;
– о сложностях, с которыми может столкнуться автоматизатор;
– об инструментах для подходящего решения поставленных перед ним задач.
Также рекомендую свою статью тем специалистам, которые уже обладают базовыми знаниями Python и Docker и стремятся углубить свои навыки в автоматизации тестирования.
Мир искусственного интеллекта не перестает удивлять прорывами, и 2025 год — яркое тому подтверждение. Нейросети становятся не просто мощнее, но и все доступнее, интегрируясь в огромное количество инструментов и сервисов, которые способны кардинально изменить подходы к работе в IT. Для специалистов самых разных направлений – будь то разработчики, тестировщики, бизнес-аналитики, менеджеры проектов или маркетологи – это открывает поистине невероятные возможности: от автоматизации рутинных задач и ускорения генерации креативных идей до глубокого анализа данных, создания прототипов и многого другого.
В этой статье собраны наиболее интересные и практически полезные нейросети, заслуживающие вашего пристального внимания в 2025 году. Это не просто очередной список, а подробный гайд: мы детально разберем каждую модель или инструмент, рассмотрим их ключевые функции, преимущества и потенциальные сценарии использования в вашей повседневной IT-деятельности.
Наша цель – помочь вам сориентироваться в этом быстрорастущем мире AI-решений и выбрать те, которые смогут принести реальную пользу именно вам. Пристегните ремни, мы погружаемся в мир передового ИИ, который уже сегодня меняет правила игры!
🔰 Этот список будет дорабатываться и дополняться самыми актуальными инструментами и описанием к ним. Так что ложите статью к себе в закладки. Все ваши пожелания и комментарии, по возможности, также будут учтены.
Для вашего удобства мы сгруппировали представленные модели и инструменты по основным категориям их применения: работа с текстом и мультимодальные задачи, генерация изображений и графики, создание видео и анимации, обработка аудио и голосовые технологии, генерация пользовательских потоков и прототипирование, создание интеллект-карт, быстрая визуализация идей, работа с презентациями, создание 3D-моделей и аватаров, а также другие специализированные AI-решения. Поехали!
Всем привет! Судя по ответам, которые мы получили от посетителей конференций Joker, Heisenbug и JPoint, примерно в половине компаний есть требования по набиванию тестового покрытия (обычно 60-70% кода должно быть покрыто тестами).
Однако, при личном общении с разработчиками и тестировщиками мы постоянно слышим, что никаких требований нет и покрытие никак не контролируется.
Кто отвечает за тестовое покрытие? Должны его набивать разработчики или эта задача ложится на плечи тестеров? Будем благодарны, если ответите на 1 (один) вопрос. Если хочется поговорить о наболевшем и рассказать, как у вас в проекте обстоят дела с тестовым покрытием, пишите в комментарии.
Всем хорошей пятницы и классных выходных!
Скачать последнюю версию Explyt Test плагина можно на сайте или напрямую с GitHub.
Для обратной связи и сообщений об ошибках: GitHub Issues
Для общения: t.me/explyttest
Для большинства разработчиков очевидно, что сначала должен появляться код, а только потом тесты для проверки работоспособности этого кода. Но в этой статье мы рассмотрим обратный процесс — Test Driven Development. В простом понимании это означает написание тестов перед написанием кода, но на самом деле этот подход гораздо шире. Тесты перед реализацией заставляют вас больше думать о том, что на самом деле ожидается, а «как» приходит позже, и «как» — это деталь реализации, которую можно изменить с помощью рефакторинга.
В этой статье, написанной на основе публикации Rogério Chaves «The complete guide for TDD with LLMs» мы рассмотрим использование больших языковых моделей (LLM) для Test Driven Development.
Когда автотесты начинают тянуться как улитка, страдают все. CI медлит, разработчики косо смотрят на отчёты, а я вместо багов натыкаюсь на тайминги. Особенно это бесит в UI‑тестах — там каждый шаг может тормозить, но с ходу это не видно.
В команде периодически всплывал один и тот же вопрос:
«Почему один и тот же сценарий утром идёт дольше, чем вечером?»
Захотелось простой утилиты.
Никаких интеграций, серверов и плясок с бубном. Так появился Slowpoke Finder — маленькая CLI‑утилита и библиотека для анализа логов автотестов. Кидаешь ему JSON или HAR — он вытаскивает шаги и показывает, какие из них реально тормозят.
Всем привет! Совсем недавно вернулась из Санкт-Петербурга, где посетила 36-ю международную конференцию по тестированию и качеству программного обеспечения SQA-days. Это уже 4я конференция на которой я побывала, но именно на этой я впервые была в качестве спикера. Хочу сегодня рассказать вам про свой опыт, о том как пришла к этому, как готовилась, с чем столкнулась и немного закадровых подробностей.
Будет полезно тем, кто еще не решился, но хочет в будущем выступить на конференции SQA-days или любой другой. Надеюсь, мне удастся вас вдохновить своим примером :) А также будет полезно тем, кому в принципе предстоит публичное выступление т.к в ходе статьи я буду делиться лайфхаками.
С каждым годом тестирование API становится всё важнее в разработке, особенно с ростом популярности Agile и DevOps. В отличие от тестирования UI, которое может быть медленным, API-тесты позволяют быстро проверять взаимодействие компонентов и получать обратную связь, что ускоряет весь процесс разработки. Эти тесты помогают не только повысить качество приложения, но и гарантируют его стабильность.
В этой статье мы расскажем о лучших open-source инструментах для тестирования API в 2025 году. Вы узнаете, какие из них подойдут для разных типов тестирования — от функционального до нагрузочного, и как выбрать подходящий инструмент для вашего проекта.
Как разработчики мы понимаем, что даже лучшие решения могут столкнуться с проблемами при увеличении нагрузки, поэтому важно заранее оценить их устойчивость и работоспособность. В этой статье я рассмотрю принципы нагрузочного тестирования в 1С, поделюсь методами построения обработок, а также покажу, как правильно запускать тесты, интерпретировать их результаты и фиксить ошибки.
Привет, Хабр! Меня зовут Дарья Бавыкина, я разработчик IBS. На производительности 1С могут сказаться и обновление платформы до последней версии, и внедрение новых функций, и внесение каких-либо, порой даже мельчайших, изменений в конфигурацию. Чтобы бизнес-заказчик не поседел от ужаса, когда его главная учетная система начнет зависать посреди рабочего дня, после любых «телодвижений» разработчиков важно проводить нагрузочное тестирование. Ниже — подробная инструкция как.
В 2006 году я захотел стать разработчиком. Учился, брал небольшие заказы, откликался на вакансии, проходил собеседования. В итоге на 10 лет застрял в эникее: ставил винду, настраивал сеть, чинил принтеры. Денег не хватало, ипотека давила, жена предлагала поехать на вахту. Но я продолжал вкатываться в IT и в итоге оказался в тестировании.
Привет! Меня зовут Виктор, я Senior QA в Outlines Tech. Если вы не можете найти себя в IT или у вас тупик в карьере — возможно, моя история покажет, что выход есть. Ниже нет инструкции, как быстро сменить профессию. Я просто расскажу, почему у меня не получилось с разработкой, как вкатился в тестирование через техподдержку и есть ли повод жалеть о потраченном времени.
В современной разработке программного обеспечения роли четко распределены: разработчики пишут код, системные аналитики формируют требования, а QA‑инженеры обеспечивают качество. Но что происходит, когда компания решает нарушить это равновесие и нанять опытных разработчиков без QA бэкграунда в отдел тестирования? Наш опыт показал, что это может привести к неожиданным результатам.
Привет, Хабр!
Ранее мы разбирались с основами Kafka (часть1), рассматривали, как тестировать микросервисы (часть2) и предугадывали ошибки offset explorer и kafka ui (часть 3). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером.
Преимущества брокеров
Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API?
Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров:
1. Асинхронное взаимодействие
API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает.
2. Масштабируемость
В случае с Kafka это значит, что можно гибко добавлять продюсеров и консьюмеров. Данные можно переиспользовать — допустим, создать один топик для нескольких консьюмеров. Либо, что очень важно в продакшене, например, если продюсер начал слать мусор — его можно просто отключить.
Первая статья цикла про работу AI-QA-инженера (но написана без использования AI)
Когда работаешь в IT уже почти 25 лет, то все обещаемые революционные изменения первое время воспринимаешь со значительным скепсисом. "Все - в мобайл, остальное умрёт" или "все - в крипту, в этом будущее" обычно заканчивается тем, что появляется очередное ответвление внутри IT, а старые направления никуда не деваются.
Принять участие в AI-лихорадке я заранее не планировала. Но за последние полгода без какой-либо инициативы со своей стороны мне пришлось поучаствовать в тестировании сразу нескольких коммерческих AI-проектов (не путать с использованием AI-инструментов для тестирования).
А каждый шестой QA-джун из наблюдаемых мной начал свою карьеру сразу в AI-компании.
Хочу поделиться своим, пусть пока небольшим, но прикладным опытом работы с AI и рассказать, как выглядит оно, тестирование AI-приложений. И, главное, кому действительно имеет смысл погружаться в тестирование AI, а для кого это может быть преждевременно.
Сегодня расскажу, как мне удалось перехватить управление миллионами смарт-весов, подключенных к интернету. Причина — уязвимость в механизме привязки весов к пользователю, превратившая эти устройства в идеальные мишени для атак.
Эта находка наглядно показывает, что аппаратная и веб-безопасность — две одинаково важные составляющие защиты умных устройств. Отыскав уязвимости в каждой из них, злоумышленник может достичь по-настоящему пугающих результатов.
