В репозитории Awesome First Pull Request Opportunities больше сотни проектов, в которые новички могут делать пул-реквесты и получать обратную связь и даже советы по изучению программирования. Все проекты разделены по языкам и темам: C#, C++, Java, JS, фронтенд, бэкенд, информбезопасность, мобильная разработка под iOS и Android. Каждый найдет проект и стек. Проекты и репозитории ведут реальные разработчики и постоянно их поддерживают. Каждая команда всегда читает пул-реквесты, часто дает советы по разработке и обучению, обратную связь новичкам и даже шанс попасть на стажировку.
Работать в одной команде много лет или менять их несколько раз в год
Обсудили с девчонками-тестировщицами Контура. 💅 Капа Потапова шесть лет в одной команде, Катя Заусова — из бюро тестировщиков, меняет проекты и контекст задач каждые несколько месяцев.
Постоянная смена команд вызывает чувство одиночества и отсутствия долгосрочных связей с коллегами
Меняет команды: Я в команде бюро год и это был мой самый главный страх, что когда перейду туда, то лишусь коллег, с которыми можно пообщаться, попить чай, потусить в свободное время. Но этот год показал обратное: бюро тестировщиков — это тоже команда, у нас есть свои традиции, общение и мероприятия. Это всё позволяет чувствовать себя частью чего-то большого и важного. Но я ещё и сама по себе человек активный, мне важно знакомиться и общаться.
Не меняет команды: Вот! Это самое главное. Мне — наоборот, чтобы сблизиться с коллегой, нужно больше времени — иногда и года не хватает. Я в своей команде уже больше шести лет, и многие коллеги стали роднульками. Но чтобы к этому ощущению прийти, нам нужно было сделать кучу совместных проектов.
Когда работаешь в одной команде, можно решать более интересные задачи, чем когда всё время меняешь её
Не меняет команды: Когда ты работаешь очень долго в одном проекте и одной команде, ты уже знаешь все нюансы и какие там есть проблемы. Не просто «копаешь от рассвета до заката», а понимаешь суть — почему надо сделать так, а не иначе, с чем можно столкнуться в процессе. Для меня интересные проекты — это те, в которых есть неочевидное, когда надо поковыряться, договориться с кем-то.
Меняет команды: В бюро тестирования интересно то, что первое время ты делаешь те задачи, которые никогда ещё не делал. Здесь процессы нужно поднимать с нуля, например, настроить автоматизацию или ревью аналитики. В одном из моих прошлых проектов нужно было выстроить стратегию тестирования, а там были одни разработчики и в итоге всё превратилось в стратегию автоматизации: разбирались, что мы покрываем автотестами, когда это делаем и в каком количестве.
Работа в одной команде даёт больше чувства значимости в успехе продукта
Меняет команды: Конечно, потому что ты регулярно вносишь свою лепту. Но тут ещё важно, чтобы команда рассказывала о своих результатах и успехах, вакуума быть не должно, когда человек думает «У меня есть одна зона ответственности, а на другие даже не смотрю». Чтобы чувствовать свою значимость, тебе нужно хотя бы видеть продуктовые метрики фич.
Не меняет команды: Я бы ещё добавила, что далеко не всем важно ощущать себя частью успеха команды. Бывают люди, которым важно только понимание того, сколько они зарабатывают и возможен ли рост: остальное не очень волнует. Наверное, когда ты приходишь в команду, которая только стартует, и если у тебя есть возможность заложить какой-то фундамент, то в дальнейшем ты будешь чувствовать себя причастным к этому процессу.
Работа в одной команде может привести к выгоранию из-за однообразия
Не меняет команды: Любая работа может, если неправильно распределять ресурсы и не соблюдать баланс, работать по выходным и круглосуточно. Это не зависит от того, в команде ты или в бюро. К потере интереса скорее приведёт монотонность и рутина. С другой стороны, постоянный хаос тоже может быстро надоесть.
Я спасаюсь тем, что у меня много непроектных активностей, например, мероприятия и обучение.
Работа в разных командах позволяет предложить свежий взгляд на задачи, что ценно для продукта
Меняет команды: Главное не применять этот свежий взгляд резко и ультимативно, обрубая всё, что было до этого. Потому что всё новое — это стресс, и каким бы не был продукт, поначалу обновления будут тяжело и долго внедряться.
Не меняет команды: Когда работаешь в бюро, то видишь разные команды с разными подходами. Это прикольно с точки зрения того, что ты так наращиваешь свой опыт и насмотренность, и поэтому у тебя для всех всегда будет пул решений на любой вкус.
ИИ против рутины: как изменится тестирование? Круглый стол на «Стачке»
2–3 октября в Санкт-Петербурге пройдёт XIV международная IT-конференция «Стачка», и мы рады сообщить, что Маргарита Трофимова, директор департамента тестирования и обеспечения качества ITFB Group, выступит модератором круглого стола «Применение ИИ в тестировании».
Маргарита — эксперт с более чем 17-летним опытом в области качества ИТ-систем, вице-председатель Russian Software Testing Qualification Board, спикер ведущих отраслевых конференций и идейный вдохновитель образовательного практикума «Академия тестирования».
На круглом столе вместе с представителями ДОМ.РФ, Альфа-Банка, Авито и других лидеров рынка участники обсудят, как искусственный интеллект трансформирует процессы тестирования, команды и бизнес-результаты.
Будет затронуты ключевые вопросы: — какие задачи уже сегодня эффективнее решают ИИ-системы, — где технологии пока остаются уязвимыми, — как измерить эффект от внедрения ИИ в QA.
Приглашаем QA-специалистов, разработчиков и продакт-менеджеров присоединиться к дискуссии и взглянуть на будущее профессии вместе с экспертами отрасли.
📍 Санкт-Петербург 📅 2–3 октября 🔗 Конференция «Стачка»
Специалист по ремонту компьютерного оборудования, моддер и видеоблогер VIK-on представил тестер оперативной памяти DDR5 для ноутбуков. Модуль выполнен в виде платы размером с плашку ОЗУ SO-DIMM и оснащён дисплеем для отображения ключевых параметров слота ОЗУ. Устройство способно отслеживать напряжение памяти и активность шины SPD, что позволяет понять — видит ли система установленные модули ОЗУ. Тестер оснащён специальной кнопкой, которая позволяет вывести на экран 5 последних POST-кодов (в настоящий момент эта функция доступна только на ноутбуках Asus на базе плат Quanta).
Сегодня, 9 сентября, в мире ИТ вспоминают первый компьютерный баг
В 1947 инженеры Гарвардского Mark II под руководством Грейс Хоппер разбирались с поломкой реле. В какой-то момент они нашли причину — внутри застряла настоящая моль. Её аккуратно извлекли, приклеили в журнал отладки и подписали: «Первый реальный случай бага».
До этого слово “bug” использовали в инженерной среде, но именно этот случай сделал его легендой ИТ.
Забавно, что сама моль сохранилась — её до сих пор можно увидеть в Смитсоновском институте.
С тех пор баги перестали быть буквальными насекомыми, но последствия стали куда серьёзнее.
Вспомнить хотя бы Heartbleed — уязвимость в OpenSSL, обнаруженную в 2014-м. Одна ошибка в библиотеке, которая отвечает за шифрование, открыла доступ к памяти миллионов серверов по всему миру. Пароли, ключи, данные — всё оказалось под угрозой. В СМИ её называли «самым громким багом десятилетия».
Через несколько лет весь мир обсуждал уже Log4j. Казалось бы, скромная библиотека для логирования на Java, использующаяся в тысячах приложений. В декабре 2021 обнаружили, что через неё можно удалённо выполнить произвольный код. За считаные часы уязвимость стала глобальной катастрофой: под угрозой оказались банки, облачные сервисы и даже игровые платформы вроде Minecraft.
В обоих случаях баг оказался не меньше, чем та самая моль в реле. Только если в 1947-м инженер мог достать насекомое пинцетом и продолжить работу, то сегодня одна ошибка в коде способна обрушить бизнес-систему мирового масштаба.
И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.
Как строить эффективное тестирование ИИ-моделей в бигтехе?
Меня зовут Валентин, я — руководитель направления тестирования моделей машинного обучения в Альфа-Банке. Моя команда занимается тестированием ML-моделей и модельных сервисов для наших клиентов уже более четырех лет, и более трех из них я погружен в наши процессы QA.
За несколько лет прошел путь от линейного тестировщика до руководителя команды из 8 человек, и в этой статье рассказываю о своем опыте. О том, как:
начал как единственный тестировщик ML-моделей в Альфа-Банке, совмещая функциональное и нагрузочное тестирование, что оказалось очень сложно из-за ограниченных ресурсов и растущего потока задач,
понял необходимость расширения команды,
столкнулся с выбором между кросс-функциональной командой и специализацией,
продумал подход к делегированию задач,
начал автоматизацию тестирования на основе Postman-коллекций, Pytest и Allure, интегрированную в CI/CD через Jenkins и Airflow, что ускорило и упростило тесты…
Эта статья будет полезна:
• тем, кто только начинает выстраивать процессы тестирования моделей; • начинающим тимлидам QA-команд до 10 человек; • тем, кто просто хочет познакомиться с примером организации QA-процесса с нуля.
Новая глава в твоей QA-карьере может начаться через три, два, один…
Упрощенная схема стенда для тестирования базовой станции LTE
Как насчет того, чтобы сменить привычную тестовую среду на что-то новое? Например, на тестовый стенд с BBU, RRU, симулятором ядра сети и т. д. И сделать это еще до осенних холодов.
Инженеры YADRO из дивизиона Телеком ищут коллег, которые присоединятся к тестировщикам-автоматизаторам. Нужны QА-инженеры с опытом работы в автоматизации тестирования от 2 лет и уверенным знанием Python. Приветствуется опыт работы с Linux и понимание сетей, базирующихся на TCP/IP.
Продолжаем набор специалистов в ИТ-команду SSP SOFT
Привет Хабр! Уже конец лета и не пора ли серьезнее подумать о новой работе — а мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы вы получали удовлетворение от работы.
✔️ Гарантируем интересные задачи ✔️ Для каждого нового сотрудника есть наставник ✔️ Центр компетенций помогает прокачивать навыки ✔️ С нами ты можешь работать из любой точки мира ✔️ Для экстравертов у нас есть офисы в Москве и Томске ✔️ Оптимальный Work Life Balance ✔️ ДМС со стоматологией, обучение от компании и бонусная программа.
📢 На этой неделе мы ищем (см. ссылки на описание вакансий у каждой позиции):
👉 Не обязательно откликаться через hh — присылайте резюме напрямую нашему HR в Telegram: @sspsoft или на почту: job@ssp-soft.com. Не забудьте сопроводительное письмо с фразой «Нашел вас на Хабр», чтобы резюме рассмотрели по-возможности быстрее.
Войти в hardware-тестирование можно с любым бэкграундом. В команде HW QA в YADRO есть специалисты, которые ранее не работали с серверами, и те, кто с первого дня уверенно пользуется осциллографом. От новых сотрудников не ожидают готовых экспертных знаний — важны мотивация и желание разбираться. Остальному обучают внутри команды.
В первую неделю — оформление, знакомство с командой, лабораторией, стендами и процессами, закрепление ментора. За 14 дней — полное погружение в работу с BMC. В первый месяц поощряется командное взаимодействие.
На 2–4 неделе — изучение Linux, устройства продуктов, компонентов, прошивок и инструментов, работа по чек-листам: запуск тестов, анализ результатов. Ко второму месяцу — доступ к целевой платформе, документации и задачам среднего приоритета.
После адаптации определяется вектор роста и формируется индивидуальный план развития с обозначением компетенций и точек роста.
Пример использования матрицы компетенций для оценки сотрудников
Сейчас команда ищет HW QA-инженера в департамент разработки аппаратных средств. Задачи — тестирование инженерных образцов, валидация компонентов, настройка стендов, автоматизация, работа с BIOS, BMC и прошивками.
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):
Мы ценим сотрудников — работа без лишней бюрократии — только задачи, которые приносят результат и удовлетворение от процесса, участие в реальных проектах, развитие профессиональных навыков.
🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
Пишите с резюме нашему HR в Telegram: @sspsoft Или присылайте резюме на почту: job@ssp-soft.com.
И как это экономит ресурсы, улучшает продукт и снижает количество переделок
Одна из ключевых проблем, с которыми сталкиваются компании, заказывающие разработку — это разрыв между ожиданиями и реальностью. Причины бывают разные: неполное или неструктурированное ТЗ, размытые пользовательские сценарии, неучтённые роли или ветвления логики, которые всплывают на стадии разработки и тестирования.
Команда Doubletapp приняла решение: QA подключаются к проекту на этапе первого ознакомления с ТЗ от заказчика, ещё до оценки, дизайна и начала разработки. Этот подход сильно влияет на качество итогового продукта и помогает заказчику получить то, что действительно нужно — без множества итераций «переделать» и «добавить, потому что забыли».
Ниже расскажем, как у нас выстроен процесс, какие задачи берут на себя QA, и почему мы считаем, что раннее подключение тестирования — это не просто хорошая практика, а основа устойчивой разработки.
Роль QA в нашей команде: не только тестирование
Наши QA участвуют в проекте с первых дней.
Структурируют поступившее от заказчика ТЗ
Выделяют функциональные блоки
Формируют уточняющие вопросы
Работают над схемами и диаграммами логики
Проверяют, насколько требования реализуемы и согласованы между собой.
Наша задача на этом этапе — перевести бизнес-язык заказчика на язык разработки и одновременно выловить противоречия и пустые места в логике до того, как они станут багами.
QA плотно взаимодействуют с селлерами и лидами разработки и помогают им формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.
Как это работает на практике
Заказчик приходит с ТЗ. Оно может быть подробным, а может состоять из тезисов, что хотелось бы реализовать в продукте.
QA разбивают информацию на структурные блоки — экраны, роли, сценарии, ограничения, точки перехода.
Составляют вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.
Параллельно разработчики начинают верхнеуровневую оценку трудозатрат. Они тоже собирают вопросы, если логика не до конца ясна.
Все вопросы объединяются, уточняются и через менеджеров идут в диалог с заказчиком.
Такой процесс позволяет уточнить максимум информации до старта разработки и значительно уменьшает риск изменения требований на лету.
Когда это спасло проект
Один из проектов, с которым мы работали, сопровождался очень подробным бизнес-ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработанно.
Однако при формировании схемы ролей и доступов наши QA обнаружили логические противоречия: несколько ролей получали доступ к функциям, к которым не должны были иметь отношения. Это было связано с тем, что в тексте документа не было визуального представления логики переходов, и ошибки остались незамеченными.
На этом этапе проблема была решена за один день — без этой работы её бы пришлось исправлять на этапе тестирования, переделывая часть кода и логику авторизации.
Внутренние процессы: как это устроено
Мы работаем по agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике: анализ, структурирование, детализация, согласование требований, построение логики.
Тест-кейсы и баг-репорты ведём в YouTrack и Qase, используем CI/CD, чтобы как можно раньше получать обратную связь по стабильности продукта.
Зачем это заказчику
Когда QA работают с самого начала, заказчик получает
Прозрачную архитектуру с понятной логикой
Согласованные требования, переведённые в схемы
Минимум доработок в процессе разработки
Экономию времени — на исправление неочевидных ошибок
Повышенное доверие команды к требованиям — все понимают, что делают и зачем
Если вы находитесь в поиске команды, которая помогает не просто писать код, а проектирует продукт вместе с вами, задаёт неудобные вопросы до начала разработки и экономит вам месяцы правок — значит, вам нужен именно такой подход.
Standoff Hacks пройдет в Индии, и ты можешь полететь туда вместе с нами!
→ Во-первых, на нашей платформе активно багхантят ребята из Индии. → Во-вторых, наш следующий ивент Standoff Hacks пройдет 13 сентября в Ахмадабаде. → А в-третьих — у тебя есть шанс попасть на него за наш счет!
🔎 Для этого тебе нужно... Багхантить (surprise)! И набрать с момента публикации этого поста до 18 августа как можно больше баллов по этим публичным программам:
Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики
На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.
В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.
🛠️ Внешние сервисы без тестовых контуров
Решение: собственный мок-сервис на основе WireMock.
Как он работает:
тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;
нужные вызовы подменяются в конфигурации;
при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.
Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.
Плюс: так мы не зависим от внешних API, которые то работают, то нет.
💸Платные вызовы и лимиты на тестовые запросы
Решение: изолированные стенды и замещение моками везде, где возможно.
Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.
Плюсы:
не сжигаем бюджет;
эмулируем ошибки и нестандартные ответы;
ускоряем тесты без зависимости от внешней стороны.
🔄 Нестабильность интеграционных тестов
Решение: изоляция и моки как защитный слой.
Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:
эмулируем нестабильные вызовы моками;
изолируем свою часть и фокусируемся на ее стабильности;
прогоняем тесты на командных стендах — быстро, стабильно и без флуктуаций от партнеров.
🤝 Десятки команд, завязанных на общий процесс
Решение: интеграционные проверки и ревью на совместимость.
Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:
общие тестовые фреймворки и единый подход к интеграционным тестам;
сценарии, которые включают зависимости от других команд;
проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.
В SSP SOFT открыты новые вакансии в ИТ-команды: ищем мидлов, сеньоров и лидов
Мы в SSP SOFT — команда, которая занимается заказной разработкой и активно ведет проекты по модели ИТ-аутсорсинга. Наши специалисты помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Во 2-м полугодии 2025 года мы усиливаем несколько ключевых направлений. Если вы уверенно чувствуете себя как профи, цените системный подход и хотите работать в зрелой команде — присоединяйтесь.
Аналитика и системный анализ • Аналитик DWH • Аналитик 1С (Регламентированный учет) • Бизнес-аналитик (Промтех) • Системный аналитик (ИБ)
Разработка • Lead Python Developer • Android-разработчик (Senior) • Fullstack-разработчик (C#, React) • Разработчик 1С (ЗУП) • Разработчик Angular • Разработчик MS SQL • Data Engineer
Тестирование и поддержка • Automation QA Engineer • Automation QA Engineer (Python) • Automation QA Engineer (Java) • ITSM-инженер
Как мы подходим к найму:
В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
🧩 Наши специалисты нередко входят в состав аутсорс-команд, работающих с внешними клиентами. Поэтому важно не только владение инструментами, но и софтскиллы: умение выстраивать коммуникацию, брать ответственность за сроки и качество своей работы.
🧭 Как устроен процесс найма и адаптации:
1️⃣ Собеседование с HR и руководителем направления, 2️⃣ Техническое интервью с нашими экспертами, 3️⃣ Индивидуальный план онбординга — с учетом ваших сильных сторон, 4️⃣ Испытательный срок — с поддержкой наставника, 5️⃣ Подключение к серьезным задачам — когда вы полностью готовы.
Есть множество видов тестирования, их классифицируют по различным признакам: уровню, целям, степени автоматизации, знаниям о системе, а также типу проверяемых сценариев (функциональные и нефункциональные). Расскажем подробнее о реализации разных видов тестов, которые проводятся в лабораторных условиях:
Модульные (unit) и компонентные (component) тесты реализуют сами разработчики. Они позволяют проверить корректность работы отдельных модулей и компонентов на ранней стадии.
Бокс-тестирование предполагает интеграцию нескольких компонентов базовой станции в рамках единой среды. В этом режиме используются симуляторы пользовательских устройств и ядра сети.
Системное тестирование охватывает проверку сквозных (end-to-end) сценариев на реальной аппаратной платформе. В отличие от бокс-тестов, здесь задействуются реальные пользовательские терминалы и максимально приближенная к коммерческой опорная сеть.
Нагрузочное тестирование и тестирование стабильности позволяют оценить работу системы под высокой нагрузкой в течение длительного времени. Это важно для подтверждения отказоустойчивости и стабильной производительности.
Выделим полевое тестирование. Оно позволяет в реальных радиоусловиях с реальными абонентскими терминалами протестировать описанные выше процедуры. Для такого тестирования используется специальный автомобиль, в котором установлено оборудование для проведения drive-тестов.
Внутри автомобиля для полевого тестирования
Во время drive-тестов используются разные модели пользовательских устройств. Это важно для нормализации результатов и получения объективной оценки поведения системы при работе с многообразием смартфонов.
В статье Ивана Политова и Антон Васина, инженеров из департамента разработки и проектирования опорной 5G-сети в YADRO, читайте подробнее, как в компании тестируют телеком-продукты.
10 задач, в которых AI действительно помогает QA-инженеру
Этот пост – саммари пилота нейросетей на реальном проекте. На тесте было несколько моделей: DeepSeek, Qwen, Gemma.
Вот универсальный список задач по тестированию, с которым все они справляются хорошо:
– анализ логов и stack trace; – поиск причин неочевидных ошибок в пайплайне; – генерация SQL-запросов и объяснение незнакомых конструкций (например, JSONB); – экранирование кавычек в больших XML-фрагментах; – автоматическая генерация тест-кейсов из BPMN- или XML-схем; – генерация случайных данных для теста; – сравнение параметров (включая UTF-8 кодировку) при ошибках интеграции; – проверка SQL-запросов, XSD (XML) и JSON-схем на соответствие структуре; – подсказки по фиксам в случае ошибок, связанных с отсутствием логов; – преобразование описаний ТЗ в чек-листы (но только если текст написан понятно и ТЗ описано подробно, подойдет не для всех и нужно внимательно ревьюить результаты); – написание сниппетов для postman.
Вывод ожидаем: ИИ все еще не заменяет тестировщика, но ускоряет работу. Главное – не забывать проверять то, что получилось.
Проект Zero Day Initiative (ZDI) сообщил о проведении соревнований Pwn2Own Ireland 2025, которые состоятся в середине октября 2025 года в Ирландии. Участникам предложено продемонстрировать эксплоиты для ранее неизвестных уязвимостей (0-day) в смартфонах, мессенджерах, беспроводных точках доступа, устройствах для умного дома, принтерах, сетевых хранилищах, системах видеонаблюдения и устройствах виртуальной /дополненной реальности. Атака должна быть проведена на самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.
Мероприятие примечательно готовностью выплатить миллион долларов за выявление в мессенджере WhatsApp ошибки, позволяющей удалённо выполнить код без действия пользователя (0-click). За удалённо эксплуатируемую уязвимость в WhatsApp, требующую действий пользователя (1-click), премия составляет 500 тысяч долларов, за уязвимость, приводящую к захвату учётной записи - $150 тысяч, а за получение удалённого доступа к данным пользователя, микрофону или камере - $130 тысяч.
В категории "мобильные телефоны" за удалённую эксплуатацию уязвимости в смартфонах Google Pixel 9 и Apple iPhone 16 назначена премия 300 тысяч долларов. При этом введена новая категория - взлом устройства при подключении по USB c размером премии $75 тысяч. За удалённый взлом 3D-шлема Meta Quest 3/3S и умных очков Meta Ray-Ban назначено вознаграждение в $150 тысяч. Максимальный размер премии за взлом устройств умного дома и сетевых хранилищ составляет $50 тысяч, систем видеонаблюдения - $30 тысяч, а принтеров - $20 тысяч.
Привет! Ищу комьюнити тестировщиков. Готовлюсь к конференции и нужна ваша помощь) Исследую вопросы формального vs исследовательского тестирования. Не могли ли бы вы пройти короткий анонимный опрос на 5 минут. Помогите собрать стату и исполнить мечту :)
Про опрос: 13 вопросов на да/нет/наверно. Он опосредован и анонимен, даже я не вижу, кто его заполнял
От вибростендов до полевых испытаний: тесты Hardware QA в реальных условиях
Как понять, выдержит ли стойка или сервер поездку через всю страну в контейнере или грузовике? Чтобы проверить, готово ли оборудование к реальной транспортировке, команда HW QA использует целый комплекс инструментов и методов:
Вибростолы воспроизводят типичные транспортные нагрузки — от тряски в грузовике до промышленных вибраций. Оборудование фиксируется на платформе, и на него подаются колебания заданной частоты, амплитуды и направления. Вибротесты стоек показывают, как сервера реагируют на тряску: анализ ускорения и спектр вибраций (частоты до 10–40 Гц).
Датчики ускорений фиксируют рывки и удары, чтобы оценить реальные перегрузки компонентов.
Полевые испытания: перевозят стойки по России, ставят датчики и собирают реальные профили нагрузок в зависимости от типа грузовика и подвески.
Вибротест стойки: проверяем, как сервера выдерживают тряску при перевозке
Почему это важно? Даже один отвалившийся кабель в пути может сделать стойку непригодной к использованию.
Это лишь часть арсенала Hardware QA в YADRO. В статье директор департамента верификации и контроля качества Игорь Попов рассказал, как команда проверяет стойки и серверы на прочность, какие инструменты используют и как команда инженеров моделирует реальные условия работы оборудования.
