Тестирование IT-систем *

Как повысить доступность оборудования для работы по предназначению и сократить издержки 

Внезапный выход оборудования из строя это не просто техническая неисправность. Для любого производственного предприятия это прямые финансовые потери, срыв сроков и удар по репутации. Многие руководители ищут спасение в сложных предиктивных технологиях, надеясь, что «умные» датчики предупредят о каждой возможной поломке. Однако, как показывает практика, универсального решения, способного предсказать износ каждого подшипника, провода или шестерни, не существует. Проблема гораздо глубже и требует не столько технологического, сколько системного подхода в работе предприятия. 

Границы предиктивной аналитики: почему датчики не видят всей картины 

Современный станок, да и в целом любой оборудование, является сложным комплексом механических, электрических и электронных компонентов. На одном агрегате могут быть десятки подшипников, множество направляющих, зубчатых реек, датчиков, энкодеров и контакторов. А какое электронное устройство способно оценить степень износа зубчатой рейки в зоне активной работы? Как измерить усталость металла в скрытой части станины или определить, что контакт в клеммной коробке стал ненадежным?  Никакое. Никак.

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

Каждый разработчик хотя бы раз в жизни сталкивался с ситуацией, когда баг, который вроде бы уже исправлен, неожиданно возвращался в продакшен. В этой статье я расскажу о тех случаях, когда ошибки служили для меня не провалом, а очень настойчивым, но полезным учителем. Да, иногда именно они объясняют архитектуру, принцип работы систем или забытый corner case лучше самых толстых документаций. Эта статья не учит идеализму — наоборот, она про то, как ценить несовершенство.

Привет, Хабр!  Мы провели вместе долгие часы, изучая коммутационное оборудование Eltex для ЦОД: строили фабрику, устраивали ей  пожар  нагрузочное тестирование,  тестировали на совместимость с заморскими вендорами… Не знаю как вы, а я очень устал от всех этих команд, проверок и… страха, что вся конфигурация сбросится, не сохранится, и мне придется набивать всю конфигурацию с нуля. И тут я подумал, ведь у Eltex есть система управления ECCM, заточенная под их оборудование. Почему бы мне параллельно с написанием статей не применить ее, чтобы воспользоваться всем спектром возможностей?

И вот она нарядная, на праздник к нам пришла…

Привет, Хабр! Меня зовут Максим Шишкин, я инженер по нагрузочному тестированию в команде Platform V Works::Artifactory в СберТехе. Наше решение — менеджер репозиториев артефактов и контейнеров. Он позволяет организовать хранение, описание, тегирование сборок и дистрибутивов программных продуктов, а также готовых Docker-контейнеров.

В этой статье я расскажу, как и почему мы перешли на Java 17, как протестировали возможности нового сборщика мусора Z Garbage Collector и в результате сэкономили ресурсы виртуальных машин — а вместе с этим и финансы. Надеюсь, наш опыт будет полезен инженерам по сопровождению, командам разработки и тестирования.

В этом посте хочется поделиться 20-летним личным опытом в тестировании и приходу к частичному отказу от тестовой модели с использованием тестовых кейсов. Переход был плавным. Не планировала загружать статью сложными метриками и цифрами, но хотела показать постепенную эволюцию сквозь призму личного опыта в стиле некоторого ревью. Для многих мой опыт наверняка окажется созвучным с их личной практикой, но также допускаю, что есть ситуации, компании или продукты, где стоит использовать классические подходы. Так или иначе, кто-то подкрепит свои догадки и сложившиеся подходы, а кому-то будет интересно почитать, как оно все происходит у других, и почему они выбрали именно такой подход.

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.

В этой статье представлены Chrome-расширения для QA-инженеров, которые не повторяют функции DevTools, а дополняют их. Эти инструменты помогают автоматизировать рутинные задачи, ускоряют проверку форм и API, упрощают анализ данных и визуальное тестирование, а также открывают возможности для проверки сценариев, которые сложно реализовать стандартными средствами браузера.

Кто-то тестирует виртуальные кнопки в интерфейсе, а кто-то — железные кнопки умной колонки. Чем отличается такое тестирование и какие у него особенности? YADRO и московское сообщество тестировщиков MoscowQA объединились и нашли экспертов, которые дадут ответы на эти вопросы в рамках QA-митапа 11 декабря (четверг) в Москве. Для участия офлайн или онлайн регистрируйтесь на сайте.

Почему оффер ломается не на алгоритме, а на вопросе «кем вы видите себя через 5 лет?» — разбираю шесть таких ловушек и показываю сильные ответы.

Когда ты тестируешь интернет-магазин, пропущенный баг — это съехавшая вёрстка. Но если ты тестируешь высоконагруженную СУБД — это остановка бизнеса федерального масштаба. Разбираем внутреннюю кухню QA в Postgres Professional: от борьбы с утечками памяти через ASAN и Valgrind до «вайб-кодинга» с ИИ. Узнайте, как выстроить процессы качества так, чтобы не уронить прод, когда цена ошибки исчисляется миллионами.

Привет! Меня зовут Юра Байков, я ведущий ведущий QA-инженер и много раз проводил собеседования на позицию тестировщика в свою команду. Да, на Хабре много постов о том, как проходят такие встречи и как к ним подготовиться. Но сегодня хочу поделиться именно своим опытом: подскажу, какие книги прочитать, чтобы укрепить базу, — шок-контент, но их всего две. А еще расскажу, о чем я спрашиваю джунов на собеседовании.

Во избежание недопониманий подчеркну, что это исключительно мой опыт и в моей практике он работает. У вас может быть другое видение — и это нормально. 

2025 год начался с короткого затишья текущих проектов, возникла идея поковырять тему нагрузочного испытания радиоподсистемы Wi-Fi. Основная сложность и основной вопрос всех нагрузочных тестов - Чем нагрузить? Вот этот вопрос попробуем разобрать в этой статье ...

Привет, Хабр. Пишу, потому что на текущем проекте прямо сейчас живу эту боль: всем включили 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 по сути станут участниками масштабного полевого эксперимента. Их жилища превратятся в тестовые полигоны.

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

Когда инженеры только начинают переносить роботов из лабораторий в мир людей, их ждет столкновение с абсолютно новой реальностью. Цена ошибки здесь измеряется не в багах в логах, а в разбитых вазах, затопленных соседях, травмах и подорванном доверии.

Первоначальный энтузиазм быстро сменяется осознанием: тестирование робота — это проверка его способности взаимодействовать с хаотическим миром. И самый сложный вопрос — не «как тестировать?», а «что именно и в каком объеме нужно тестировать?».