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

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

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

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

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

В этой статье я покажу, как построить гибкий и масштабируемый подход к тестированию фильтрации с помощью Playwright + TypeScript, используя: Page Object Model, Data-driven testing, конфигурацию фильтров и кастомные фикстуры.

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

Добрый день, уважаемые хабровчане! Меня зовут Евгений Иванов, и вот уже год я работаю на позиции QA-lead в компании FixPrice. В прошлом году руководство поставило передо мной задачу: наладить быстрый старт автотестирования и масштабирование решений на все проекты нашего отдела.

Mock-сервисы (или мок-сервисы) — это программные компоненты, которые имитируют поведение реальных сервисов, систем или зависимостей в процессе разработки и тестирования приложений. А мы сделали свой.

Дэвид Истман, разработчик ПО для Oracle Corp. и British Telecom, тестирует ИИ-инструмент для кодинга под названием Bolt. Совместно с ИИ-ассистентом он пробует разработать простенький проект блога, попутно рассуждая о сильных сторонах, ошибках и нюансах сервиса. Статья будет полезна новичкам и желающим приобщиться к вайб-кодингу работе с ИИ-помощниками.

Основан на pluggy. Основная единица pytest - pytest плагин. Написан достаточно интересно. Ключевое слово - “ключевое слово”. Основное взаимодействие в pytest происходит через хуки. Хук это некий этап к которому можно получить доступ к той или иной логики работы. Следуя из названия это некоторые крючки за который можно цепляться вставляя свои заплатки. Начинаются с pytest.

Фикстуры (Fixture) в  pytest это некий аналог мока/сетап tear down в unittests.  Это некие кусочки кода результаты которых могут быть пере использованы. Сами фикстуры реализованы как плагин. 

Как уже говорилось в эта система плагинов полагается на Pluggy. В Pluggy програамма полагается на PluginManager который управляет сохранения спецификаций хуков регистрацией плагинов и вызовом их. Плагины могут регистрировать сами себя в PluginManager.

Когда хук стартуют они вызывают свои имплементации по умолчанию как LIFO очередь - самый поздний элемент вызывается раньше всего. Для изменения этого порядка вызова можно применять trylast or tryfirst свойства в их имплементациях(пример). По умолчанию возвращается результат от всех имплементаций с исключением случая с как  firstresult свойством. В случае свойства firstresult программа возвращает результат первого не None результата. 

Другое интересное свойство имплементации плагина это hookwrapper.  С помощью этого свойства имплементации будут вести себя как обертки над другими хуками с помощью yield.

Вдохнули?

Хуки вызываются 3 способами:

Если вы когда-либо писали автотесты для веб-приложений с элементом canvas, то наверняка знаете, как это может быть непросто. Canvas — это "чёрный ящик", где привычные инструменты UI-тестирования бессильны: внутри нет DOM-структуры, за которую можно зацепиться. При этом на экране canvas может отображать что угодно — от графиков с осями X и Y до сложных анимаций.

Хотите узнать, как автоматизировать тестирование canvas без лишней боли? Давайте разберёмся на простом примере.

Я решил проверить, как популярные генераторы изображений справляются с одной и той же задачей: сделать фотореалистичный женский вариант известного персонажа игры. Участники: GPT (DALL·E), Gemini, Qwen и «Шедеврум» (Яндекс).

Что должен знать и уметь успешный тестировщик? Знания и опыт не появляются сами по себе: у каждого QA есть свои книги, статьи и ресурсы, которые помогли ему начать и освоиться в сфере тестирования.

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

Если надоело открывать Postman и вручную запускать каждую коллекцию или проверять эндпоинты по очереди, то решение есть — Newman, терминальный раннер от команды Postman. Его функционал позволяет:

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

запускать их прямо из командной строки,

получать отчёты для анализа или интеграции в CI/CD.

В этом кейсе покажу путь от экспорта коллекций до автоматического прогона тестов через Newman CLI.

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

Если вы начинающий специалист в автоматизации тестирования, или автотестировщик с опытом, готовый обсуждать и улучшать стратегии тестирования, то с радостью представляю вам первый пост в серии, посвященный разборам подходов к тестированию ПО. Здесь я разбираю свой взгляд на способы решения реальных задач по тестированию, используя Playwright + TypeScript.

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

При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест‑кейсов, задач на тестирование и найденных дефектов.

В этой статье рассмотрим, как использовать функционал Jira в задачах тестирования: от сохранения запросов до интеграции с другими системами.

Статья будет полезна для всех участников QA‑команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться.

В каждом собеседовании наступает момент, когда интервьюер говорит: «Какие у вас есть вопросы к нам?». Для большинства это вежливая формальность. Для сильного специалиста — это главный этап собеседования, на котором уже он оценивает компанию.

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

Это руководство поможет вам превратить список вопросов в системный подход к оценке будущего работодателя.

Привет, меня зовут Роман Поляков, я инженер по тестированию (QA-самурай) в Т1 Иннотех. В мире ручного функционального тестирования каждый день идёт битва за качество. Смена требований, пропущенные баги, плотные дедлайны и тонны тестовых сценариев могут сломить даже опытного специалиста. Но настоящий QA-самурай не сдаётся. Он превращает рутину в искусство, а стресс — в топливо для роста.

Если вы когда-нибудь думали, что работа QA — это просто сидеть и нажимать на кнопки в надежде, что баги сами обнаружатся, то… вы немного заблуждались! Добро пожаловать в увлекательный и порой весьма запутанный мир тестирования, где каждый день сулит встречу с новыми подводными камнями, ловушками и, конечно же, классическими граблями на пути к качественному продукту.

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

Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome. 

Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда. Добро пожаловать под кат.

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

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

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

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

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

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

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

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