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

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

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

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

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

Каждый ноет на ретро. Мы научились ныть так, что работать стало комфортнее и эффективнее. В статье расскажу, что нам помогло.

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

Представьте: вы даёте задачу, а интеллект внутри 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 для генерации недостающих тестов.

Flaky-тесты в Go — неизбежны, но наивные ретраи делают только хуже. Разбираем, почему retry — это не цикл и как правильно реализовать повторный запуск автотестов.

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

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

«Sometimes не работает как ожидается» - так выглядел наш баг-репорт на LLM-агента. Агент пропускал обязательные шаги сценария, застревал на переходах, молча менял поведение - без единого изменения с нашей стороны.

В [прошлой статье] я разбирала, почему классический QA ломается на LLM: нет одного эталонного ответа, один и тот же тест плавает от прогона к прогону, зелёный прогон ничего не гарантирует. Это была статья про осознание проблемы.

Эта - про то, как с этим жить в коде, когда агентов не один, а несколько.

Увы, в июне индекс активности IT-найма никаких особо хороших новостей не показывает. Число нанимающих компаний для роли Manual QA после роста в 2024 году и стабилизации в 2025 году падает уже 7-й месяц подряд. Для Automation и Senior QA продолжается постоянное небольшое снижение. Единственный рост, пусть и небольшой — у AI QA и ML Evaluation, но там рынок еще не сформирован.

Что с наймом в IT?

Есть множество способов узнать ответ на вопрос.

Субъективные – наблюдение за делами в своей компании, получение апдейтов от знакомых в других IT-компаниях или отслеживание новостей о сокращениях.

Объективные – анализ макроэкономических показателей или изучение статистики с числом вакансий на job-сайтах.

Обычно ориентируются именно на последний индикатор – на число открытых сейчас IT-вакансий. Но это относительный параметр (1000 открытых вакансий для конкретной IT-роли – это много или мало?), который не учитывает, что рост как числа IT-компаний, так и соискателей продолжается и во время кризиса (поэтому год назад 1000 открытых вакансий – это хорошо, а сейчас – плохо).

Год назад мы создали более точный индикатор активности найма. 
Ежедневно AI-агенты сканируют напрямую тысячи источников: сайты компаний, ATS-системы и job-сайты. Миллионы накопленных записей о датах открытия и закрытия вакансий по каждой IT-роли в каждой из тысяч компаний позволяют видеть тренд роста или падения найма по конкретным IT-ролям.

При помощи этого индикатора можно узнать, когда (если) кризис закончится.

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