Тестирование

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.

Я не стала ходить вокруг да около. Взяла и спросила ребят из IT в запрещенных соц. сетях: за какие ляпы на английском им до сих пор стыдно перед международной командой?

И вот что у нас получилось:

В статье разберём, как именно раннер решает, что тест прошёл, почему .then без return выполняется уже после теста, почему try/catch в async‑тесте — частый источник ложного зелёного, что не так с forEach и setTimeout внутри тестов и какие инструменты не дают тесту соврать. Примеры на Jest, но контракт у Mocha, vitest и прочих тот же.

Привет! Разобрал популярные шорткаты GPT вроде EL5, /REDTEAM, /BULLET — какие реально выручают каждый день, какие работают через раз, а какие лучше не тратить время.
Смотри шпаргалку! 🚀

Мы попытались построить MCP-сервер, который сам читает спеки, пишет автотесты и коммитит код. На практике выяснилось, что токены — не главная проблема, а QA — это не «делатели тестов», а носители контекста и ответственности.

Привет! Это снова Михаил Федоров. В первой статье — архитектура QA Assist: 11 AI-агентов от декомпозиции требований до готовых автотестов. Во второй — как «4 часа подключения» превращаются в неделю корпоративной реальности. В третьей — почему пирамида тестирования ломается, когда тест-дизайнером работает LLM. Сегодня — про то, как я решил наконец-то перестать оценивать агента «на глаз» и собрал отдельный проект-бенчмарк, на котором можно честно сравнивать прогоны: версии агента, отдельные «улучшалки», даже эксперименты с моделями. В качестве бонуса покажу все артефакты, которые агент готовит за один прогон пайплайна. И бенчмарк, и артефакты — в публичном доступе, ссылки в конце статьи. Обсудить всё это можно в Telegram-группе.

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 и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.

Если честно, последние полгода тема AI для учебы начала немного утомлять. Каждую неделю появляется новая «лучшая нейросеть для диплома», очередной сервис обещает написать курсовую за 5 минут, а TikTok заполнен роликами в стиле:
«Вот промт - вот готовый диплом».

На практике всё оказалось намного интереснее.

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

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

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

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

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

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

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