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

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

Но если сценарий становится нелинейным (появляются развилки, выбор пользователя ведёт на разные экраны) всё усложняется. С этим E2E-тесты ещё справляются: пишем несколько тестов, каждый под свой путь. Сложнее, но решаемо.

Мы столкнулись с этим при работе с платформой в Услугах Авито: пользователь заполняет форму заявки, переходя между экранами. Логика переходов между экранами зависела от категории услуги, типа экрана и выбранных опций. Сценариев стало попросту слишком много. Пришлось искать другой путь. 

Меня зовут Константин Горностаев, QA в Авито, в этой статье я расскажу о подходе, который позволил нам решить эту задачу и получил название «система фейков».

Разбираю как выглядит нормальный QA-пайплайн в GitHub Actions: от линтинга до E2E тестов на Playwright. С рабочими конфигами, кэшированием и уведомлениями о падениях.

Как тестировать систему, если половина её компонентов — это «чёрные ящики» с уникальными протоколами, а стандартные API-mocks не справляются? С точки зрения готовых решений — тупик… 

Меня зовут Дмитрий, я AQA-инженер в ИнфоТеКС. Мы с командой столкнулись с этой проблемой и создали собственные API-mocks, которые не просто отвечают шаблонными сообщениями, а ведут себя как настоящие компоненты системы. В этой статье — наш путь от идеи до работающего решения, которое можно адаптировать под ваши задачи.

Привет, Habr.

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

Если чуть дольше повариться в рынке, становится видно, что вокруг собеседований уже давно существует отдельная инфраструктура. Речь про слитые вопросы, базы по компаниям, закрытые чаты, документы и каналы, где собирают и передают друг другу реальные этапы найма. Причём это уже давно не история про редкие “утечки” или единичные случаи. Для части рынка это вполне рабочий инструмент подготовки.

Сразу уточню важный момент. Эта статья не про мораль, не про публичные разоблачения и не про попытку назначить кого-то злодеем.

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

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

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

Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.

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

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

Красиво, правда? Прямо слайд для презентации. Давайте проверим эту цифру на реальном проекте — и посмотрим, насколько я был честен с вами (спойлер: не совсем).

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

В этот момент прокси-инструменты вроде Proxyman начинают играть совсем другую роль. Это уже не просто «посмотреть запросы», а полноценный слой управления трафиком.

Меня зовут Станислав, я Test-инженер в KODE, в этой статье разберу, как использовать Proxyman Scripts не как вспомогательную фичу, а как инструмент автоматизации тестирования.

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

Причина в архитектурных минах которые заложили месяц назад и забыли. В этой части разберём самые частые из них и настроим ESLint чтобы робот ловил их вместо лида на ревью.

Примеры кода намеренно упрощены для наглядности. Фокус на идее, не на архитектуре.

Когда код уже написан, половина багов уже не исправить. Парадокс? Нет — статическое тестирование. В этой статье разбираю, как находить дефекты ещё на этапе требований, почему «большой взрыв» интеграции — это путь в никуда, и зачем знать про заглушки, драйверы и уровни от компонентного до UAT.

Всем привет! Меня зовут Юля Трусова и я тестировщик. А ещё я лидирую под ключ одно из самых крупных и древних комьюнити в Авито — QA Community. В этой статье я расскажу про свой подход к теме, поделюсь важными вехами в становлении комьюнити и с удовольствием почитаю про ваш опыт в комментариях.

Наш тестовый фреймворк перестал масштабироваться с ростом сервисов. Мы переработали архитектуру, ввели разделение на слои, упростили масштабирование автотестов и подготовили фреймворк к интеграции SDK и использованию AI

Важное уведомление

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

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

Ответственность за применение полученных знаний лежит исключительно на пользователе.

Возможно, ни одна из описанных технологий не нова. Но их сочетание — с учётом российских реалий (CGNAT, DPI, белые списки) — представляет собой, насколько я вижу, ещё не реализованный на практике open-source проект. Приглашаю сообщество проверить эту гипотезу вместе.

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

Этот материал вырос из нашего доклада на Infostart Tech Event в прошлом году. Здесь я подробно разберу, как мы перестраивали процесс тестирования релизов в крупном проекте 1С:ЗУП: с чего начали, какие проблемы выявили, почему не стали автоматизировать всё подряд и к какому результату в итоге пришли.

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

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

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

Playwright — фреймворк от Microsoft для E2E-тестирования — был построен с нуля, чтобы решить именно эту проблемкую. В нем есть автоматические ожидания, изоляция через Browser Contexts и встроенный тест-раннер. Разберём, чем он отличается от Selenium и Cypress, и как писать тесты, которые не падают от ветра.

Даже с чистым кодом тесты могут падать с завидной нерегулярностью. Раз в десять прогонов, чаще в CI, чем локально. Не потому что CI какой-то особенный, а потому что там может быть меньше CPU, выше latency между сервисами и куча параллельных процессов. Асинхронные проблемы никуда не деваются и локально, но более мощная машина и быстрая сеть их маскируют. Стоит условиям стать чуть хуже, и тайминги разъезжаются: фронтенд уже отрисовал результат, бэкенд ещё обрабатывает запрос, а транзакция в базу ещё не закоммичена. Тест идёт проверять и не находит там того, что ожидает.

Три темы, которые дают стабильность на больших числах:

Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».

В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM

примеры таблиц, схемы и чек-лист для QA

Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.

Дефекты — неизбежная часть разработки, но если они живут своей жизнью в чатах и трекерах, релизы превращаются в лотерею. В этой статье рассказываю, как выстроить системное управление дефектами: от жизненного цикла и сортировки до метрик вроде MTTR и SLA. Вы узнаете, чем серьёзность отличается от приоритета, почему «не воспроизводится» — это красный флаг для команды, и как метаданные дефекта экономят часы разработчиков.

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

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

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