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

Как удалённый пользователь получил 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 на три строчки, и начинается извивание ужа на сковородке:

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

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

Представьте внутреннего AI-агента, который помогает компании искать общие документы и управлять ими. Он работает. До тех пор, пока 12–15% запросов не начинают падать. Агент возвращает не тот документ, редактирует не тот файл, молча падает или уверенно ссылается на файл, которого не существует. Поиск по фото отказывает с той же частотой. Ошибки размазаны равномерно по пользователям, фичам и запросам.

Первое инстинктивное действие — поменять модель. Opus 4.5, GPT 5.5 или что там сейчас в топе лидерборда. Меняете. Счет за инференс растет в 4–5 раз, а общая доля ошибок снижается с 12% до 9%. Пользователи пишут о тех же проблемах. Бюджет следующего квартала сгорает за пару недель ради улучшения в 3 процентных пункта — и вы по-прежнему не понимаете, что именно было не так в системе и как улучшать ее дальше.

Эта статья — о том, почему смена модели обычно разочаровывает и куда стоит смотреть в первую очередь. Большинство сбоев AI-систем живет в слое обвязки — orchestration, retrieval, tool definitions, retries, context management, — а не в самой модели. Дальше — метод, как отличить проблемы обвязки от проблем модели, кейс, в котором одно исправление в обвязке подняло completion rate с 26% до 88% без смены модели, и чек-лист, который помогает находить такие сбои в вашей собственной системе. Если вы никогда не делали подобной диагностики — ожидайте найти хотя бы один пункт, который стоит починить.

Привет, Хабр. На связи Маша Лещинская, Head of QA в Surf. Мы все любим пет-проекты, и еще больше — пет-проекты на AI. Но есть нюанс: большинство таких штук забываются через неделю, потому что их сложно и дорого поддерживать. Я сделала проект, который живёт уже третий месяц, и причина не в каких-то крутых технологиях, а в том, что цена поддержки стала минимальной.