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

Кто ходит в гости по утрам, тот поступает мудро. А кто ходит в гости в инженерный центр, становится еще мудрее. 16 июля встречаемся в офисе YADRO в Санкт-Петербурге, чтобы обсудить тестирование за рамками классического QA и побывать в инженерном центре, где создаются и тестируются энтерпрайз- и телеком-продукты.

Встреча пройдет без трансляции и записи докладов — только живое общение и максимальное погружение в тему. Эксперты расскажут о полевом тестировании базовой станции и особенностях тестирования «железа», а затем для гостей проведут экскурсию по лабораториям, ЦОД и инженерным пространствам.

Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало. Помните эту старую хохму?

Когда в новостях вспоминают о кибератаках на розничные сети, то обычно говорят про слитые базы данных, DDoS и шифровальщиков. Но что, если злоумышленник войдет в магазин с ноутбуком в рюкзаке и внимательно посмотрит по сторонам?

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

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

Итак, приходит Хакер в магазин и обнаруживает: 

• Кассы-трансформеры и терминалы самообслуживания — лицо современного ритейла и его ахиллесова пята.

• Кнопки вызова сотрудников — радиопередатчики с фиксированным кодом, который можно перехватить и воспроизвести.

• Беспроводные трубки стандарта DECT, которые до сих пор используют в торговых залах.

• Терминалы сбора данных — Android-устройства без пароля, с доступом к настройкам Wi-Fi.

• Сетевые провода, которые приглашают к знакомству с внутренней сетью.

Привет, Хабр! Мы протестировали zVirt 5.0 с функциональностью, которой нет в ванильном oVirt. Главное, что нужно знать: в 5.0 на каждом узле меняется гипервизорная операционная система, фактически выполняется переустановка хостов и системы управления. В статье подробно разберу, почему переход на новую версию – это не рядовое обновление пакетов, а отдельный проект со своими особенностями и подводными камнями.

SonarQube подключен, дашборд есть, анализ запускается на каждый MR, но никто не пользуется. В таком случае проблема не в инструменте. Проблема в том, что между «Sonar работает» и «Sonar приносит пользу» — пропасть из-за отсутствия договорённостей. Я видела это на нескольких проектах и расскажу, что конкретно превращает декоративный дашборд в работающий механизм контроля качества.

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

В статье разбираем практический маршрут на REST Assured 6.0.0 и JSON Schema: как закрыть структуру ответа одной проверкой, как сделать схему по-настоящему строгой и где в этой связке спрятан капкан, из-за которого схема с условной логикой выглядит рабочей, но не проверяет ничего.

Дашборд зеленеет, число багов падает, команда получает похвалу — а через пару недель прод ловит инцидент на ровном месте. Так бывает, когда метрики дефектов становятся целью для отчёта и начинают подменять реальное управление качеством. В статье — шесть типовых ошибок: от количества багов как личного KPI до доли переоткрытых задач, которую легко обойти красивой статистикой.

На примере FastAPI-чата показываю, как выстроить автотесты для API с двумя транспортами: REST используется для подготовки состояния, WebSocket — для проверки событий. В статье разбираем архитектуру тестов на Python: клиенты, фикстуры, Pydantic-схемы, контрактные проверки, Allure и CI/CD.

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

Представьте: вы даёте задачу, а интеллект внутри IDE сам всё делает. Без интернета, без копилки токенов. Видит весь проект а не конкретный файл. Это уже реальность.

В чем отличие агента от чата - ассистента?
Всё просто они работают по схеме запрос-ответ. Спросил, получил текст и дальше сам разбирайся. А агент - это совершенно другая история. Агент сам планирует, что делать, сам использует инструменты (редактировать файлы, выполнять команды в терминале, искать по проекту), помнит весь контекст сессии и, что важно, умеет реагировать на ошибки и корректировать свои действия на ходу. Cline в IntelliJ именно такой. Он реально работает в вашей среде, почти как живой коллега.

Привет, Хабр! Меня зовут Андрей Орлов, я QA‑инженер в команде Tarantool Database, VK Tech. Я занимаюсь функциональным тестированием: проверяю новые фичи и изменения, поддерживаю и развиваю автотесты, разбираю инциденты, анализирую логи и метрики. Нагрузочное тестирование и стресс‑тестирование тоже входит в мои задачи — в том числе для проверки поведения Tarantool Database на больших конфигурациях. В этой статье я расскажу, как мы организовали и провели тестирование Tarantool Database на 640 инстансах, какие подходы и инструменты использовали и какие выводы сделали.

Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.

Это не история про «идеальный процесс». Она скорее про рабочую систему, которая помогает не сгореть команде и не терять качество, когда QA в проекте один, а разработчиков восемь.

Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?

Здесь всё на личном опыте, по делу и понятно.

Хотите не забывать детали диалога или то, что вас просили купить в магазине? Конечно, можно по старинке открывать блокнот в телефоне или чат в избранном и записывать все руками, но в потоке задач это неудобно. Гораздо проще надиктовать мысли голосом или записать разговор, а расшифровку доверить сервису. 

Сегодня ASR-системы нового поколения способны учитывать контекст беседы и выдавать осмысленный текст. Однако у любой медали есть обратная сторона — архитектурные ограничения. Чтобы понять, готовы ли эти модели к жизненным сценариям, мы устроили им бенчмарк на Hugging Face. Ниже — разбор того, ломается ли контекстное окно алгоритмов на длинных видеозаписях и как фоновый шум влияет на итоговое качество транскрибации.

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

Всем привет! Меня зовут Олег Малышев. Я один из лидеров стека тестирования в компании «ТехВилл»

Мы продолжаем разговор о том, как применять ИИ в тестировании. В этой статье расскажу, как мы пишем API-автотесты с помощью OpenAPI Generator, Cursor/Claude Code и автоматически считаем покрытие по Swagger через swagger-coverage.

Раньше я уже записывал большое двухчасовое видео по Cursor, где показывал в том числе, как мы генерируем автотесты. Но с тех пор подход немного изменился: мы сильнее завязались на OpenAPI-контракт, добавили Swagger Coverage, JSON-отчёты для LLM и специальные skills для генерации недостающих тестов.

На Хабре есть серия статей, касающаяся заблуждений программистов о, казалось бы, простых вещах: о времени, почтовых адресах, именах и даже дверях. Я недавно пообщался с ребятами, пилящими медицинский софт, и решил собрать набор таких же заблуждений, только применительно к врачебному делу. А чтобы было чуть интереснее, собрал это в виде истории, которой позавидует любой индийский фильм или турецкий сериал.

Итак, перед нами молодой джун Игорь (здесь и далее все имена и фамилии вымышлены), который работает в компании, разрабатывающей софт для больниц. Его только что отправили разгребать легаси-код для ПО, установленного во множестве родильных домов. Одновременно в больницу поступила Елена Соколова, благополучно беременная двойней - будущий кармический спутник Игоря. Но не в романтическом смысле - просто благодаря Елене наш Игорь пройдет через множество Edge-случаев...

Всем привет! Меня зовут Алена, и я продолжаю свой цикл статей про применение ИИ в тестировании. Следующий этап в shift-left подходе — это автоматизация. А в нашем случае — генерация автотестов с помощью ИИ.

После успехов с требованиями и тестовой документацией мне казалось, что дальше всё будет ещё проще. Однако первый pull request оказался настолько «удачным», что его разбор занял почти две недели.

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

Какая главная польза от методик/техник тест-дизайна? В целом, методики обобщают опыт инженеров по тестированию, позволяют систематизировать процесс разработки тестов, снизить их число при сохранении достаточного покрытия. Но если рассматривать строгие методы, то у них есть ещё одно важное свойство: в рамках своей применимости они гарантируют полноту покрытия, благодаря самим алгоритмам этих методов.

Роль и контекст

Короче говоря, я QA лид. Отвечаю за обеспечение и контроль качества сразу на нескольких проектах в компании IT Test. А это значит, что пребывая к контексте десятка имеющихся у нас в портфеле проектов, я выстраиваю процессы тестирования, анализирую связанные с качеством инциденты, развиваю компетенции тестировщиков и, в целом, делаю всё, чтобы QA активности были прогнозируемыми результативными. 

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

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

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

Например, любому QA-инженеру очевидна необходимость ведения тестовой документации. Но как вести таковую, если мы заранее знаем, что текущая реализация функционала отличается от того, как это будет реализовано в итоге? Писать кейсы, опираясь на то, как это работает сейчас, или на то, как это должно быть в финале?

Такие вопросы наравне со множеством иных мне приходится ежедневно решать в ходе своей деятельности.

И данный формат работы требует специфического подхода к обеспечению качества, когда само понимание качества от проекту к проекту начинает варьироваться.

На помощь здесь мне приходят, во-первых, метрики. Те же самые, с которыми работает большинство лидов QA: метрики дефектов, метрики тестового покрытия, выполнения тестов, релизного качества и та метрика, о которой мы далее поговорим более детально - метрика эффективности команды.

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

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

Метрика эффективности команды в нашем случае оперирует таким понятием, как оценка или эстимейт, и служит для понимания предсказуемости и стабильности QA - процесса. Эта метрика включает в себя:

Меня зовут Даниил Никольский, я бэкенд-инженер команды Trisigma. В создании статьи участвовали Искандер Мирмахмадов, руководитель продуктового направления, и Александр Кузнецов, старший аналитик. В этой статье я расскажу про Switchback-эксперименты, рассмотрим как они устроены, почему для него не подходит обычный t-тест, и какая инфраструктура нужна, чтобы проводить такие эксперименты в промышленном масштабе.

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

В июле 2025 coding-агент в Replit проигнорировал явный запрет на изменения файлов (code-freeze) и удалил production-базу – данные примерно 1200 компаний, позже заявив, что «сделал катастрофическую ошибку». Operator от OpenAI, которого попросили всего лишь найти дешевые яйца, сам купил их на Instacart на $31.43 – в обход собственного подтверждения покупки. Официальный чатбот мэрии Нью-Йорка советовал предпринимателям нарушать закон: говорил, что можно забирать чаевые работников и отказывать арендаторам с жилищными ваучерами Section 8. Эти и другие инциденты сведены в обзоре «Towards a Science of AI Agent Reliability», где каждый разделен по характеру сбоя: тяжесть вреда, нарушение полномочий, плохая калибровка.

Ни один из этих случаев не всплыл бы в обычном демо. И ни один бенчмарк про них заранее бы не предупредил.

Публичные бенчмарки полезны – по ним видно, какая модель в целом сильнее и куда движется фронтир. Но они отвечают на другой вопрос. Высокий балл на лидерборде не говорит, справляется ли система с вашими задачами: для этого нужны собственные evals и бенчмарки под конкретные задачи. А часть аспектов – безопасность, устойчивость к злоупотреблениям, поведение под атакой – бенчмарком в принципе не измерить; в этих случаях работает red-teaming. Современная AI-система – это модель в симбиозе с retrieval, tools, memory, routing, prompts, state, permissions. Вы ответственны за всю систему и хотите понимать, как хорошо работает именно она, в то время как публичный бенчмарк измеряет только модель.