Привет, Хабр. Пишу, потому что на текущем проекте прямо сейчас живу эту боль: всем включили Cursor «для скорости», а нормальных автотестов так и не завезли. Может, кто-то уже описывал этот кейс, но я не нашёл — поэтому делюсь своей ситуацией и тем, как это надо было делать с самого начала.
Привет, Хабр! Меня зовут Иван Дюков. Последние несколько лет я занимался разработкой и оптимизацией сетевых компонентов для облачной инфраструктуры. Среди моих проектов — участие в разработке сетевого процессора для компании Google в составе российского подразделения Intel, а также оптимизация программных сетевых функций для облака Samsung в команде Samsung R&D Institute Russia. В настоящее время работаю над сетевыми сервисами для платформы Cloud.ru Evolution в R&D-команде Cloud.ru.
Основное направление моей работы — это исследования программных сетей, сетевых сервисов и их производительности. В этой статье хочу рассказать, как я искал точку отказа прокси-балансировщика. Расскажу и про метрики, и про инструменты, и как я автоматизировал измерения. Путь оказался весьма извилист, наполнен граблями и шишками, зато результат был познавательными. Статья будет интересна разработчикам сетевых сервисов, DevOps-инженерам и тестировщикам, исследующим проблемы производительности сети и сетевых сервисов.
Всем привет!
Меня зовут Владимир. Я работаю в одной из крупных IT-компаний занимающейся разработкой цифровых продуктов предназначенных для кибербезопасности. Моя роль на проекте - готовить стенды для тестирования десктопных продуктов, проведение ручного тестирования и запуск автотестов.
При неправильном удалении снапшотов (удаление не по порядку слева-направо), так же возможно после аварийного завершения работы ОС, при следующем включении машины с контроллером домена (Windows Server 2022) появился синий экран - Stop Code 0xc00002e2. Никакие бэкапы, откаты снапшотов не помогают. На просторах интернета решение проблемы найти было трудно.
Например, в управлении транспортом статичные данные (например, сет за «типичный вторник») не дают протестировать систему в условиях праздника, крупной аварии, сессии у студентов, скидки 99% на Лабубу в крупном супермаркете и так далее.
Что мы сделали:
• Стали брать реальные данные с прода, которые выбиваются за стандартные представления.
• Обезличивать их.
• Использовать ML-модель для генерации сценариев, где эти данные увязываются с остальными в системе. Это типа генерации новых данных с усилением трендов и их пересечением.
То есть фактически по модели швейцарского сыра — мы имеем один статичный срез, а затем начинаем ходить в прод и искать новые дырки. Потом соединяем несколько дырок в новом слое и накладываем слои друг на друга, чтобы посмотреть, не будет ли сквозного отверстия.
Цель — не просто нагрузить систему, а протестировать жизнеспособность архитектуры в похожих на реальные условиях.
Очень упрощая, наши наборы тестов учатся нестандартным ситуациям с прода и включают их и в тестовые выборки данных, и в юнит-тесты, и такие ситуации не только покрываются как частные случаи, но и включаются в сложные сценарии, где 3 малозначимых отказа могут привести к аварии.
Я думаю, что это будущее тестирования сложных систем, и мы с командой уже затащили это в автоматический пайплайн.
Привет! Меня зовут Владислав Миронов. Я отвечаю за внедрение LLM в процессы QA Яндекса и в этой статье расскажу, каких результатов мы достигли — от генерации тест‑кейсов и автотестов до помощи в ручном тестировании. Поделюсь не только успехами, но и тем, какие компромиссы и организационные решения понадобились, чтобы всё это заработало.
В статье покажу, как мы разрешаем противоречия между командами, уходим от «зоопарка» инструментов и строим централизованную экосистему, где качество остаётся под контролем: реальные схемы, примеры и цифры, без магии и маркетинга.
Спойлер: рассчитывать можно на многое, но и вложиться придётся основательно. Парой промптов тут, к сожалению, не обойтись.
Наша компания Octomind занимается созданием ИИ-агентов, но её кодовая база по-прежнему в основном пишется людьми. Мы любим LLM и используем их везде, где можем, от нашего продукта до внутренних рабочих процессов. Но, несмотря на весь хайп, ситуация далека от того, чтобы агенты писали большую часть нашего кода.
У нас есть веские причины на то, чтобы пока не присоединяться к таким компаниям, как Anthropic (генерируется 80%), Microsoft (30%) и Google (25%).
Пока нам недостаёт в них некоторых жизненно важных элементов. В статье мы расскажем, почему это важно, и что нужно, чтобы закрыть эту нехватку.
Локаторы являются одним из ключевых элементов UI‑автоматизации. От того, насколько устойчиво тест находит нужный элемент, зависит стабильность всего тестового набора. Несмотря на кажущуюся простоту, выбор правильного локатора часто становится самым критичным и самым недооценённым аспектом автоматизации.
В этой статье мы разберём общую концепцию локаторов, критерии их качества и ограничения классических подходов. Затем рассмотрим, как Playwright переосмыслил эту философию.
Калифорнийский стартап 1X, бросив вызов таким гигантам, как Boston Dynamics, начал принимать предзаказы на своего человекоподобного робота NEO.
Это одна из первых серьезных заявок на создание коммерческого андроида для дома. NEO, управляемый голосом и искусственным интеллектом, обещает автоматизировать рутину: убираться, мыть посуду, стирать и даже общаться.
Однако за громким анонсом скрывается менее заметная, но критически важная деталь: на начальном этапе большую часть сложных задач за робота будет выполнять удаленный оператор, наблюдающий за происходящим через камеры NEO.
Генеральный директор 1X Бернт Бёрних прямо заявляет, что для достижения истинной автономии необходимо собрать огромный массив данных из реальных домов. Это означает, что первые владельцы NEO по сути станут участниками масштабного полевого эксперимента. Их жилища превратятся в тестовые полигоны.
Этот подход иллюстрирует фундаментальный вызов, стоящий перед всей индустрией: как можно теоретически построить систему тестирования для машин, которым предстоит работать в самой сложной и непредсказуемой среде — в человеческом доме?
Когда инженеры только начинают переносить роботов из лабораторий в мир людей, их ждет столкновение с абсолютно новой реальностью. Цена ошибки здесь измеряется не в багах в логах, а в разбитых вазах, затопленных соседях, травмах и подорванном доверии.
Первоначальный энтузиазм быстро сменяется осознанием: тестирование робота — это проверка его способности взаимодействовать с хаотическим миром. И самый сложный вопрос — не «как тестировать?», а «что именно и в каком объеме нужно тестировать?».
Это схема, которая описывает типы объектов в вашей системе и возможные отношения между пользователями и этими объектами (ролями, функциями защиты и привилегиями).
Классическая ситуация:
«Я данные отправил!»
«А я не получил!»
«А они зависли где-то, потому что формат не тот!»
Пример из практики: комплексный проект по рефакторингу системы управления доступами. Интеграция приложения по управлению доступами на основе ролей и привилегий (это наша Новая система) с другими информационными системами (ИС) в контуре предприятия (например, управление учетными записями, авторизация пользователей и прочие).
Всем привет! Я Катя, QA Tech Lead в MD Audit.
Я собрала пять промтов, которые экономят часы рутинной работы. И они настолько рабочие, что я использую их почти каждый день.
Список не про генерацию тест-кейсов или чек-листов — про это уже написаны километры текстов.
Сегодня поговорим о сценариях, которые редко обсуждают, но которые могут сразу и заметно улучшить вашу работу с ИИ.
Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.
Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад.
На тот момент я, еще студент последнего курса универа, только получил свою первую работу в IT... Как сейчас помню свои эмоции. Наконец-то, спустя годы подготовок и отказов, вот, наконец получаешь свойпервый «настоящий» проект. Осмотревшись по сторонам, понимаю, что кругом меня не то что других джунов нет, но даже мидлов. Сплошные синьоры и лиды, как тогда казалось — грозные дядьки, с большим опытом... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂.
Получаю компьютер, креды для доступа, мне подробнее рассказывают про проект, присылают ссылки на минимальный набор сервисов, что нужно будет локально поднять для работы и отправляют настраивать окружение. В первый же день я сломал заботливо предустановленную мне убунту 😂 (удалил «не ту» версию питона, которая, как выяснилась, очень нужна), ну да ладно, мелочи, с кем не бывает?
Установил минт, начал настраивать IDE, окружение, забрал себе нужные сервисы, вроде все хорошо, НО в одном из сервисов стабильно падает один и тот же тест. Запускаю отдельно — все хорошо и стабильно. Запускаю через сборщик (mvn test) — падение. Пытаюсь разобраться, что происходит — ничего не понятно. Тест падает из‑за мока, которого вообще нет в этом тестовом сценарии. Больше того, смущает ситуация, что ни на ci, ни у кого из коллег такого не происходит. Тест стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.
Привет, Хабр! Меня зовут Александр Кувакин, я backend-инженер в команде Engineering Excellence в Авито. В этой статье разберём, как backend-разработчикам выстраивать систему тестов на бэкенде и разберём основные проблемы. Речь пойдет прежде всего о тестах, которые проверяют бизнес-логику.
Когда работа в QA ограничивается только написанием тест-кейсов и автоматизацией, легко упустить из виду более широкую цель — реальное влияние на качество продукта. Настоящий QA — это про участие на всех этапах, включая прод, про понимание, как работает система в бою, и про осознанный подход к обеспечению стабильности и надёжности.
Я расскажу, как у нас в команде QA-инженеры участвуют в дежурствах на боевом контуре наравне с разработчиками: разбирают инциденты, анализируют причины сбоев и вносят улучшения в продукт и процессы. Поделюсь, какие компетенции для этого нужны, и как такой подход помогает QA не просто проверять, а действительно влиять на качество — не только после релиза, но и задолго до него.
Статья будет полезна и тимлидам с менеджерами, которые выстраивают процессы качества в команде. Она поможет по-новому взглянуть на роль QA, понять, как вовлечение инженеров в прод повышает зрелость команды и осознанность в подходе к качеству.
Лучших инженеров увольняют не потому, что они плохи. А потому что они слишком правы. Их слова рушат иллюзию контроля — и показывают, что план не сработает. Но без них компании быстро понимают, какой ценой даётся это «спокойствие».
Подготовка к ISTQB давно стала своеобразным «обрядом посвящения» для тестировщиков.
Сертификация востребована, работодатели её любят, а многие специалисты воспринимают её как способ структурировать знания и выйти на новый уровень в профессии.
Но есть проблема, о которой вслух говорят редко: готовиться к ISTQB всё ещё неудобно.
Куча устаревших сайтов, странные интерфейсы, вопросы 2011 года, закрытый контент, платные попытки, непонятные подписки, рекламные баннеры — всё это превращает нормальную учебную задачу в мучение.
Именно поэтому я решил сделать тот тренажёр, который мне самому хотелось бы использовать. Так появилась платформа ProSTQB — бесплатный удобный инструмент для подготовки ко всем уровням ISTQB, без рекламы, без paywall’ов и без боли.
Сегодня ProSTQB доступен сразу в трёх форматах: веб-версия, приложение для iOS и приложение для Android, что делает его одной из самых доступных платформ на рынке.
Я уже писал, что всестороннее тестирование является критической необходимостью для обеспечения киберустойчивости. Сейчас хотел бы показать, как этот принцип применяется в условиях, когда ИТ-системы развиваются с беспрецедентной скоростью, а изменения вносятся постоянно. Возникает парадокс: чем быстрее мы внедряем новое, тем выше риск сбоев. Аналитики отмечают, что общее количество инцидентов в критически важных сервисах неуклонно растет. Как же управлять этим "хаосом изменений" и обеспечить стабильность 24/7?
Когда интуитивного тестирования уже недостаточно и качество ведет себя непредсказуемо, метрики перестают быть формальностью и превращаются в обязательный инструмент управления качеством.
За годы работы в тестировании я убедился: то, что невозможно измерить — невозможно улучшить. В статье я разберу ключевые QA-метрики и объясню, как TMS помогает сделать картину качества действительно прозрачной.
Публикация Allure-отчётов — простая задача, пока не сталкиваешься с ограничениями конкретной CI/CD-системы. Но как опубликовать отчёт, чтобы это было и удобно, и стабильно, и без бубнов?
SDET-разработчик Николай разбирает три подхода — от самого простого до функционально полного. Работа GitLab Pages с историей, Allure Server и Allure Docker Service, а также плюсы, минусы и лайфхаками из практики.
Первая полностью автоматизированная ИИ-атака уже случилась. Claude сам нашёл уязвимые компании, написал под них малварь, разослал её и начал шантажировать жертв с требованием выкупа в биткоинах. Взломано было 17 компаний. И это только начало.
Сергей Зыбнев— Team Lead пентестер и специалист по безопасности больших языковых моделей. Это интервью записано в эфире телеграм-канала Ai4Dev — AI for Development, где регулярно разбирают практические кейсы применения ИИ в разработке. Пока разработчики радуются тому, как Opus 4.1 за ночь переписал целый микросервис, злоумышленники уже научились использовать те же инструменты для атак. Prompt injection в корпоративных ботах, скрытые команды в MCP-серверах, ИИ-сгенерированные эксплойты — всё это работает прямо сейчас.
