Привет, Хабр!
Меня зовут Елена Грицай, почти полгода я работаю тестировщиком в Fix Price IT. Хочу поделиться наблюдениями о том, как быстрее влиться в новый проект: поговорим и про процессы, и про личные качества, и про командную культуру.
Всем привет!
Меня зовут Алексей Медведев. Первый раз я участвовал в кибербитве Standoff в 2022 году. Далее стал капитаном синей команды (Command and Defend, которая впоследствии сменила название на Ctrl+Alt+Defend) и возглавлял ее на протяжении пяти битв подряд. На Standoff 16 я передал эту ответственную должность и стал своеобразным наставником команды. Расскажу о том, как мы защищали и как нас ломали.
В этот раз, на октябрьском Stаndoff, наша команда защищала город. Эта довольно обширная инфраструктура, включающая в себя несколько сегментов, а также 14 уникальных критических событий (события, реализация которых приводит к нанесению значительного ущерба компании, далее — КС). Перед соревнованиями мы подготовили схему сети, на которой отметили все КС, а также отобразили сетевые взаимодействия между сегментами.
Привет, Хабр! Меня зовут Михаил Новотарский, я из Сбера — лидирую тестирование внутренних продуктов и профсообщество тестировщиков. За плечами более 500 собеседований, от джунов до лидов. Этот материал мы подготовили вместе с Евгением Гребенщиковым, который создаёт и тестирует ИИ-агентов.
Хочу рассказать, как мы применяем ИИ в процессе найма QA-специалистов. Без обещаний революции и без страшилок про «всех заменят». Просто покажу, какие инструменты сделали, где они реально помогают, а где пока спотыкаются. Если вы проводите или проходите собеседования — welcome. Если просто хотите посмотреть, как ИИ работает не на маркетинговых слайдах, а в боевых условиях — тоже пригодится.
Мы создали комплексную систему автоматического развертывания кластеров PostgreSQL, протестировали ее более 150 раз, внедрили у заказчика в изолированной инфраструктуре, и все заработало.
Никакого доступа к рабочей инфраструктуре, никакого интернета, никакого «скопировал — вставил». Даже буфер обмена отключен. Все тестируем у себя, воссоздав полностью среду заказчика. А это уже больше похоже на запуск марсохода.
В 2025 году и фактически, и по ощущениям, в России началась рецессия.
IT она не обошла стороной. Если в начале года произошли сокращения в крупных IT-компаниях, а к весне немного отпустило, то с осени ситуация снова стала более напряженной.
Это не могло не отразиться на зарплатах (спойлер: общая тенденция негативная, но есть и исключения).
Ежегодно отслеживаю, что происходит с зарплатами тестировщиков, используя редкий, доступный мне способ.
В этой статье я собрал девять самых частых задач из live-coding этапов собеседований на Python — от декораторов и замыканий до GIL и паттернов. Эти задачи регулярно встречаются в компаниях разного уровня, и их знают те, кто часто участвует в найме.
Мы разберём каждую задачу: как её формулируют интервьюеры, какие типичные ошибки делают кандидаты, и как выглядит корректное решение с пояснениями. Цель статьи простая — помочь разобраться в базовых механизмах Python, которые важны как на собеседованиях, так и в реальной работе.
Как в реальности тестируют телеком-оборудование, проверяют его на соответствие стандартам и используют искусственный интеллект, чтобы ускорять работу инженерных команд? На недавнем митапе специалисты YADRO и Сбера показали закулисье такого тестирования: от выездной лаборатории, которая ездит по городу и измеряет качество связи, до строгих conformance-проверок по 3GPP и инструментов ИИ, помогающих экономить время на рутине. В статье мы собрали записи трех докладов и разобрали, что полезного можно из них вынести.
Привет! Меня зовут Евгений Семенюк — я Test Manager, Quality Architect и специалист по внедрению AI-подходов в SDLC.
В тестировании я уже 11 лет, занимаюсь построением процессов, внедрением практик качества, автоматизацией и развитием QA-организаций. Обладаю полным набором сертификатов ISTQB Expert Level Test Management, а всего у меня 9 ISTQB сертификатов от Foundation до Expert.
За последние годы на волонтерских начала я помог 100+ инженерам подготовиться и успешно сдать ISTQB.
И чем больше я работал с людьми, тем лучше понимал одну вещь:
ISTQB — это не про “знать больше”, а про “думать иначе”.
Ниже — короткие и честные советы, которые действительно работают.
Привет! Меня зовут Денис. В августе 2024 года я присоединился к компании ЮMoney в роли Fullstack-тестировщика с автоматизацией на Kotlin. Наша команда тестирует и фронтенд, и бэкенд. Автотесты в основном интеграционные — они охватывают интерфейс пользователя и внутренние процессы.
Набор задач обширный. Поэтому, на мой взгляд, для новичка в команде очень важен этап онбординга. Спустя год я хочу поделиться впечатлениями о первых трёх месяцах работы в компании. Расскажу об этапах онбординга в отделе тестирования, курсе молодого бойца и поддержке со стороны команды в течение всего периода.
В A/B-тестах хотелось бы смотреть на главную метрику, ту самую North Star, которая показывает успех продукта. Но на практике она почти всегда медленная, шумная и бесполезная для быстрых решений. Например, вы запускаете тест новой системы рекомендаций, ждёте неделю, две, а LifeTime Value не двигается. И непонятно, это потому что нет результата или ещё рано делать выводы.
Чтобы не тратить месяцы на догадки, можно воспользоваться прокси-метриками — быстрыми, чувствительными показателями, которые реагируют раньше, чем бизнес-метрика «успевает моргнуть». Проблема в том, что это решение часто требует дополнительные ресурсы.
Привет, Хабр! Меня зовут Артем Ерохин, и я Data Scientist в X5 Tech. Я прочитал современные исследования, пропустил их через свой опыт и собрал концентрат подходов к работе с прокси-метриками. Постараюсь передать только суть. Разберемся, зачем нужны прокси, как с ними не выстрелить себе в ногу, где заканчивается польза и начинается самообман.
Привет, Хабр! Меня зовут Илья Знаменский, я ведущий инженер в группе оптимизации алгоритмов искусственного интеллекта в AI-дивизионе YADRO.
Популярность RISC-V растет стремительными темпами, и на рынке появляется все больше новых отладочных плат. Моей команде поставили задачу: узнать, как эти платы будут справляться с простыми AI-нагрузками (задачи запуска LLM-on-device не стояло). В процессе работы мы внесли вклад в развитие собственного тензорного компилятора и создали библиотеку математических ядер, которая позволила существенно увеличить производительность инференса моделей на RISC-V. С какими трудностями мы столкнулись и что в итоге из всего этого получилось — читайте в статье.
Если вы когда-нибудь бывали на ИБ конференциях, то знаете этот ритуал. Бесконечные ряды стендов, много кофе, улыбок, разговоров и... обещаний. Обещания, что новое решение может то-то, что теперь нам что-то не грозит, что теперь оно «производительнее, выше, сильнее…». Да, иногда показывают железо, а чаще только интерфейс, но потом брошюры, каталоги и презентации. Мы тоже так делали, но в этот раз решили сделать по-другому. Если уж мы занимаемся тестированием, то давайте вместо разговоров об этом дадим людям возможность… потестировать тестирование.
Как YDB разворачивается «в бою», что происходит при сбоях, как работает восстановление, как ведет себя кластер под нагрузкой, с какими сюрпризами столкнется команда, которая будет ее администрировать. Весь анализ — с фокусом на уменьшение операционных затрат и повышение надежности.
Представьте: вы открываете письмо, кликаете по безобидной ссылке, и ваш корпоративный аккаунт теперь принадлежит кому-то другому. И это лишь один из четырех критических багов в коробочном SSO-решении, которые мы обнаружили во время рутинного пентеста.
Мы покажем, как одна логическая ошибка в продукте может привести к полному захвату аккаунтов, и объясним, как действовать, когда находишь подобный «подарок» в своей инфраструктуре.
Когда твой тестовый стенд разбросан по этажам, IP-адреса живут своей жизнью, а нужное устройство стабильно «гуляет» между кабинетами — это не инфраструктура, это квест. Три года назад я подключался к железкам по SSH и даже не знал, где они физически находятся. Сегодня всё иначе: у нас универсальная тестовая лаборатория, собранная как из конструктора LEGO — аккуратная, управляемая, с централизованной сетью, удалённым регулированием питания и мониторингом.
Этот текст — про то, как из хаоса родился порядок. Как вместо десятков разрозненных девайсов появилась стойка, где каждый винт, кабель и IP на своём месте. И как одна инженерная идея может превратиться в систему, которая экономит часы, нервы и делает работу с тестами наконец-то предсказуемой. Эта статья написана по мотивам моего доклада для конференции Highload++.
Вам нужно было хоть раз запускать x64 программы под Linux на ARM платфоме? Если да - это статья для вас. В ней я рассказываю про способы запуска программ с другой архитектуры на ARM.
Также это статья для вас, если вы хотите на будущее знать способы, которые есть для запуска. Когда наступит эра ARM-ноутбуков и ПК вам это может очень даже пригодится.
ИИ фактически обнулил модель «эксперта, который знает всё». Почему исчез поток джун-вопросов, куда делась токсичность и что теперь считается настоящей экспертностью — разбираю на примерах.
Привет, меня зовут Иван и я SDET‑специалист в SimbirSoft. Полагаю, каждый программист хотя бы раз слышал про инструмент Kafka, многие работали с ним. Наиболее простое его использование — это настройка взаимодействия между микросервисами. А если попробовать использовать его как инструмент для логирования — связать Kafka и Elasticsearch? И при чём тут вообще Elasticsearch? Все просто: это система, которая позволяет работать с большим объемом данных. В нашем случае также необходимо использовать Kibana, надстройку над эластиком, которая позволит визуализировать данные.
В этой статье мы рассмотрим процесс настройки потоковой передачи логов из Kafka в Elasticsearch:
— как настроить взаимодействие между Kafka и Elasticsearch
— как настроить Kibana для визуализации логов, хранящихся в Elasticsearch.
Эта статья будет полезна тестировщикам для настройки анализа логов в распределённых системах, а также разработчикам, желающим реализовать альтернативные сценарии использования Kafka для централизованного логирования.
Перед началом разбора хочу отметить, что это один из моих первых writeup'ов в рамках сезонного ивента Season of the Gacha на HackTheBox. Машина Gavel оказалась весьма интересной и познавательной, но также она заставляет немного приложить усилий, терпения и логики. Не скажу, что у меня не было проблем с прохождением, но я думаю, что испытал внутреннее удовлетворение после прохождении, давайте приступим!
Привет Хабр! Если вам тоже доводилось разбирать незнакомый проект, сопровождать прод или помогать QA, вы знаете, как быстро начинаешь ненавидеть однообразные команды etcdctl: копировать ключ, вбивать get, ловить в терминале многострочные значения, скроллить историю… Особенно если ключей сотни, а половина из них — конфиги или JSON’ы на несколько экранов.
Мне хотелось чего-то попроще: запустил один бинарь в терминале и спокойно ходишь по дереву ключей etcd, как по файловой системе, подобно mc.
Без браузера, без копипаста, с нормальным просмотром и редактированием многострочных значений. Так появился etcd-walker.
Под катом расскажу, как он устроен, почему в etcd v2 внезапно пропадают ключи, которые начинаются с подчеркивания, как их всё-таки увидеть, зачем понадобилась “инъекция” узлов, и как решить боль с большими многострочными ключами, например JSON или yaml. А также покажу, как этот инструмент помогает разбираться с локами, которые создает python библиотека для работы c etcd.
Если вы хоть раз пробовали разгрести чужое хранилище в etcd, то поймёте, почему без подобного инструмента жить уже не хочется.
