В мире технологий есть один необычный момент, который навсегда остался в истории — мотылёк стал частью истории вычислительной техники. Слово «баг» использовалось для обозначения сбоев в работе машин и до этого, но 9 сентября 1947 года это слово приобрело совершенно новый смысл.
Привет, Хабр! Я Ксения Сергеева и сегодня расскажу свою историю, как я оказалась докладчиком на конференции SQA days 36 и (спойлер!) внезапно заняла со своим докладом 3 место среди 56 докладов конференции.
Эксплойты ядра iOS всегда вызывали у меня огромный интерес. За последние годы эксплуатация ядра стала значительно сложнее, и традиционные уязвимости (например, связанные с повреждением виртуальной памяти) стали встречаться реже.
Тем не менее, летом 2023 года felix-pb выпустил три эксплойта под названием kfd. Это были первые опубликованные эксплойты ядра, работавшие на iOS 15.6 и выше.
Разрабатывая джейлбрейк для iOS 14 (Apex), я реализовал собственный эксплойт для уязвимости Physpuppet. В этой статье объясню, как эксплуатировать уязвимость типа physical use-after-free на современных версиях iOS.
В этом топике я не пытаюсь доказать, что тесты бесполезны. Это скорее мои размышления вслух и личная попытка нащупать их реальную ценность. Некоторые идеи в процессе всё-таки зацепили - но скорее как частные случаи, а не что-то универсальное.
Я программирую уже больше шести лет. На самом деле существенно больше (на свой первый аутсорс на PHP я попал примерно в 2016 году), но осознанно подходить к своей карьере я начал не сразу. За это время я вполне успешно поработал в довольно разных местах, от маленьких стартапов до международных компаний.
Недавно я проходил очередное собеседование, и на мой взгляд я неплохо держался. Как минимум до вопроса о том, как я покрываю свой код тестами. После него я стыдливо пробормотал о том, что знаю, как работает assert в python, и даже слышал про pytest. И что я с радостью начну писать тесты как только попаду к ним на проект, просто в наших проектах их не требовали. После чего мы плавно перешли к следующей теме, а оффер я так и не получил.
Когда я вижу очередную статью или видеоурок про тестирование кода, я почти уверен, что мне опять расскажут про моки.
Создаётся впечатление, что это самый лучший и правильный способ писать тесты, и вообще, невозможно обойтись без моков. Это не так! Можно писать тестируемый код без моков. Более того, использование моков следует избегать и использовать их только в специфичных случаях.
Когда-то мой чек-лист «готова ли фича» выглядел как молитва джуна: открыть браузер, нажать пару кнопок, убедиться, что в консоли нет красного цвета (желтое — это нормально, да?), и смело делать merge.
В те времена React был еще зеленым, Backbone уходил в архив, а модные парни на конференциях говорили про какое-то тестирование. Я слушал их как индеец — много слов, мало понимания.
Проект жил быстро, но баги плодились еще быстрее. Каждый хот-фикс тянул за собой новый хот-фикс, как матрешка багов. Я начал бояться рефакторинга сильнее, чем дантист боится собственных зубов.
Переломный момент настал ночью перед релизом. Один пропущенный null-чек положил всю систему авторизации. Пока я в 3 утра откатывал релиз, понял: так больше жить нельзя.
Я устал платить за GPT и думать, куда уходят данные. Нашёл Gemma 3 12B от Google и LM Studio — установил всё за 15 минут. В статье — подробная инструкция и советы, как запустить свою Gemma даже без опыта в ML.
Последние месяцы Model Context Protocol (MCP) — буквально из каждого утюга.
YouTube, Twitter, конференции, доки — все жужжат:
MCP — это прорыв, новый стандарт дебага, интеграция AI в тесты нового поколения и прочее.
Звучит круто. Но, как это часто бывает, — всё сложно, перегружено и на птичьем языке.
В этой статье — простой, честный взгляд на MCP: без зауми, с примерами и аналогиями, которые реально помогают врубиться в тему.
Недавно я делал обзор по текстовым моделям, а теперь — визуал! Всё основано на моём практическом опыте и сотнях картинок. Ваше эстетическое чувство может быть другим, но вот мой топ и их краткое:
Хабр, привет! На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies каждый месяц исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.
С прошлого дайджеста мы добавили еще 7 трендовых уязвимостей.
Привет, Хабр! Меня зовут Алексей Гарцевич, я эксперт в Центре практик направления QA в МТС Web Services. Часто бываю на профессиональных конференциях и одна из популярных тем там — «стеклянный потолок» в карьере. Обычно проблема выглядит так: ты доходишь до определенного уровня и перестаешь понимать, куда двигаться дальше. Возникают сомнения: «я не могу стать руководителем», «я постоянно варюсь в однотипных задачах», «мне некуда развиваться». Это состояние создает ощущение, будто ты столкнулся с невидимой преградой. Я сам сталкивался с такой проблемой и потратил много времени и сил, чтобы ее понять и преодолеть.
Этот текст — попытка сделать материал, которого мне не хватало в тот сложный момент. На примере своего направления QA расскажу, что «стеклянного потолка» не существует. В текущем мире — с быстрым обменом информацией, доступом к рынку и сообществам — возможность развиваться есть всегда. В такой среде сама идея «потолка» становится скорее внутренней установкой, чем внешним ограничением.
Учитывая сложившееся положение на рынке и снижение доступности готовых решений для осуществления сетевых тестирований - актуальным становится рассмотрение любых доступных альтернатив. Один из самых доступных и достойных вариантов - Open Source решение TRex от компании Cisco. Данный трафик-генератор я использую в своей текущей работе и поделиться своим опытом его использования. Его особенности, возможности и как им пользоваться - я бы хотел рассмотреть в этой статье.
Думаю, что данный материал может быть полезен сетевым инженерам и разработчикам сетевого оборудования, которые занимаются тестированием сетевой производительности.
Приглашаю всех заинтересованных под кат!
Облако — большой и сложный продукт, поэтому и процесс тестирования может растянуться… Всем привет! На связи Галина Чупрова, главный инженер по тестированию Облака Рег.ру. В какой-то момент мы с командой поняли, что чем раньше начать тестирование — тем меньше багов получим на выходе. В статье расскажу про этапы, которые помогут устранить «узкие горлышки» в процессе проверки качества продукта и подключить команду с первых шагов проекта. Будет полезно тем, кто начинает путь в тестировании или хочет по-новому взглянуть на процессы в своих командах. Поехали проходить этот квест!
Привет! Меня зовут Дмитрий Березницкий, я больше 25 лет работаю в разработке ПО. За это время видел, как одни команды росли и с лёгкостью внедряли новые фичи, а другие — всё больше погружались в хаос, где любое изменение требует недели усилий и проверки «на авось». Причина почти всегда одна — технический долг. Сегодня я расскажу, что это такое на практике, как его распознать, почему он опаснее, чем кажется, и какие шаги реально помогают.
Технический долг — это не просто неряшливый код. Это системная проблема, накапливающаяся из множества компромиссов, спешки, недостаточной инженерной культуры и отсутствия стратегического планирования. Поначалу всё кажется безобидным: «перепишем позже», «временное решение», «не до этого сейчас». Но потом проект буквально перестаёт двигаться.
И если долго игнорировать эти сигналы — наступает архитектурное банкротство. Это тот момент, когда изменить что-либо в системе уже практически невозможно: любое движение вызывает каскад непредсказуемых ошибок, а разработчики постепенно теряют мотивацию.
По данным Stripe, около 42% времени разработчиков уходит на поддержку некачественного кода. А компании, у которых технический долг под контролем, по данным McKinsey, растут на 20% быстрее. Это подтверждают и мои наблюдения: чем здоровее архитектура — тем быстрее команда реализует новые идеи и меньше выгорает.
Существует распространённое, но опасное упрощение: мол, технический долг — это просто код, который нужно переписать. На деле это больше похоже на финансовую задолженность. Как сказал Уорд Каннингем, автор концепции: «Каждая минута, потраченная на не совсем правильный код — это проценты по долгу». Проблема в том, что в отличие от ипотеки, технический долг не приходит со счётом в конце месяца. Он накапливается незаметно — до момента, когда становится слишком поздно.
Автоматизация тестирования API — задача, с которой сталкиваются даже опытные инженеры, но многие всё ещё предпочитают полагаться на ручные запросы в Postman, а затем переносят их в код — и так годами. Но можно ли избежать этого лишнего шага? В этой статье мы покажем, как настроить эффективную автоматизацию тестов API с Postman и Newman, интегрируя их в процессы CI/CD, чтобы избежать ошибок и повысить производительность.
Каждый год мы проводим масштабные международные соревнования по кибербезопасности Standoff, которые собирают сильнейших специалистов blue team и red team. Очередная кибербитва Standoff 15 проходила на киберфестивале Positive Hack Days 21–24 мая. Формат соревнований предполагает столкновение команд защитников и атакующих в рамках максимально реалистичной инфраструктуры, которая имитирует компании из различных отраслей.
В ходе соревнования защитники используют средства защиты информации (СЗИ) не только для обнаружения и расследования, но и для реагирования и отражения атак. В числе средств защиты была и PT Sandbox — продвинутая песочница для защиты от неизвестного вредоносного программного обеспечения (ВПО), использующая почти все современные методы обнаружения вредоносов. На Standoff песочница подсвечивает почтовые угрозы и помогает остальным средствам защиты понять, является ли тот или иной файл, найденный в сети или на конечных точках, вредоносным.
Кибербитва — это важное испытание для экспертизы PT Sandbox, своего рода ежегодный экзамен. На Standoff мы проверяем способность песочницы обнаруживать техники злоумышленников и корректируем ее экспертизу. А в этой статье мы решили поделиться с вами тем, что же наловила песочница и какие инструменты наиболее популярны у красных команд. Это интересно, потому что атакующие в ходе соревнований ограничены по времени, у них нет возможности месяцами готовить атаку на инфраструктуру, а значит, в соревновании точно будут задействованы самые надежные, ходовые инструменты и методы, доступные и реальным злоумышленникам.
Видеоконференсинг. Автотестирование алгоритмов адаптации качества видео к свойствам интернет каналов. Нам нужно быстрое автотестирование. Автотесты не должны проходить при наличии фатальных искажений в видеопотоке. При этом среднее значение падения качества видео нами так-же учитывается.
Тестирование программного обеспечения уже давно сопровождает процесс разработки в ru-сегменте. Для новичков, и не только, часто остается не до конца раскрытым процесс тест-дизайна. Курсы и статьи дают информацию о техниках разного уровня описания, полноты и качества.
Проблема в том, что на реальном проекте инженер использует те техники тест-дизайна, которые уже приняты на проекте, исходя из устоявшихся процессов и, как следствие, количества времени на тестирование. Ограниченность тестирования во времени часто не даёт инженерам использовать тот набор техник, который хотелось бы. Из-за отсутствия практики техники, которые изучались ранее, постепенно забываются, и их понимание размывается в восприятии.
Тест-дизайн — одна из самых непростых тем в тестировании программного обеспечения. В блоге ЛАНИТ на Хабр я предлагаю вашему вниманию гайд, который поможет вам вспомнить тест-дизайн и его техники. Мы также проанализируем все нюансы и механики, которые могли ускользнуть от вашего внимания раньше. Осознание этих деталей позволит глубже понять инструментарий тест-дизайна и применять его более гибко в работе, определяя оптимальные методы для каждого случая.
Привет! Меня зовут Артём Ашарин, я руковожу аналитикой CRM-юнита в Авито. У нас есть собственная CRM-платформа для запуска коммуникаций в разных каналах, а наша команда аналитиков занимается алгоритмами доставки: когда, кому и с какой частотой отправлять.
В этой статье рассказываю, как мы автоматизировали процесс A/B-тестирования CRM-рассылок, встроили Trisigma в процессы, и почему маркетологи теперь могут делать всё сами.
