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

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

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

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

Сразу — не надо так!

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

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

Дано:

* Растущее количество ручных тестов (иногда переваливающее за тысячи), которые сложно поддерживать.

* Отсутствие нормального переиспользования шагов в стандартных системах, из-за чего приходится постоянно дублировать общие шаги.

* Рассинхронизация между автотестами и ручными кейсами, приводящая к спорам о том, какой тест считать актуальным (главным).

* Сложности с параллельной работой в ветках, ревью изменений и плохой аудит удалений, где один клик может снести целую группу тестов.

Найти:

* Единый источник правды для всех тестов на проекте.

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

Привет, Хабр. Меня зовут Виталий Стародубцев. Я ведущий QA-инженер в СберЗдоровье — MedTech-компании №1 в России.

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

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

Всем привет! Продолжаю цикл статей про применение ИИ в тестирование. Сегодня поговорим про тестирование требований, а именно про первый и самый важный этап — подготовку контекста. 

В своей статье под контекстом я буду подразумевать структурированную информацию о продукте: описания компонентов, бизнес-правила, сценарии использования, связи между сущностями — то есть всё то, что нужно ИИ для понимания предметной области.

Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.

В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.

Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.

Разбираемся с терминологией Test Doubles без лишней воды. В чем реальная разница между Mock, Stub и Fake? В статье разберем классификацию на живых примерах: поднимем умный стаб-сервер на FastAPI, напишем мок-шпион для проверки сайд-эффектов и ускорим тесты с помощью фейковых БД.

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

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

Привет! На связи Саша Мищенко, тимлид платформенной команды, и Света Чекунова, Senior QA Auto. Нам кажется, что мы нашли этот баланс.

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

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

Привет, Хабр. На связи Маша Лещинская, Head of QA в Surf. Мы все любим пет-проекты, и еще больше — пет-проекты на AI. Но есть нюанс: большинство таких штук забываются через неделю, потому что их сложно и дорого поддерживать. Я сделала проект, который живёт уже третий месяц, и причина не в каких-то крутых технологиях, а в том, что цена поддержки стала минимальной.

Привет, Хабр! Это команда Яндекс Практикума. В этом году мы переосмыслили, актуализировали и переупаковали курсы по тестированию: изменили методики и обновили программы с учётом изменений на рынке. Рассказываем самое важное.

Привет, Хабр! Меня зовут Илья, я работаю Manual QA в команде, которая отвечает за качество продукта с большим количеством микросервисов, API и регулярными релизами. Если вы хоть раз писали тест-кейсы по тикету из Jira, потом руками собирали Postman-коллекцию по OpenAPI-спецификации, а после ревью документации обнаруживали, что половину сценариев забыли — эта статья для вас.

Я собрал инструмент, который автоматизирует три самых рутинных задачи QA-инженера: генерацию тест-кейсов, генерацию API-тестов и ревью документации. Всё это под одной крышей, с поддержкой любого OpenAI-совместимого LLM (включая локальные модели), с интеграциями в Jira, Confluence, TestRail, TestIT и Zephyr Scale.

Проект называется Test Generator Suite (TGS), и в этой статье я расскажу, какие проблемы он решает и как устроен внутри. Сразу оговорюсь: я не разработчик, я QA, и большую часть кода писал «как умею» — поэтому если в архитектурных решениях вам что-то покажется странным, я заранее согласен. Это инструмент для коллег по цеху, а не образец Python-инженерии.

Привет! Я Даша, QA в команде Смартбот. Эта статья будет о том, как мы перестали спорить о срочности обращений и багов.

Начну с краткой исторической справки. Около года назад я начала тонуть в задачах на саппорт и эскалациях. В чат прилетала карточка с названием вроде «Не работает отправка сообщений», и уже по одному заголовку казалось, что нужно бросать все и срочно фиксить. Потом я погружалась в задачу и понимала, что проблема воспроизводится только у двух пользователей, и оба сидят через Explorer.

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

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

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

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

По данным World Quality Report 2025, 89% компаний пилотируют или внедряют Generative AI в процессы Quality Engineering. При этом только 15% сделали это на уровне всей организации. Остальные находятся в стадии осторожного эксперимента.

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

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

Вы можете замокать aiohttp.ClientSession._request и получить зелёный CI. Но этот тест всё ещё не доказывает, что у вас работает timeout. И не доказывает, что клиент переживёт обрезанный JSON. И не доказывает, что retry реально делает три HTTP-запроса через сокет.

В этой статье я прогоняю один и тот же сценарий через пять уровней тестирования внешнего API — от DI-заглушки до настоящего HTTP-сервера — и показываю, где каждый уровень врёт.

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

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

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

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

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