Привет! Я Павел Лобач из команды инфраструктуры тестирования Т-Банка. Расскажу, как у нас организована инфраструктура для запуска E2E браузерных тестов, как она развивалась и как в итоге вылилась в открытый проект Selebrow.
Будет много технических подробностей и ни слова про ИИ!
Кажется, ИИ в составе CRM считается привычным. Чат-боты, скоринг, предиктивная аналитика, прогнозирование полей - повсеместно заявленные возможности ИИ впечатляют, что увеличивает интерес компаний к рассмотрению соответствующих решений, но на практике большинство из них лишь прототипы.
Почему в бизнесе интеллектуальные системы редко используются в полную меру и как в этой плоскости развивается BPMSoft, расскажем в этой статье.
Перспективы
По нашим данным, объём рынка искусственного интеллекта в корпоративном ПО к концу 2025 года достигнет 1 трлн рублей, а главным драйвером роста всё же выступит спрос на интеллектуальные CRM.
Компаниям просто необходимо осваивать современные решения и внедрять инструменты для прогнозирования продаж, анализа клиентского поведения и автоматизации сервисных функций. Особенно востребованы чат-боты для первой линии поддержки: в ритейле ими пользуются 42% компаний, в медицинских организациях — 38%, в банковском секторе — 27%.
Прототипы vs Интеллектуальные CRM
Сегодня базовую модель машинного обучения может собрать даже небольшая команда: открытые фреймворки вроде TensorFlow и Scikit-learn, облачные ML-платформы и готовые библиотеки снижают порог входа. Поэтому рынок быстро наполнился CRM с «ИИ-ярлыками» — чат-ботами на базе LLM, классификаторами обращений, базовыми инструментами прогнозирования оттока.
Такие решения охотно поддерживаются малым бизнесом, который активно растёт, но в какой-то момент перестаёт чувствовать клиента. Это возможность задуматься о ИТ-решениях сейчас и на перспективу, сэкономить деньги и время, вернуть контроль над продажами и предотвратить хаос. При этом базовой функциональности вполне хватает для решения типовых задач.
Привет! Я Женя, работаю QA-инженером. У нас в компании случился классический сюжет: с ростом команды появились проблемы из-за отсутствия системы управления тестированием. Решили внедрять, но какую выбрать? Устроили мини-исследование. Где-то радовал функционал, но пугали возможная блокировка или цена. Где-то нужно было пройти квест по настройке под себя. Были и неожиданно приятные находки. Что в итоге оказалось под капотом у пяти TMS из нашего топ-листа — в моей статье.
Привет! Я Ева, тестировщик в KTS.
В этой статье я хочу рассказать про Requestly — мощный инструмент, позволяющий перехватывать и модифицировать HTTP-запросы и ответы без участия разработчиков. Он особенно полезен при тестировании нестандартных сценариев, симуляции ошибок и быстром создании нужных тестовых данных.
Во многих разделах Requestly есть обучающие видео про работу с этим инструментом, однако они не всегда подробно покрывают все его возможности. К тому же, на русском языке материалов о нем довольно мало. Я решила собрать весь свой опыт работы с Requestly в один объемный туториал — от начала работы до конкретных юз-кейсов.
В условиях экспоненциального роста сложности ИТ-инфраструктур и постоянно эволюционирующих киберугроз, тестирование перестает быть опциональной процедурой и становится критической необходимостью. Недооценка его роли, к сожалению, до сих пор приводит к катастрофическим последствиям, которые измеряются не только финансовыми убытками, но и компрометацией всей системы безопасности.
В этой статье мы разберем как можно быстро и удобно конвертировать mind map в чек листы с дальнейшим импортом в Testops и Testrail.
Цель - сэкономить время на рутинных операциях с тестовой документацией.
Привет, Хабр!
Я, как, надеюсь, и вы тоже, очень люблю читать про всякие уязвимости. Это похоже на чтение детективов, где разными окольными путями, используя какое-нибудь нелепое стечение обстоятельств и тупые стандарты, навроде исполнения кода при десериализации или внешних запросов при открытии xml, атакующий приходит к цели и уничтожает весь мир. Ну что-то такое.
Я и сам писал пару статей такого рода и, честно говоря, очень ими горжусь, потому что уязвимости там действительно прикольные, и для их нахождения мне пришлось сильно пошевелить мозгами.
Но сегодня статья будет супер банальная, кому-то может быть даже покажется скучной. Никакого хитрого сюжета, абсолютно банальнейшая уязвимость в наиболее обыденной ситуации. Но мне кажется, что кто-нибудь может найти мой ход мысли полезным, может быть даже чему-то научиться - ведь я решил расписать всё максимально подробно. Поэтому вот вам статья про самую скучную уязвимость на свете, а вы напишите, что об этом думаете.
В интернете большое количество статей о сдаче экзамена ISTQB онлайн и достаточно подробно описана сама процедура - как подготовить рабочее место, поставить нужные плагины в Chrome, как следует и не следует общаться с проктором и так далее. В этой статье я хочу поделиться опытом сдачи экзамена on-site, то есть с выездом в конкретную локацию, а не дома.
Этот инструмент экономил сотни тысяч долларов и без него нельзя было выпустить релиз — но на бумаге оставался “пет-проектом” одного инженера. Почему компании раз за разом убивают такие инициативы — и как этого избежать.
Всем привет! Меня зовут Андрей, я инженер по автоматизации тестирования в команде Озон Банка, занимающейся разработкой и поддержанием инструментов тестирования, которыми пользуется весь банк.
Сегодня я хотел бы поделиться опытом сбора технических метрик pytest и их анализа в целях выявления узких мест и ускорения выполнения тестов.
💥 «Слепые не видят преград — только дедлайны»
Сложности в трудоустройстве есть у некоторых всех. Вы знали, что люди с инвалидностью и без отзываются об этом одинаковыми словами? Одни говорят «Трудоустройте меня, потому что "Я слепой, мне и так трудно”», а другие «У меня же ипотека, войдите в моё положение» или «Я работаю в айти уже 30 лет, у меня гигантский опыт, а эйчары даже не отвечают. Рынок найма сломался!»
Больно? Ещё как! Но если мы будем просто жалеть себя и в панике наматывать круги в чатах по поиску работы, никакого толкового КПД не родим. В этой статье я поделюсь своим личным опытом и опытом других людей со слепотой о том, как найти и реализовать себя, будь то работа, блогерство или проекты в искусстве.
И этот опыт как никогда пригодится тебе, мой нормотипичный друг.
Мнение пользователей о продукте — основное мерило качества работы всей команды. В каждом спринте мы делаем все возможное, чтобы подготовить стабилизированный и соответствующий ожиданиям пользователей релиз. Хотя баги — часть нашей профессии, неприятно узнавать о том, что какие‑то из них проскользнули в продакшн.
Мы регулярно проводим работу над ошибками, благодаря чему стали использовать кросс‑ревью: практику, которая раз за разом помогает нам расширять список проверок и грамотно их структурировать, позволяя получать при тестировании больший профит при меньших трудозатратах. Меня зовут Михаил Михайлов, я руковожу отделом тестирования Polymatica BI, и в сегодняшней статье расскажу, как сейчас устроен этот процесс в нашей команде.
Мультимодальные модели блестяще «понимают» сцены, но промахиваются там, где тестировщику важно точное соответствие: в сравнении двух версий одного экрана. Случайный сдвиг на несколько пикселей ломает пиксельные diff’ы и маскирует реальные проблемы — вроде исчезнувшей кнопки. Разбираем, почему так происходит, как компенсировать искажения многоуровневым сопоставлением и как простая CNN по окнам 9×9 помогает выявлять именно релевантные отличия.
И снова здравствуйте, коллеги!
Продолжаем испытывать на прочность российское железо. В прошлый раз мы строили фабрику на коммутаторах Eltex. Поняли на практике, как ее правильно собирать и настраивать.
Так вот, эта фабрика до сих пор работает и радует моё инженерное сердце!
Но, как любая игрушка, через неделю она становится просто чем-то, что у тебя есть, а тебе хочется чего-то нового. И тут я вспомнил, как в детстве, вдоволь напускавшись бумажных самолетиков с друзьями, мы придумали сделать что-то ЯРКОЕ. И решили, что горящие самолетики – это круто! Было здорово.
Знаю, о чем вы могли подумать. Нет, мы не будем поджигать нашу фабрику. 😊 Но устроим что-то жаркое… Нагрузочное тестирование! Зальем порты доступа гигабайтами трафика.
Привет, Хабр! На связи Иван Глинкин, специалист по аппаратному реверс-инжинирингу из команды Бастиона. Сегодня поделюсь интересным кейсом разбора платежного POS-терминала. Когда-то эти маленькие черные коробочки были крепким орешком для хакеров. Однако отвертка, паяльный фен, логический анализатор и, конечно же, пытливый ум исследователя творят чудеса. К тому же сами разработчики и даже регуляторы порой дают в руки исследователям все козыри, будто только и ждут успешного взлома устройств.
Эта статья — не просто очередной «сказ про то, как железку взломали», а попытка вывести универсальную методологию аппаратного реверс-инжиниринга на основе исследования конкретного устройства. Мы пошагово пройдем весь путь: от сбора информации в открытых источниках до физического вскрытия, обхода защиты и перехвата «секретных переговоров» между чипами.
Итак, часть первая: вскрытие и разведка боем. Поехали!
AI генерирует тесты, но 95% из них не работают — галлюцинирует классы,
путает поля, использует несуществующие API. Знакомо? Мы в отделе RAPID прошли через
это на проекте с биржевым протоколом TWIME. Делимся итеративным подходом:
как за 3 шага превратить хаос из 307 тестов в 109 работающих.
С конкретными промптами, метриками и выводами.
Привет! Я работаю в компании «ЛАНИТ Экспертиза» тест‑лидом на проектах по внедрению систем электронного документооборота и хочу поделиться практическими наработками в области формирования тестовой модели с использованием средств визуализации. В профессиональной деятельности часто встречаются ситуации, когда необходимо быстро погрузиться в систему или часть функционала и приступить к тестированию. Однако сделать это может быть невозможно по ряду таких причин, как фрагментированное описание, высокая сложность и многомерность процессов, отсутствие коммуникации с экспертами по системе. В этом случае одним из способов решения задачи быстрого погружения и старта может стать формализация процессов системы в графический вид или их комбинации, удобные для актуализации, использования и масштабирования количества участников процесса тестирования.
Ну и что делать, если в вашей компании — несколько тысяч программистов, сотни команд и десятки стримов? И вам нужно… Нет, не нужно — жизненно необходимо, чтобы они все работали как единый, отлаженный, настроенный механизм.
Разработка в Газпромбанке — это процесс, в котором задействовано более 3500 инженеров, пять департаментов, 59 стримов и 200+ кросс-функциональных команд.
При этом был период, когда наши команды создавали ПО разрозненно, стандарта разработки не было, практики и технологии у всех свои. Велосипеды, как в анекдоте, были у всех, но ездили по-разному. Билды проходили тесты, которые не должны были пройти, и возвращались «на доработку» едва ли не перед запланированным релизом. Что же делать, как же быть?
Да. Нужен стандарт. И нужны автоматизированные средства поддержки стандарта.
Нам не подошли ни одни из существующих Quality Gates — мы сформировали собственный набор практик проверки качества продукта (билда, сборки — всего того, чему требуется многоуровневое тестирование). Теперь у нас выросшая в семь раз частота деплоев и шикарные фильтры, построенные на тестах.
Почему мы не купили готовое решение? Что сделали? Как? Расскажем.
Привет, Хабр! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.
Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.
Ручное тестирование нового ПО АТМ трудозатратно, требует много времени и ресурсов. Зачастую действия повторяются и QA выполняет одни и те же тест-кейсы. Нашей целью было высвободить ресурс QA, уйдя от рутинного ручного тестирования к более творческим задачам путем роботизации ручного тестирования.
Эта статья поможет начинающим автоматизаторам раз и навсегда разобраться с принципами объектно-ориентированного программирования. Мы разберем инкапсуляцию, наследование, полиморфизм и абстракцию на практических примерах из жизни и кода.
