Automation QA | IT

Частые проблемы при тестировании в Playwright (и способы их решения)

#почитать

В этой статье расскажем о популярных проблемах при тестировании в Playwright и поделимся способами их решения

⏱Читать статью

Ассистент ошибся. На каком этапе?

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

У karpovꓸcourses есть гайд «Как создать ИИ агента». В нём разбираются механика RAG на реальных примерах, варианты запуска LLM и основные понятия архитектуры.

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

Забрать файл в боте: https://clc.to/2UUS2w

Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFH1tuD3

Что должен знать и уметь разработчик автоматического тестирования, чтобы называться инженером

#почитать

В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

⏱Читать статью

Тестирование с плагинами из маркетплейса GigaIDE

#почитать

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

⏱Читать статью

UI-автотесты: Fluent-стиль и умные данные — чтобы тесты работали на вас, а не вы на них

#почитать

В статье — как сделать автотесты читаемыми, стабильными и предсказуемыми: Fluent API, централизованные данные, логирование, retry и философия «ошибка — это информация».

⏱Читать статью

10 Chrome-расширений для QA часть 2

#почитать

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

⏱Читать статью

Chaos Engineering: что это за метод тестирования, этапы и инструменты

#почитать

История метода chaos engineering неразрывно связана с гигантами IT-индустрии, которые первыми столкнулись с проблемами масштаба. Пионером в этой области стала компания Netflix. Их переход в начале 2010-х годов с локальных серверов на распределённую облачную архитектуру в Amazon Web Services выявил серьёзную проблему: традиционный контроль качества не мог предсказать все возможные сбои в новой сложной среде. Любая ошибка, будь то отказ сервера или проблемы с сетью, могла вызвать цепную реакцию и остановить работу всего сервиса.
Инженеры Netflix осознали: чтобы система стала по-настоящему отказоустойчивой, её нужно испытывать в условиях, максимально приближенных к реальным сбоям. Так на свет появился первый и самый известный инструмент — Chaos Monkey. Его задача была проста и разрушительна: в случайное время отключать виртуальные машины в рабочем кластере. Это заставляло команды разработки с самого начала создавать продукты, которые могли бы работать несмотря ни на что. Успех этого подхода доказал его эффективность, и метод chaos testing начал быстро распространяться среди других крупных компаний.

⏱Читать статью

Убрать рутину из регресса или как автоматизировать, не зная кода

#почитать

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

⏱Читать статью

Как тестировать взаимодействие с голосовыми интерфейсами и виртуальными помощниками

#почитать

Голосовые ассистенты прочно вошли в нашу жизнь, трансформировавшись из модного гаджета в полноценный бизнес-инструмент. Они управляют умным офисом, интегрируются с корпоративными системами (CRM, ERP), автоматизируют процессы бронирования и клиентской поддержки. Для QA-специалистов это означает появление нового, сложного и крайне перспективного объекта для тестирования. Голосовой интерфейс (VUI — Voice User Interface) ломает все традиционные парадигмы веб- и мобильного тестирования, требуя совершенно иного подхода к построению стратегии обеспечения качества.

⏱Читать статью

Termidesk Connect vs BIG-IP F5 и Citrix NetScaler: новичок и классика в нагрузочных тестах

#почитать

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

В этой статье разберу три решения для закрытия проблемы с «главным подозреваемым»: F5 BIG-IP, Citrix NetScaler и Termidesk Connect. Если решения от F5 и Citrix хорошо известны на рынке, то Termidesk Connect — достаточно молодое решение от «Группы Астра». Релиз версии 1.0 состоялся весной 2025 года, под конец года вышел релиз 1.2 — его-то я и разберу в статье.

Логика сравнения продуктов максимально приземленная: одинаковые вводные, единая методика и попытка посмотреть на поведение «как в жизни». У меня нет цели выбрать лучшее из представленных решений, скорее — честно показать сильные стороны и возможные подводные камни.

⏱Читать статью

Как мы автоматизировали анализ упавших тестов с помощью AI: от хаоса к структуре

#почитать

Представьте: каждый день ваши автотесты генерируют десятки отчетов об ошибках, QA команда тратит часы на анализ падений, а разработчики получают невразумительные описания в духе "test.feature упал на строке 410".

⏱Читать статью

Ручное управление не делает нас сильнее: как я написал клиент для автоматизации тестирования

#почитать

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

Зачем нужно было переезжать? Очень хотелось собирать и хранить данные тестирований разных отделов и команд в одном месте и в одном стиле. Иначе, как водится у инженеров, каждый обзаведется пачкой тестов и будет хранить их у себя «под ковриком». А когда доходит дело до презентации результатов другим, оказывается, что «коврик» исчез или его нет под рукой.

Заезжать в TMS всегда больно. И ладно еще писать, оформлять тест-кейсы с нуля — это полбеды. Главная боль — ведение отчетности.

⏱Читать статью

Агенты Playwright

#почитать

С выходом Playwright 1.56 в инструменте появились три новых агента: Planner, Generator и Healer. Они помогают создавать сценарии, поддерживать тесты и выявлять нестабильное поведение.

⏱Читать статью

Requestly: гайд для тестировщиков

#почитать

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

⏱Читать статью

Интеграция OpenSearch: от функционального тестирования до проверки интеллекта поиска

#почитать

В этой статье я на реальном примере интеграции OpenSearch в LMS iSpring Learn расскажу, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Мы не только разберём базовые проверки, но и погрузимся в тестирование стемминга, релевантности, работу в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск».

⏱Читать статью

DIY Observability для автотестов, используя Pytest, ClickHouse и Grafana

#почитать

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

⏱Читать статью

Разделяй и тестируй: @DataJpaTest и @WebMvcTest для быстрых тестов Spring Boot

#почитать

Начнём с того, почему вообще тесты могут быть медленными. Используя @SpringBootTest, мы просим Spring Boot поднять весь контекст приложения для каждого тестового класса. У нас доступны все бины, но часто все это избыточно. Например, хочется протестировать контроллер, а Spring загружает ещё и базу данных, и сервисы, и шлёт запросы к Kafka. В результате простой тест метода контроллера может запускаться несколько секунд, пока поднимется веб‑сервер, инициализируется база, подтянутся все классы.

Эту проблему осознали и добавили так называемые test slice‑аннотации. Все простоб грузим не весь контекст, а только срез приложения, например, только веб‑слой или только слой доступа к данным. Spring Boot содержит готовые slice‑аннотации для основных слоёв: @WebMvcTest для веб, @DataJpaTest для JPA‑репозиториев, и ещё пачку для других случаев.

⏱Читать статью