Статья из блога компании ИнфоТеКС Tech

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

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

Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.

Где мы сейчас: ИИ уже в разработке, но почти не в автотестах

По данным недавнего опроса StackOverflow, 84% разработчиков постоянно используют ИИ‑ассистенты в своей работе. Для них это такой же привычный инструмент, как IDE или Git.

Как обычно работает подобный ИИ‑помощник в IDE:

• анализирует открытые файлы;

• дополнительно смотрит на соседние файлы в проекте;

• учитывает локальный контекст: какие вопросы вы задавали и какой код меняли.

А вот автотестировщики часто оказываются как будто «на обочине» этой ИИ‑революции.

Специфика продуктов InfoWatch состоит в анализе самых разнообразных данных. Поэтому практически каждый автотест требует подхода с широким набором параметров. Для нашей команды хорошим решением стало вынести генерацию параметров pytest.mark.parametrize в отдельный компонент, который собирает данные из файловой коллекции проекта.

Существует множество способов параметризировать тестовые функции. Эта статья — пример изящной параметризации Pytest для сценариев, основанных на файловой коллекции проекта с большим количеством данных. Расскажем про наш опыт решения такой задачи.

Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д.

Автор:

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

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

И поскольку мне нравится автоматизировать свои проблемы, я решил упростить это с помощью инструментов, которые пробовал в последнее время. Покажу, как использовал Goose, Playwright MCP и их новое расширение Playwright MCP Bridge для Chrome, чтобы автоматизировать скучную задачу создания множества тикетов во внутренней системе отслеживания задач.

Автор:

Когда вы пишете end-to-end тесты, аутентификация часто становится первым барьером. Невозможно протестировать реальную функциональность приложения, не пройдя сначала экран логина. Но современные методы аутентификации могут усложнять автоматизацию, используя несколько факторов, которые трудно автоматизировать (в этом и заключается смысл 2FA).

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

Так как же правильно работать с аутентификацией?

Автор:

ИИ-ассистенты для написания кода - Claude Code, Cursor и GitHub Copilot, - становятся частью повседневного рабочего процесса. Они читают файлы, понимают кодовую базу и помогают писать код быстрее. Но есть проблема — они также могут читать .env-файлы. В последнее время в соцсетях ходит история об этом, и я сам столкнулся с этим на практике:

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

Автор:

Если вы следите за сферой AI-ассистентов для программирования, то, скорее всего, заметили, насколько быстро всё развивается. Новые модели выходят каждый месяц, и все пытаются выявить «правильный способ» работы с этими инструментами. Я провёл последние пару месяцев, создавая тесты на Playwright с помощью Cursor, и, честно говоря, прошел через множество проб и ошибок. Некоторые вещи работали отлично, другие… не очень.

Я решил собрать всё, чему научился, в этом посте. Давайте разберёмся.

Мы продолжаем разговор о том, как применять ИИ в тестировании. В этой статье расскажу, как мы пишем API-автотесты с помощью OpenAPI Generator, Cursor/Claude Code и автоматически считаем покрытие по Swagger через swagger-coverage.

Раньше я уже записывал большое двухчасовое видео по Cursor, где показывал в том числе, как мы генерируем автотесты. Но с тех пор подход немного изменился: мы сильнее завязались на OpenAPI-контракт, добавили Swagger Coverage, JSON-отчёты для LLM и специальные skills для генерации недостающих тестов.

Нестабильные (flaky) тесты создают постоянные трудности для тестировщиков. Такие тесты не отражают состояния тестируемой системы и подрывают доверие к тестовому набору.

Вооружившись лучшими практиками, нестабильность можно свести к минимуму, но полностью избавиться от неё крайне трудно. Чтобы лучше её контролировать, нужны инструменты, позволяющие выявлять нестабильные тесты — например, Allure Report. В этом руководстве мы посмотрим, как Allure работает с нестабильными тестами:

• Исследуем, как устроена история тестов

• Разберёмся, как история позволяет определять нестабильные тесты

• Настроим перезапуск тестов

Эту функциональность мы рассмотрим на примере PyTest, но все те же принципы работают и с другими фреймворками.

Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты?

У меня было смутное представление о некотором тёмном «раньше», и условно-ограниченно-просвещённом «сейчас», когда мысль о том, что тестирование не должно жить отдельно от разработки, кажется, стала нормальной.

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.

Автор:

Облачные приложения: текущая ситуация

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

Сегодня вы можете построить приложение, на 100 процентов работающее в облаке. Наиболее популярны сейчас облачные провайдеры AWS, Google Cloud и Azure. Именно эти трое во многом обеспечивают работу большинства облачных приложений. В 2023 году компании потратили примерно 270 миллиардов долларов США на облачную инфраструктуру — на 45 миллиардов больше, чем годом ранее.

Большинство облачных провайдеров взимают плату в зависимости от объёма использования сервисов. Чем больше вы используете сервисы провайдера, тем серьезнее будет счёт в конце месяца. Как правило, провайдеры всё ещё предлагают бесплатный тариф, но при превышении определённого лимита вам всё равно придётся платить. Проблема в том, что многие компании сильно зависят от этих сервисов и активно их используют, из-за чего сложно оставаться в рамках лимитов. 49 процентов компаний испытывают трудности с контролем затрат на облако, а 33 процента превышают бюджет на облако на 40 процентов.

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

Со временем такие решения начали накапливаться. Разные сервисы использовали разные паттерны для HTTP‑клиентов, ретраев, подготовки данных и валидации ответов. Общие абстракции постепенно размывались, а направление зависимостей становилось менее очевидным. Дополнительно ситуацию усиливали срочные задачи, которые требовали быстрых изменений без полноценного архитектурного пересмотра. Это приводило к появлению временных решений, которые затем становились постоянными.

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

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

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.

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

Подход, который я долгое время использовал массово - написание юнит-тестов с использованием Mockito. В заглушки превращается любой сторонний сервис, используемый тестируемым классом. Тесты супер-быстрые, все зеленое, все супер!

Со временем я заметил, что этот подход начал изрядно напрягать. Часто на две строчки кода приходилось писать не менее 10-20 строк теста. Огромное количество переопределений поведения заглушек. Проверки, что тот или иной метод сторонних сервисов более не вызывался или вызывался не более определенного количества раз. Без преувеличения, огромное количество бойлер-плейт кода в тестах.

Дальше - больше. Множество зеленых галочек, появляющееся на экране при запуске тестов, не могло не радовать. Но вот ты решаешь сделать минимальный рефакторинг, оптимизировать какой-то метод. В этот момент все разваливается на куски. Куча красных тестов! Как, почему? Да просто во внутренней реализации ты перешел на использование другого метода, добавил в метод еще один параметр или что-то подобное. В результате куча тестов перестала работать. И теперь, поменяв одну строчку в процессе рефакторинга, надо поменять еще 30 строк в тестах. В какой-то момент начинаешь ловить себя на мысли - “Ни в коем случае, никаких рефакторингов больше!”

Автор:

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

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

Представьте утро. Вы открываете ноутбук, заходите в Allure — и видите красное море.

Падает половина автотестов, часть — «временно», часть — «иногда». Почти каждый день начинается с одних и тех же починок, дебага и «вроде теперь стабильно».

Знакомо? Скорее всего да, иначе вы бы не открыли эту статью.

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

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

Каждый упавший тест — это не просто «флак» или «ошибка окружения». Это пропущенная проверка, потерянное доверие и часы бесполезных фиксов. Если таких тестов сотни, то со временем автотесты перестают быть инструментом качества — и превращаются в источник шума.

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

Автор:

Что общего у кулинарии и автоматизации тестирования?

Что общего у кулинарии и автоматизации тестирования, спросите вы? Можно провести красивые параллели между программированием и готовкой: автоматизаторы тестирования как шеф-повара, скрипты автоматизации как рецепты, фреймворки автоматизации как кастрюли и сковородки, а кулинарная книга — как эта статья! Эта статья посвящена всем тестировщикам, которые ищут новые рецепты аутентификации с использованием Playwright.

Статья предназначена для автоматизаторов тестирования, которые уже знакомы с Playwright или используют его в своей работе. Для демонстрации я буду использовать учебный магазин Book Cart, на который я наткнулась в статье Сары Дири на сайте Ministry of Testing.

Для этой «поваренной книги» я отобрала четыре рецепта аутентификации, варьирующиеся от базового до среднего уровня сложности. Эти рецепты используют сочетание методов аутентификации через UI и API, с объяснением реальных сценариев применения для каждого из них.

В феврале этого года я писал на Хабре про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.

С тех пор фреймворк вырос. Сильно. Из узкоспециализированного решения для промышленного ПО превратился в универсальный инструмент. Теперь работает с чем угодно - офисные пакеты, банковские клиенты, CAD-системы.

Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.

Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.

Автор:

Таймауты — одна из ключевых частей end-to-end тестирования UI. При тестировании пользовательских интерфейсов мы часто сталкиваемся с различными формами случайности (или кажущейся случайности) в том, как элементы появляются и взаимодействуют.

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

Автор:

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

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

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

Автор:

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

Но насколько на самом деле надёжны эти тесты? Могу ли я верить, что они будут проходить успешно и падать именно тогда, когда нужно? Покрыл ли я все важные моменты?

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

Когда я говорю о тестировании тестов, я демонстрирую это с применением мутационного тестирования (недавнюю лекцию можно посмотреть здесь), но до сих пор я в основном использовал PITest для Java. Поскольку RestAssured.Net — библиотека на C#, я не могу использовать PITest, но слышал много хорошего о Stryker.NET – это был идеальный шанс наконец испробовать его в деле.

Автор:

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

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

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

Обратите внимание, что всякий раз, когда я использую слово «тест» в оставшейся части этой статьи, я имею в виду автоматизированный тест / проверку, которая подтверждает или опровергает ожидания относительно поведения нашего продукта. Не думаю, что эта модель так же хорошо применима к исследовательскому тестированию (но буду рад, если меня опровергнут).

Зачем нам управлять временем?

В начале немного о себе, мое основное занятие — обеспечение качества на вверенных проектах, я Senior QA в компании Umbrella IT. Периодически при тестировании микросервисов приходится сталкиваться с необходимостью изменения времени для проверки работы того или иного функционала. Это может быть функционал, который срабатывает по «тику» cron, или связанный с применением системного времени как одного из условий обработки/хранения/передачи данных тестируемым микросервисом.

Если микросервис разворачивается в Docker, то время контейнера берется из системного времени хост машины и без дополнительных инструментов максимум, что мы можем поменять — это часовой пояс контейнера, но не само системное время. Проблема в том, что часто для целей тестирования просто изменения часового пояса, ровно как и изменения времени в пределах 24х часов, оказывается недостаточно. Что делать если нам нужно протестировать работу микросервиса в граничных значениях даты‑времени, например начало и конец месяца/года, или использовать замечательные даты, такие как 29 февраля, последние даты месяцев со сменой количества дней, и так далее?

Меня зовут Надежда Буртелова, я ведущая тестировщица в музыкальном сервисе Звук. В тестировании с 2014 года, с 2022 года работаю в Звуке: тестирую backend и менторю коллег. Последние два года активно пишу автотесты. 

Закончила МФТИ: факультет аэрофизики и космических исследований. 

В статье разберу причины нестабильности автотестов на бэкенде и предложу способы их стабилизации. Расскажу, как из одного «флакающего» теста сделать три стабильных, стоит ли автоматизировать изначально нестабильные сценарии и когда лучше что-то убрать из автотестов и сохранить адекватное покрытие.