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

Представь: пятница, вечер. Ты запускаешь CI для последнего пулл-реквеста, идёшь наливать кофе, возвращаешься… а билд упал. Один тест. Ты перезапускаешь проходит. «Флаки», — вздыхаешь ты и ставишь лейбл flaky. На следующей неделе история повторяется. Потом ещё раз.

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

Я написал инструмент, который это делает автоматически. Без логов CI, без истории прогонов — только AST и машинное обучение.

Назвал его FlakyDetector. Первая версия была исследовательским прототипом (про него у меня выходила статья на Хабре). А теперь — это полноценный продукт: CLI, веб-дашборд, CI-интеграция и даже React-фронтенд. И да, он open source.

Давай разберёмся, как это устроено.

Flaky‑тесты сложно ловить даже привычными инженерными методами: они ломают CI, подрывают доверие к автотестам и часто воспроизводятся только тогда, когда уже никто не понимает почему. Кажется логичным поручить такую задачу LLM: показать модели код теста и попросить определить, насколько он подозрительный.

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

Каждый спринт мы экспортируем JSON из Kibana, листаем сотни записей и говорим себе, что потом превратим их в тест-кейсы, но потом никогда не наступает.

Логи содержат реальные API-вызовы. Настоящие endpoint’ы, реальные payload’ы, настоящие статус-коды из продакшна. Это ближайшее к спецификации описание того, как система ведёт себя на самом деле. И почти ничего из этого не становится автотестом. Потому что переводить вручную дольше, чем идёт спринт.

Я устал от «потом», написал secure-log2test, CLI-инструмент, который читает экспорт Kibana и генерирует готовый pytest-файл. Одна команда. Работающие тесты.

Главное ограничение, которое определило весь дизайн: никакие данные не покидают машину. Никаких вызовов LLM API. Никакого облака, всё локально.

Всем привет! Меня зовут Артур Поляков, я инженер по тестированию в отделе мобильной разработки в компании iSpring. Наша команда работает над iSpring LMS — мобильным приложением для дистанционного обучения сотрудников.

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

Пятница, до релиза осталось два часа, а на финальной проверке всплывают баги: зависание после оплаты, профиль без обязательного телефона, расхождение в отчёте на несколько рублей. Для QA в такой момент важна не паника и не формальное «блокер/не блокер», а быстрая оценка последствий: кто пострадает, что сломается, есть ли обходной путь, видит ли команда проблему в логах и можно ли безопасно откатиться.

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

Привет, меня зовут Алексей, я C# разработчик. Я разрабатывал библиотеку для автоматизации взаимодействия с различными UI‑элементами и их захвата. Одной из поддерживаемых сред в такой библиотеке обязательно должна быть Windows и в ней так же требуется: находить кнопки, поля, окна, списки, нажимать на них, читать значения, вводить текст и в целом обращаться с интерфейсом не как пользователь с мышкой, а как программа.

На первый взгляд задача звучит просто: нашли элемент, кликнули, пошли дальше. Но в реальных приложениях у элемента может не быть (считай не будет) нормального AutomationId, у нескольких окон может быть один и тот же заголовок, дерево интерфейса может прогружаться не сразу, а старое desktop‑приложение вообще не предназначено для взаимодействия с современными API для автоматизации.

В итоге в моей библиотеке появилось два основных Windows‑подхода:

Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом. С помощью этих юнит-тестов мы уже нашли и исправили много ошибок в функциях на уровне БД, а также сократили загрузку ручных тестировщиков.

Привет, Хабр! В этой статье мы, старший разработчик Анастасия Цацкина и старший инженер-тестировщик Владимир Белинский из IBS, расскажем о нашем опыте внедрения юнит-тестирования на уровне БД.

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

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

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

Материал для тех, кто хочет создавать надежные и масштабируемые моки API-сервисов и любит получать удовольствие от жизни

В этой статье поговорим о том, с чего начать, как лучше подойти к разработке сервисов-моков и как упростить себя жизнь при работе с ними

Примеры и практические советы, как перейти на новый уровень покрытия тестами, если вы интегрируетесь с внешними системами

Привет, Хабр! Я SDET‑инженер в SimbirSoft Александр, в этой статье я предлагаю вам:

Рассмотреть основы Kafka, ее архитектуру и как она работает.

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

— Обсудить роль Kafka в интеграционном тестировании, покажу пример интеграционного теста.

— Материал будет полезен для новичков в области тестирования ПО, как ручного, так и автоматизированного.

Привет, Хабр! Я Эдуард, в команде РСХБ.Цифра занимаюсь организацией проведения нагрузочного тестирования. В нашей команде инженеры НТ занимаются проверкой производительности как монолитных, так и микросервисных решений. Одно из больших направлений — это мобильное приложение «Свои финансы» от РСХБ. В этой статье расскажу о том, как мы проводим нагрузочное тестирование UI‑микросервисов и поделюсь ценными выводами на тему.

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

Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.   

Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.

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

Хабравчане, всех рада приветствовать! Меня зовут Акманова Елизавета, я ведущий аналитик ГК «Юзтех». В своих статьях я стараюсь затрагивать темы, которые считаю важными, и обязательно с опорой на личный практический опыт.

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

ДИСКЛЕЙМЕР

Данная статья отражает личный опыт автора и не претендует на статус эталонного или единственно верного решения. Некоторые моменты могут вызывать несогласие или внутреннее сопротивление, это совершенно нормально. Я описываю конкретную ситуацию, сложившуюся в моей команде в рамках одного проекта. Это довольно специфический кейс, который не обязательно окажется применим в других условиях. Однако для нас он оказался полезным, и я не утверждаю, что так должно быть у всех. Моя цель — просто показать один из возможных вариантов развития событий. Возможно, наше решение совсем не идеально и не безупречно, но оно помогло нам улучшить ситуацию. Поэтому, пожалуйста, не торопитесь с критикой, будет здорово, если просто поддержите.

Надеюсь, это небольшое предисловие поможет настроиться на нужный лад.

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

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

Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.

И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.

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

Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.

Я написал postman2pytest, чтобы их познакомить.

Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.

TL;DR: Я создал BarkingDog — ИИ-сканер безопасности с открытым исходным кодом для Telegram-ботов и веб-приложений на базе LLM. Затем я натравил его на реального, широко используемого опенсорсного Telegram-бота.

Он написал работающий кейлоггер. Подтвердил, что отбеливатель лечит COVID-19. Выдал пошаговую инструкцию по взлому корпоративной сети с указанием конкретных хакерских утилит.

Затем я пропатчил системный промпт. Оценка: 97/100. Никакой смены модели. Никаких изменений в коде. Всего шесть строк текста.

Кратко о себе: в прошлом разработчик смарт-контрактов (с 2017 года), с 2022 года работаю аудитором смарт-контрактов. Эта статья для тех, кто так или иначе интересуется информационной безопасностью и непосредственно аудитом смарт-контрактов (да и процессом аудита в целом).

По итогам аудита могут возникнуть два серьёзных вопроса: «Почему мы ничего не успели?» и «Почему мы ничего не нашли?». И самая страшная ситуация, когда оба эти вопроса возникают одновременно. Опишем это одним ёмким словом: «Провал».

В данной статье я попробую описать типовой процесс проведения аудита на примере систем смарт-контрактов — от самого начала до итогового отчета.

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

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

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