Тестирование 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, а для кого это может быть преждевременно.

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

Эта находка наглядно показывает, что аппаратная и веб-безопасность — две одинаково важные составляющие защиты умных устройств. Отыскав уязвимости в каждой из них, злоумышленник может достичь по-настоящему пугающих результатов.

23 апреля на OMNI Infrastructure Meetup эксперты из Авито, Магнит OMNI, Лаборатории Касперского и Cloud.ru обсудили, как создавать системы, устойчивые к любым сбоям. Рассказываем о самых важных инсайтах.

В московском офисе Магнита и онлайн собрались DevOps-инженеры, платформенные специалисты и разработчики, чтобы разобрать реальные кейсы повышения отказоустойчивости. Гибридный формат позволил присоединиться участникам из разных городов — дискуссия получилась по-настоящему живой.

Делимся видео и презентациями докладов.

«Могу ли я выполнять 10, 100 или 1000 экземпляров процессов в секунду на этом кластере Camunda 8?»

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

Сегодня мы бросаем вызов самой защищённой модели — Claude. Несмотря на свою репутацию как одной из самых продвинутых и защищённых моделей, он не абсолютно неуязвим. В прошлой статье я показал метод внедрения системных директив, который работает почти на всех моделях — но не на Claude. Сегодня покажу как модифицировать этот подход, чтобы успешно пройти его фильтры и заставить модель следовать нашим указаниям. И в подтверждении выполним откровенно «красный» запрос.

Привет! Меня зовут Ольга и я QA-специалист SimbirSoft. На данный момент моя специализация сопрягается с тестированием платформы «1С».

Идея статьи появилась, когда ко мне обратился коллега с вопросом: что такое интеграционное тестирование «1С». Готовясь ко встрече с ним, я поняла, что это очень важный этап в работе с программой для QA-специалиста. Статья поможет на этапе изучения интеграционного тестирования платформы понять, что нужно учесть при планировании тестирования, подсветить возможные узкие места и предотвратить появление критичных багов. Расширить знания QA-специалиста в платформе «1С» в целом и возможности ее интеграции в частности.

Также статья будет полезна для SDET специалистов, тимлидов или PO проектов, где присутствует эта платформа.

Привет! Я Рома Авдонин, Head of QA в KTS.

На Хабре уже выходили посты о том, как тяжело найти работу QA в 2024–2025 годах, но мало кто взвешивает сразу две позиции — и кандидата, и нанимателя. Я побывал по обе стороны и решил поделиться наблюдениями.

Пару слов обо мне: за последние полгода я провел больше сотни собеседований, а ранее сам активно проходил их как соискатель. Совсем недавно я полностью перестроил процесс найма тестировщиков в нашей компании (если будет интересно, пишите в комментах, расскажу об этом отдельно) и теперь хочу поговорить о том, что изменилось на рынке QA, почему собеседования стали такими сложными, как к ним адаптируются компании и что с этим делать соискателям и нанимателям, чтобы не свихнуться.

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30-70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.

Хабр, привет! На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies каждый месяц исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это такие уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.

С прошлого дайджеста мы добавили еще 4 трендовых уязвимости.

В марте маленькая платка внезапно оказалась в центре глобального технологического скандала. Заголовки пестрили страшилками про «бэкдор» в «миллиардах устройств», и по новостям казалось, что хакеры вот-вот захватят все умные лампочки, термостаты и прочий IoT.

А потом... все как-то поутихло. Что же на самом деле нашли испанские исследователи в популярном микроконтроллере? Почему новость о «бэкдоре» разлетелась со скоростью лесного пожара? И главное — насколько реальна была угроза?

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