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

Всем привет! Меня зовут Юлия Новикова, и мае 2025 года я стала Team Lead группы фронтенд-разработки в Ozon. В моей команде сейчас 5 разработчиков и 2 тестировщика, и мы создаём фронтенд для админок, которые управляют работой складов, РЦ (распределительный центр) и дарксторов. Но путь мой сюда был не самым тривиальным — до этого я была QA Lead, а не разработчиком.

А началось всё с того, что я начала думать: а что дальше? Кем я могу стать, если ещё вырасту? Вакансий руководителей тестирования, а особенно руководителей отделов тестирования, не так много, а хотелось больше влияния, больше развития. И я решила прыгнуть вбок и сменить профессию: стать тимлидом разработки. Расскажу, как это было и чего стоит ожидать тем, кто задумывается о таком же повороте.

Привет, Хабр! Меня зовут Владимир, я Python-разработчик в команде IMV в Авито. Мы разрабатываем продукт, который помогает оценивать рыночную стоимость товара, будь то автомобиль, квартира или холодильник. Мы часто пишем тесты, и в этой статье я расскажу, как разные подходы к юнит-тестированию влияют на качество тестов, когда они помогают проекту, а когда — мешают, и почему само по себе наличие тестов ещё не гарантирует пользы. Статья будет полезна разработчикам, тимлидам и всем, кто пишет юнит-тесты и поддерживает код в долгоживущих проектах.

На прошлой неделе я попросил Claude устранить однострочный баг. Ему понадобилось 23 тысячи токенов. Потом тот же баг я попросил устранить Gemini. Он потратил 350 тысяч токенов. Да уж, на такое невозможно закрывать глаза.

Поэтому я написал Context Lens — трассировщик контекста, перехватывающий вызовы LLM API, чтобы показать, что же на самом деле находится в окне контекста с разбивкой по этапам. Я подключил его к четырём инструментам кодинга и дал им одну и ту же задачу. Результаты оказались настолько разными, что я решил написать об этом статью.

Вопрос

При работе с этими моделями мы платим за токены. Токены — это довольно сложная тема. По сути, это блоки информации; 1 токен приблизительно равен 4 символам английского текста. Чем больше токенов передаётся в модель, тем больше мы платим.

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

Итак, нам нужно быть аккуратными с нашим окном контекста, а для построения этого окна используются токены. Я задался вопросом: как инструменты справляются с этим ограничением? Насколько умно они его обрабатывают?

Часто SDET-инженеры, работающие со встраиваемыми системами, не приступают к работе, пока не получат реальное железо: датчик, микроконтроллер или плату с новым чипом. Такой подход обычно оправдывают тем, что без физического девайса «на столе» писать корректно работающий софт невозможно. Очевидный минус: увеличивается время выхода продукта и нового функционала на рынок. Но разработку можно начать, даже не имея в своем распоряжении устройства: все дело в договоренности между командами.

Меня зовут Рустам Ахмадуллин, я старший инженер по системной верификации аппаратуры в YADRO. Расскажу на примере датчика температуры LM75A, как написать API без физического доступа к устройству и его прошивке. Разберем методологию Test Driven Development, при которой разработка начинается с написания автоматизированных тестов, а не самого кода.

Благодаря предобучению, большие языковые модели (LLM) приобретают широкие лингвистические способности и общий «кругозор» о мире. Но постобучение — не менее важный этап, на котором они как раз усваивают конкретные намерения человека, ограничения, присущие предметной области, а также требования к надёжности, предъявляемые в продакшне. В  Netflix исследовали, как именно LLM могут открыть новые грани рекомендаций, персонализации и поиска. Для этого в Netflix попробовали адаптировать универсальные обобщённые модели к имеющимся условиям так, чтобы они лучше отражали содержание каталога фильмов и нюансы истории взаимодействия пользователей с сайтом. В масштабе такой компании как Netflix постобучение быстро превращается как в инженерную проблему, так и в проблему моделирования: приходится выстраивать сложные конвейеры данных и оперировать ими, координировать распределённое состояние в масштабах многоузловых кластеров GPU и оркестровать потоки задач, в рамках которых перемежаются обучение и логический вывод. В этой статье описаны архитектура и инженерная философия применяемого в Netflix фреймворка постобучения, который был разработан командой по платформе ИИ с целью скрыть сложность инфраструктуры — так, чтобы исследователи и разработчики моделей могли сосредоточиться на внедрении инноваций, а не на латании распределённых систем.

Привет, Хабр! Я написал эту статью для тех, кто с System Design особо не сталкивался. Никаких предварительных знаний не нужно — всё объясню с нуля. Если вы уже знаете, что такое load balancer — местами будет скучно, но, может, в секции про очереди или мониторинг найдёте что-то новое.

RAG ломается не так, как обычный LLM. У голой языковой модели одна поверхность отказа - генерация. У RAG-системы таких поверхностей две: retrieval и generation. И ломаются они по-разному.

Retriever может вернуть нерелевантные чанки, потерять нужные документы или ранжировать их неправильно. Генератор может проигнорировать контекст и ответить из собственных весов. Стандартные LLM-метрики не ловят проблемы retrieval - они оценивают только финальный ответ.

В статье - практический гайд по тестированию обеих поверхностей:

6 метрик RAGAS с production-порогами: Faithfulness ≥ 0.80, Context Precision ≥ 0.70, Context Recall ≥ 0.70, Answer Relevancy ≥ 0.70

Классические IR-метрики: Precision@K, Recall@K, MRR - для быстрой проверки retrieval без LLM-судьи

Security-тесты: document poisoning, context injection, cross-tenant leakage через Promptfoo

CI/CD pipeline: автоматический quality gate при обновлении knowledge base

От pip install ragas до GitHub Actions - всё с кодом и конфигами.

Соблюдение определённой структуры пакетов или архитектуры крайне важно. Особенно в Java, где для корректной работы некоторые элементы должны быть public или действительно доступны за пределами своего пакета.

В новом переводе от команды Spring АйО рассмотрим библиотеку с открытым исходным кодом ArchUnit, которая помогает в тех случаях, когда одного компилятора недостаточно.

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

Мы в Beeline Cloud собрали несколько open source инструментов, которые помогут решить эту задачу: одни позволят запустить такой код в изолированной среде, другие — вести учет сгенерированных фрагментов кода в репозиториях.

Смарт-контракты могут использоваться не только в публичных блокчейнах, но и в корпоративных и permissioned‑EVM-сетях. При этом с аудитами безопасности по‑прежнему связано много упрощенных представлений: от веры в то, что они не нужны в приватной сети, до ожидания, что аудит способен гарантировать отсутствие уязвимостей.

Мы обсудили эти вопросы с нашим экспертом по аудиту смарт‑контрактов на Solidity, Владимиром Чечеткиным. Под катом — разговор о типичных заблуждениях, качестве подготовки проектов и о том, почему ценность аудита часто раскрывается не в отчете, а в процессе взаимодействия.

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат.

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

Меня зовут Лилия Урмазова, более 20 лет назад я начала работать классическим QA-инженером.

А последние пару лет специализируюсь на тестировании AI-приложений. В настоящее время — Senior Staff AI-QA Engineer/ML Evaluation Engineer в крупной международной IT-компании.

Для тех тестировщиков, кто хочет как минимум быть “в курсе” тестирования AI, я с коллегами подготовила небольшой бе��платный практический курс.

Всем привет!

Меня зовут Игорь Панарин, я же m0nr0e21. Руковожу направлением анализа защищённости инфраструктуры в Дирекции по информационной безопасности РАНХиГС. Мы работаем с распределённой инфраструктурой: офисы, филиалы, ЦОДы — много площадок и зон ответственности. В такой среде важно не просто находить уязвимости, а наводить порядок в процессах, выстраивать понятное управление и делать безопасность системной, а не точечной.

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

Привет, Хабр! Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде.

Я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове:

«Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?»

И тут меня накрыло. Я же слышу это каждый месяц на работе:

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

Чтобы избежать этой ловушки и обеспечить безупречное качество на ��сех платформах, необходим стратегический подход, и ключевую роль здесь играет тестирование пользовательского интерфейса (UI). В «ЛАНИТ Экспертизе» мы помогаем решать такие задачи, и в этой статье мы разберем основы UI-тестирования, но основной фокус сделаем на его мобильной специфике. Вы получите четкий план действий для тех, кто стоит на пороге тестирования мобильных приложений: поймете, с чего начать, каких подводных камней ожидать и как построить процесс, который сэкономит вам нервы и время.

В мире тестирования программного обеспечения часто царит культ «хард скиллов». Selenium, SQL, Postman, Charles, написание автотестов — все это визитная карточка технического специалиста. Безусловно, эти навыки критически важны. Но есть загвоздка: самый совершенный скрипт не найдет баг, который требует человеческого любопытства, и не донесет критичную проблему до разработчика, который вас не слышит.

Пора признать: ключевое отличие тестировщика-исполнителя от тестировщика-аналитика и мыслителя заключается в развитых soft skills.

Последние месяцы я вижу одну и ту же сцену.

Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.

А потом начинаются знакомые фразы:

Уже несколько лет подряд у всех на слуху ИИ и тезисы о том, что он заменит человечество, а если и не заменит, то ускорит до немыслимых высот. Сегодня я хотела бы подискутировать на эту тему в области обеспечения качества, хотя рискую оказаться в ряду динозавров.

Всем привет, меня зовут Настя, и мне НЕ нравится, когда наши компании требуют от нас повсеместное внедрение искусственного интеллекта во все процессы.

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

По данным исследования Positive Technologies, в  период с июля 2024-го по сентябрь 2025 года на Россию пришлось от 14% до 16% всех успешных кибератак в мире. По итогам 2025 года общее количество успешных кибератак вырастет на 20–45% по сравнению с предыдущим годом, в котором их число достигло практически 500, а в 2026-м может увеличиться еще на 30–35%. 

QA-инженеры тратят значительную часть времени не на тестирование, а на анализ требований, написание баг-репортов, подготовку тестовых данных и отчёты для менеджмента.

Как превратить ChatGPT в ассистента, который берёт эту рутину на себя? В статье — 15 промптов, которые уже помогли командам ускорить процессы и освободить время для реального тестирования.

Статья будет полезна manual/automation QA, лидам и аналитикам, которые хотят систематизировать процессы и сократить рутину с помощью ИИ.