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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск кажется простым: поле ввода, запрос, список результатов. Но именно поэтому его тестируют поверхностно — «ввёл слово, что-то нашлось, ок». А реальные баги живут в граничных запросах, в тайминге (debounce, гонки), в пустых и ошибочных состояниях и в фильтрах. Ниже — двухслойный разбор: сначала что проверять, потом как это автоматизировать, с реальными сниппетами на TypeScript. Идея переносится на любой UI-фреймворк, но Playwright особенно удобен из-за встроенного перехвата сети.

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

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

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

Property-based testing (PBT) переворачивает подход: вы описываете свойство — утверждение, которое должно быть истинно для любого корректного входа, — а фреймворк сам генерирует сотни случайных входов и пытается это свойство опровергнуть. Нашёл контрпример — ужимает его до минимального («shrinking») и показывает вам.

В июле 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-агента. Агент пропускал обязательные шаги сценария, застревал на переходах, молча менял поведение — без единого изменения с нашей стороны. Это, конечно, не баг-репорт, а пожелание призраку.

В [прошлой статье](https://habr.com/ru/articles/1049482/) я разбирала, почему классический 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 быстро превращаются в источник затрат и как смотреть на автоматизацию с точки зрения бизнеса.

За последний месяц я насчитал минимум семь свежих статей с заголовком в духе "Playwright быстрее Selenium на N%". Проблема в том, что N у всех разный: 23%, 42%, 63%, "1.85x". Методология почти нигде не раскрыта дальше фразы "controlled environment". Для решения, которое определяет CI-бюджет и архитектуру тестов на годы вперёд, это не цифры — это шум.

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

У меня было полторы сотни кросс-языковых фикстур, все тесты зелёные, и я был уверен, что мой Go-порт Yjs байт-в-байт совместим с оригиналом. Потом сравнил байты напрямую с канонической реализацией, и они разъехались: семантика сходится идеально, а на проводе документ толще.

Юнит-тесты, roundtrip и даже конвергенц-тесты систематически пропускают баги совместимости, когда портируешь чужой бинарный формат на другой язык. Рабочий метод один: генерировать фикстуры из канона и требовать в CI побайтового совпадения в обе стороны.

Разбираю конвейер и три реальных бага из трёх своих портов (Yjs, Loro, Willow): документ в 12 раз толще канона, big-endian остров, который молча портил бы все float’ы при обмене, и дыра, через которую 9-байтный апдейт заказывал make() на 67 ТБ. Метод обобщается на любой «порт формата X на язык Y», CRDT тут просто материал.

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

Эта статья про то, как измерять. Точнее, про то, как тестировать и мониторить адаптивные LLM-системы в продакшене и до него, чтобы убедиться: ассистент ведёт себя так, как задумано.

19 июля 2024 года в 04:09 UTC CrowdStrike выкатил обновление контентного файла для своего антивируса Falcon Sensor. За следующие 78 минут 8,5 миллиона Windows-машин по всему миру ушли в бесконечный BSOD-loop. Встали аэропорты (>5000 отменённых рейсов только в США), больницы, банки, биржи, 911-диспетчерские. Прямой ущерб корпоративных клиентов — около $5,4 млрд по оценке Parametrix; одна только Delta потеряла ~$500 млн.

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

Привет, Хабр! Меня зовут Антон Фоломкин, я SDET-инженер в Orion soft. В этой статье я хочу поделиться опытом формирования экспертизы в тестах, которая называется SDET. Проблема качественного тестирования стоит сегодня достаточно остро. Все мы видим сырые продукты, невыловленные баги в привычных приложениях, и часто даже размышляем: «А стоит ли вообще обновляться?». Подобная ситуация сложилась потому, что старые практики тестирования перестают работать в новых условиях. 

Наша компания занимается различными инфраструктурными продуктами — создаем решения для виртуализации, терминального доступа, контейнеризации, управления виртуальной и облачной инфраструктурой, работы с ML/AL. Разрабатывать все это безумно интересно, но долго и сложно. Релизный цикл в среднем составляет полгода, и это значит, что перед выходом каждой новой версии необходимо провести ее комплексное тестирование. Учитывая нарастающую сложность продуктов и их связей между ними, мы решили выращивать в компании тестировщиков нового типа. В этой статье я расскажу подробнее о том, как мы помогаем ребятам становиться SDET-инженерами и что из этого получается.

13 лет я тестировала софт, где у бага был адрес: шаг 1, шаг 2, ожидаемый результат, фактический. Нажал — получил. Нажал ещё раз — получил то же самое.

А пару лет назад я начала тестировать продукты на LLM. И почти всё, на чём держится классический QA, перестало работать. Не «усложнилось» — перестало работать как метод.

Ниже — где именно ломается, по пунктам. Если вы тестировщик и заходите в AI, это ваша новая реальность.

Привет, Хабр! Меня зовут Александр Чесноков, я разработчик команды Platform V DataGrid в СберТехе. Наш продукт – форк Apache Ignite с нашими доработками, и мы активно поддерживаем open-source версию: контрибьютим в основной репозиторий, исправляем баги, развиваем новые фичи, а также поддерживаем инфраструктуру для тестирования.

В этой статье расскажу, как в Ignite мы столкнулись с orphan JVM на тестовых стендах, как они поломали нам процесс тестирования и как мы решили эту проблему, научив дочерние JVM отслеживать завершение родителя через pipe, используя System.in. В конце будет ссылка на конкретную реализацию решения.

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

Я в одиночку делаю детское приложение, где дети учат английский через рисование: рисуют слова, а оно распознаёт рисунок и отвечает голосом. В MVP голос был системный — бесплатный, но звучит как робот из нулевых, пока сам не зайдёшь в настройки и не докачаешь нормальный. Я сделал модалку с инструкцией. Угадайте, сколько людей ей воспользовались. Короче, примерно никто.

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

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

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

В этой статье разберём четыре сценария псевдоавтоматизации и рассмотрим, где система должна переходить от комментариев к действиям.

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

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