Добрый день, уважаемые читатели Хабра.
В этой статье я хочу рассказать о продукте APItizer, почему появилась потребность в его создании и какой путь привёл от небольшого Python-скрипта к полноценному инструменту для проектирования REST API-контрактов.
Если вам интересно сразу посмотреть на продукт, добро пожаловать в APItizer (прямая ссылка, вдруг домен не работает).
Большинство команд оценивают производительность AI-агентов через end-to-end метрики: success rate, количество токенов, tool usage, стоимость запроса, долю успешных задач. Это полезно для общего контроля ситуации, но почти бесполезно для реальной диагностики системы.
Например, если success rate упал с 85% до 72%, то само по себе число не объясняет причину деградации. Команда вынуждена гадать, какая часть системы вдруг начала допускать ошибки. Сломался retrieval? Модель хуже начала выбирать инструменты? Контекст загрязняется после нескольких ходов? Или система уперлась в возможности base model? При росте проекта и увеличении сложности кодовой базы, сбои начинают расти мультипликативно – ошибки всех систем начинают перемножаться между собой. В конечном итоге, команда теряет реальный контроль.
Проблему решает внедрение покомпонентных eval. Они дополняют end-to-end метрики, показывая, какой слой AI-агента работает, какой деградировал – и где именно искать причину. То есть внедрение evals помогает получать метрики производительности каждого компонента вашего агента.
Внутренний QA-отдел — зона особого риска для любой ИТ-компании. Без новых задач и внешних вызовов команда стагнирует: навыки устаревают, а сильные инженеры уходят в более конкурентную среду. Как следствие, снижается качество тестирования ПО, что приводит к росту числа инцидентов и простоев оборудования.
«ТатИТнефть» не стала ждать первых симптомов и обратилась к нам за независимым аудитом отдела тестирования. Вызовом проекта стали сроки: на разработку методологии и оценку компетенций команды было всего 20 рабочих дней. Как мы уложились и что в итоге получил заказчик — рассказываем в кейсе.
Как удалённый пользователь получил appointment. И что это говорит о том, что значит «удалить» сущность в системе с soft delete.
Пользователь удалён. Appointment создан.
Для удалённого пользователя.
Контекст
Система клиники: пациенты бронируют слоты к врачам. Если слот занят — попадают в вейтлист. Когда appointment отменяется — первый из вейтлиста автоматически получает слот.
Удаление пользователей реализовано через soft delete: в таблице users есть поле deletedAt. «Удалённый» пользователь — это обычная запись с заполненным deletedAt. Физически запись никуда не исчезает.
Это стандартная практика: soft delete позволяет сохранить историю, восстановить данные, не нарушать foreign key constraints.
Сегодня мы поговорим о нагрузочном тестировании. Той самой дисциплине, которая требуется в каждом проекте, но вспоминают о ней только тогда, когда система уже горит, а менеджеры уже успели пообещать клиенту, что «это не повторится».
Сразу — не надо так!
Мы рассмотрим базовые понятия. Без академизма, потому что трудно оставаться полностью серьёзным, когда видишь, как систему нагружают 10 тысячами пользователей, а она написана так, будто её автор рассчитывал на трёх с половиной человек и одного стажёра.
Привет, Хабр! Меня зовут Александр Сахаров, я директор по работе с партнерами компании "Диасофт".
За двадцать с лишним лет в индустрии никто из нас не видел идеального ТЗ. Ни разу. При этом каждый новый проект начинается с уверенного «у нас всё прописано». Компании теряют сотни миллионов на выборе стека, который считают «деталью». А low-code продолжают высмеивать, не заметив, что инструмент за десять лет стал другим.
Есть три мифа, за которые индустрия стабильно платит: «у нас всё написано в ТЗ», «архитектура и стек — детали, разработчики разберутся», и «low-code — для тех, кому лень писать настоящий код». Я собрал практиков из заказной разработки, чтобы разобрать каждый из них. Получился один из редких разговоров, где люди активно спорят, защищая свою точку зрения.
Полная запись на Youtube. Обсуждение — в Telegram-канале Департамент разработки.
История о том, как избавить команду от боли работы с классическими TMS и перенести тестовую документацию туда, где ей самое место - в код.
Дано:
* Растущее количество ручных тестов (иногда переваливающее за тысячи), которые сложно поддерживать.
* Отсутствие нормального переиспользования шагов в стандартных системах, из-за чего приходится постоянно дублировать общие шаги.
* Рассинхронизация между автотестами и ручными кейсами, приводящая к спорам о том, какой тест считать актуальным (главным).
* Сложности с параллельной работой в ветках, ревью изменений и плохой аудит удалений, где один клик может снести целую группу тестов.
Найти:
* Единый источник правды для всех тестов на проекте.
* Механизм, обеспечивающий прозрачный процесс работы с разными ветками, ревью изменений и т.д.
Всем привет! Продолжаю цикл статей про применение ИИ в тестирование. Сегодня поговорим про тестирование требований, а именно про первый и самый важный этап — подготовку контекста.
В своей статье под контекстом я буду подразумевать структурированную информацию о продукте: описания компонентов, бизнес-правила, сценарии использования, связи между сущностями — то есть всё то, что нужно ИИ для понимания предметной области.
Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.
В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.
Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.
Разбираемся с терминологией Test Doubles без лишней воды. В чем реальная разница между Mock, Stub и Fake? В статье разберем классификацию на живых примерах: поднимем умный стаб-сервер на FastAPI, напишем мок-шпион для проверки сайд-эффектов и ускорим тесты с помощью фейковых БД.
Если агент уже ходит в инструменты, читает документы, меняет состояние системы и принимает часть решений сам, проверка одного промпта почти ничего не говорит о надежности. Нужно смотреть на весь путь: вход, найденный контекст, вызовы инструментов, промежуточные состояния, итоговый ответ и побочные эффекты. Ниже - рабочая схема, как строить такие проверки до релиза и после выхода в прод.
Осенью прошлого года мне на почту пришло письмо от Heisenbug. Предлагалось пройти опрос: рассказать, какими технологиями я как тестировщик пользуюсь, чем интересуюсь, на каких конференциях была, что слушала, ну и так далее. За прохождение опроса я становилась участником розыгрыша билета на одну из конференций. Для меня это ничего не стоило, поэтому я решила: «почему бы и нет?».
И каково же было моё удивление, когда под самый Новый год мне приходит ещё одно письмо: «Вы победили в розыгрыше». Я получила бесплатный билет на весеннюю конференцию Heisenbug.
В этом посте делюсь обзором докладов — что зацепило, что удивило, что взяла в работу.
Cursor, Copilot и другие AI‑инструменты обещают быстро закрыть рутину с unit‑тестами: сгенерировать кейсы, расставить моки, добавить ассерты и поднять покрытие. Но зелёные тесты ещё не означают, что код защищён от регрессий.
В статье разбираем пять типичных паттернов, из‑за которых AI‑сгенерированные тесты выглядят убедительно, но пропускают реальные баги.
Когда физического прототипа ещё нет, цифровой двойник кажется спасением: можно писать код, гонять сценарии и ловить ошибки задолго до появления железа. Но у такого подхода есть неприятная ловушка: вы тестируете не только систему, а ещё и собственные предположения о реальном мире.
В статье разбираем, почему идеальная симуляция может привести к провалу на стенде, как искать ошибки без классического «правильного ответа» и зачем инженеру нужны метаморфическое тестирование, кросс‑валидация моделей и проверка границ устойчивости.
Написал утилиту для создания аккордов в любой мыслимой тональности.
Собственно в статье описываю путь от идеи до реализации этой утилиты и показываю, как ей пользоваться.
Также - просто раскрыл базовые понятия муз.гармонии, необходимые для понимания, чем же утилита полезна и в каких сценариях в жизни её может применить пользователь.
Можно много рассуждать, как здорово было бы тестировать продукты в вакууме, когда есть время всё продумать, покрыть тестами каждый сценарий и только потом выкатывать в прод. Но в реальности это так не работает.
Продукт растёт, команды работают параллельно, фичи переписываются, часть вещей живёт на старом коде, часть — на новом. В таких условиях приходится балансировать между скоростью, качеством и здравым смыслом.
Привет! На связи Саша Мищенко, тимлид платформенной команды, и Света Чекунова, Senior QA Auto. Нам кажется, что мы нашли этот баланс.
В последние годы количество запросов на поддержку RedOS значительно выросло& Ранее Test IT позволяла использовать готовые сборки под Ubuntu или CentOS с запуском в контейнерах. Однако рынок идет вперед и клиентам требуется нативный дистрибутив под RedOS 8.02 с официальным подтверждением совместимости и внесением в реестр отечественного ПО. Делимся, как со стороны технической команды прошел крупный проект налаживанию совместимости с отечественной операционной системой.
Меня зовут Даниил, я Android-разработчик в «БКС Мир инвестиций».
В первой статье мой коллега рассказывал, как мы использовали Kotlin IR Compiler Plugin, чтобы автоматически добавлять testTag и semantics в Compose-компоненты: Kotlin IR Compiler Plugin в дизайн-системе: автотесты с Compose без ручной разметки.
Эта статья — следующий шаг: как мы начали использовать информацию о структуре дизайн-системы, чтобы понимать область влияния изменения.
Меня зовут Игорь Симаков, работаю engineering manager’ом и руковожу командами разработки
На одном из наших сервисов, который работает с XLSX-файлами, прилетел production-алерт на высокое потребление памяти. Стандартный P3, обычно решается рестартом. Пошёл смотреть поды и нашёл проблему, к памяти отношения не имеющую, но представляющую больший риск, чем сам алерт. Об этом и расскажу ниже: чем «утечка диска» отличается от «утечки памяти», как мы наткнулись на грабли в Apache POI и как закрыли их на уровне архитектуры
Сейчас студенты поголовно пишут резюме с помощью ИИ, и ИИ поголовно делает им интересное западло: оно вставляет им среди рабочих навыков SVA, то есть SystemVerilog Assertions (ниже я расскажу что это). При виде SVA в резюме я тут же прошу кандидата написать некий простейший SVA на три строчки, и начинается извивание ужа на сковородке:
