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

В этом тексте расскажем, как мы за две недели собрали MVP генератора тест-кейсов на базе GenAI для компании IT Media Service. До этого ребята вручную писали сотни тест-кейсов и автотестов к каждому релизу, тратили на это тонны времени, а автоматизация требовала улучшения. 

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

Однажды мне предложили попробовать написать автотест для этого проекта, чтобы понять, будет ли мой подход эффективнее. Я использовал базовый Page Object Pattern и немного модифицированные (ради стабильности) методы Selenium. В результате получился выигрыш в ~10–15%. То есть смысла переписывать тесты особо не было.

Это стало отправной точкой. С тех пор прошло около 10 месяцев: я сменил несколько проектов, и на последнем количество тестов перевалило за сотню, а время выполнения превысило час. В целом ничего критичного — приходишь утром, запускаешь тесты и… спокойно идешь делать кофе или чай. Возвращаешься, проверяешь статусы задач, почту, составляешь план на день и т. д.

Круто? Да. Вот только при росте количества тестов очевидно вырастет и время выполнения. Ещё пара сотен тестов — и я буду успевать сгонять за кофе на другой конец города и обратно. Так что нужно искать решение.

Итак, первая часть нашего пути позади. Ваше резюме отшлифовано, мотивация ясна, и вы успешно пробили HR‑фильтр. Вы получили заветное письмо: «Приглашаем вас на техническое интервью». Сердце делает кульбит. Радость сменяется новой, более холодной волной тревоги. Теперь предстоит разговор с теми, кто будет оценивать вашу профессиональную подготовку. И здесь вас может ждать кто угодно. Это может быть ваш будущий QA‑лид или старший специалист по тестированию, проджект‑менеджер (как было у меня дважды), а порой — целая техническая комиссия из разработчика, системного архитектора и тимлида. Важно понимать: далеко не все из них «говорят с кодом на ты», но каждый будет оценивать вашу логику, понимание процессов и техническую смекалку.

Это и есть главное событие. «Boss‑fight» первого уровня, где проверяют не только то, что вы знаете, а то, как вы мыслите, как справляетесь с давлением и готовы ли вы стать частью команды. Кажется, что это экзамен, где каждый неверный ответ — шаг к провалу. Но главный секрет, который мы раскроем в этой статье, прост: техническое собеседование — это не экзамен, а диалог. И ваша цель — не сдать его на «отлично», а провести как равный собеседник.

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

Асинхронность в тестах выглядит как способ «бесплатно» ускорить прогон: пока один тест ждёт ответа сервера, другой мог бы выполняться. Я переписал UI (Playwright) и API (HTTPX) тесты на async/await, прогнал их в CI/CD и посмотрели на результат. Спойлер: магического ускорения не произошло — разбираемся, почему так и когда асинхронность всё-таки нужна.

Что происходит с QA-индустрией и куда она движется? Действительно ли профессия умирает или у неё есть будущее?

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

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

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

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

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

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

Почему ваши нагрузочные тесты врут? Часто проблема не в коде и не в стенде, а в данных. Разбираемся, как правильно готовить окружение перед тестами и почему сидинг через API надёжнее прямых вставок в БД.

У вас в проекте появились feature‑toggles, а API тесты никто не отменял?

В статье рассматривается практический пример кастомизации тестового фреймворка xUnit для написания API тестов с учётом feature‑toggles в условиях их конфликтующих состояний.

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

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

Как выбрать профиль нагрузки, чтобы результаты тестирования имели смысл? Разбираем 5 практических правил, основанных на SLA, данных с продакшена и прогнозах роста, и объясняем, почему важно учитывать не только клиентские, но и системные метрики.

Привет, Хабр!

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

Штрафы за нарушение 152-ФЗ или размещение ссылок на экстремистские организации могут достигать 15 миллионов рублей. Блокировка домена — вопрос времени. А ведь на большинстве сайтов запрещённые элементы «вросли» в код на уровне CMS, шаблонов и CDN.

Я устал вручную искать url в консоли. Мне нужен был инструмент.

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

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

В прошлой части уже описали некоторые «внешние» инструменты (ссылка). Сегодня поговорим о возможностях внутри самих тестов.

Текст подготовлен по материалам выступления приглашенного спикера внутри компании.

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

Привет, Habr! Меня Женя Паршин, и я инженер по автоматизации тестирования, работающий преимущественно в e-commerce. В этой статье я расскажу, почему создание собственного фреймворка для автоматизации — это не "изобретение велосипеда", а практичное решение.

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

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

Одним из инструментов, предоставляющих возможность автоматизации данного вида тестирования, является Playwright.

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

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.

Так удобно готовить тестовые данные. Заранее прикинул классы эквивалентности, и создал всё одним махом. Нужно исправить? Вот он, файлик, в формате csv или json — легко читается, легко исправляется. 

А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users.