Эта история из моей практики показывает, насколько сложно поднять качественное тестирование с чистого листа. Я хочу поделиться своим опытом, который может пригодиться тем, кто рискнёт отправиться в подобное путешествие.
На демо всё выглядит нормально. Промпт аккуратный, ответы связные, JSON парсится, никто не задаёт вопросов. Несколько прогонов спустя — всё ещё работает. Релизим.
Через неделю тот же самый запрос три раза подряд возвращает некорректный ответ. Не так, чтобы всё упало. Просто достаточно, чтобы сломать downstream парсер и разбудить кого-то в два часа ночи. Ничего драматичного. Просто отказ, который повторяется достаточно часто, чтобы начать мешать.
Этот сценарий возникает снова и снова не потому, что команды некомпетентны. Проверка “на глаз” кажется разумной. LLM-фича не падает с исключением, не даёт stack trace, не нарушает очевидных инвариантов. Таблицы expected output здесь не существует. Истину проверить нельзя — проверяют правдоподобие. Ответ звучит нормально, структура в целом держится, а edge cases выглядят академическими.
Есть и культурный зазор. CI вырос вокруг детерминированного кода: фиксированные входы, выходы, которые либо совпадают, либо нет. LLM-фичи выглядят как интерфейсы, но ведут себя как стохастические сервисы с памятью. В ответ команды делают то, что умеют: несколько ручных прогонов, пара промптов в стейдже, галочка “ок”. Это не халатность, а привычная реакция на систему, которая при первом контакте выглядит вежливой и стабильной.
Ломается всё не на демонстрации. Ломается на повторении, дрейфе и накоплении мелких изменений. В промпте сдвинули запятую. Обновилась модель. Temperature подкрутили с 0.2 до 0.4 “для живости”. Прогоните это пятьдесят раз — и картина меняется.
Стабильность E2E-тестов: как добиться 100% успешных прогонов ?
Практика, проверенная на реальном проекте.
Флаки-тесты убивают доверие к автоматизации. В этой статье — проверенные подходы, которые помогают превратить нестабильные E2E-прогоны в надёжный инструмент проверки продукта.
Привет, Хабр!
Меня зовут Елена Грицай, почти полгода я работаю тестировщиком в 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-ноутбуков и ПК вам это может очень даже пригодится.
ИИ фактически обнулил модель «эксперта, который знает всё». Почему исчез поток джун-вопросов, куда делась токсичность и что теперь считается настоящей экспертностью — разбираю на примерах.
