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

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

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

Так почему же разработчики и тестировщики продолжают выбирать его? Ответ на этот вопрос я и предлагаю рассмотреть далее в статье.

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

Cloudflare показывает, как превратить метрики в механизм безопасных релизов под глобальной нагрузкой. В основе — Health Mediated Deployments: решения о выкатывании принимаются по SLI/SLO из Prometheus/Thanos, с распределёнными агрегациями на уровне дата-центров, recording rules, бэктестингом инцидентов и адаптивным ограничением параллелизма. Результат — заметно быстрее вычисляются критичные запросы, батчи ускорены примерно в 15 раз, а откаты происходят до того, как проблема успевает разрастись.

Привет! Это команда Яндекс Практикума. Мы провели встречу «Что ждёт начинающего тестировщика на собеседовании». Зрители вместе с экспертом и наставником на курсе «Инженер по тестированию» Константином Булатовым разбирались, как проходят собеседования джуниоров QA-инженеров, чего ждут от тестировщиков в резюме и как новичку показать себя с лучшей стороны на интервью. Делимся самым важным.

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

Меня зовут Мария Рогова. Я iOS-разработчик в ОК. В этой статье я расскажу, с чего мы начинали, почему требовалась оптимизация и что мы предпринимали для ускорения прогона UI-тестов в iOS.

Статья посвящена использованию Gradle в автоматизации тестирования. Рассматриваются настройка проекта, управление зависимостями, запуск тестов и лучшие практики для QA-инженеров. Приведены готовые примеры конфигураций и сравнение с Maven.

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

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

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

Особенно остро это ощущают специалисты из направления QA/SDET, ведь информации действительно очень много. Но не переживайте: SimbirSoft спешит на помощь!

Меня зовут Кирилл, я SDET-специалист в компании SimbirSoft. В этой статье я собрал список вопросов, на которые обязательно стоит обратить внимание при подготовке — как начинающим специалистам, так и закалённым «воинам» в области обеспечения качества — QA Manual, QA Automation и SDET — вне зависимости от грейда.

В условиях стремительных перемен в ИТ‑сфере специалистам по тестированию необходимо быть гибкими, осваивать новые подходы и непрерывно развивать лидерские и коммуникативные навыки. Это помогает оставаться конкурентоспособными вне зависимости от технологий.

Всем привет, меня зовут Булат Маскуров, я QA Lead в Uzum Fintech. В своей статье расскажу, как сделать WireMock «ультимативным» mock-сервером. А если пока вы не знакомы с этим инструментом, я введу в курс дела, объясню, как и зачем прикручивать к WireMock простой и удобный Web GUI, и самое интересное: покажу инструмент изнутри, опишу Extension API и расскажу про наше кастомное расширение, которое решило реальную проблему.

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

Давайте разберемся, как понять, нужны ли вам автотесты? Или придем к мнению, что вам они не нужны (пока).

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

Сегодня доступно множество инструментов: Selenium, Playwright, Cypress и другие. Каждый имеет свои преимущества. Но в подавляющем большинстве наших проектов мы используем Selenium. Расскажу, почему мы сделали такой выбор.

Цель автоматизации — экономия

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

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

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

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

Требования клиентов и гибкость технологий

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

“Запахи” в тестах — это признаки антипаттернов. Хотя причины появления запахов тестов могут быть самыми разными, сегодня мы хотим рассмотреть одну повторяющуюся тему — структуру команды, а более конкретно — проблемы в общении у тестировщиков с другими командами. 

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

- знание того, что хочет пользователь, интерпретируемое менеджментом как требования;

- знание всех технических нюансов и слабых мест тестируемой системы (SUT), известное разработчикам и ручным тестировщикам;

- теория тестирования, известная тестировщикам;

- реализация тестов на конкретном языке и фреймворке, с которыми знакомы инженеры по автоматизации (SDET).

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

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

OpenAI выпустила ChatGPT Atlas 21 октября 2025 года — первый браузер с AI-агентами, встроенными прямо в ядро. Компания обещала революцию в том, как мы работаем в интернете. Спустя несколько дней после релиза люди уже протестировали браузер на реальных задачах — и результаты получились неоднозначными.

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

OpenAI представила ChatGPT Atlas - новый уровень интеграции искусственного интеллекта в браузер. По задумке, Atlas превращает привычный ChatGPT в универсального помощника, встроенного прямо в веб-страницы. Теперь чат можно вызвать в любой момент: он суммирует статьи, сравнивает контент, объясняет непонятное и даже может взаимодействовать с сайтами от имени пользователя.

На первый взгляд - мечта QA-инженера, но не торт.

Если вы начинающий разработчик и создаете свой пет-проект, легко увлечься бэкендом и фронтендом, а на ИБ сил уже не останется. Даже если проект совсем небольшой и там, казалось бы, защищать-то особо нечего, злоумышленники всегда найдут дыры в безопасности. Взломать незащищенный сайт или приложение легче, чем кажется.

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

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

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

## Всем привет!

В этой статье я хочу рассказать о небольшой расширении, которое упрощает хранение и использование feature toggles, работающих через cookie.

Наши фича-тоглы работают по принципу указания ключа и значения в cookie. Однако при тестировании (и не только) возникает несколько болей:

* Количество тоглов уже перевалило за сотню, и хранятся они в Confluence. Постоянно ходить туда или держать их названия в голове — то ещё удовольствие.

* Тестирование на фичевых ветках осложняется тем, что из-за разных доменов UI и API невозможно авторизоваться: cookie не проставляются автоматически. Чтобы их добавить, приходится заходить на мастер-ветку, брать оттуда cookie и вручную подменять домен. Не страшно, если речь идёт об одной-двух куках, но когда их больше десяти — это уже боль.

* Просмотр результата на проде тоже не всегда прост: фича-маппер не позволит просто так поменять значение cookie и вернёт исходное.

Чтобы упростить жизнь, был создали Fookie — инструмент, который позволяет хранить, выгружать, загружать, добавлять, удалять cookie и многое другое.

Разберём всё по порядку 👇

---

### Как появилась идея

Изначально задумывалось, что Fookie будет хранить информацию о feature-флагах и менять домены.

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

Первая версия Fookie была неказистая, но рабочая — а это главное. Уже тогда можно было:

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

Решение, безусловно правильное, нужное, но вот реализация, как всегда.

Хочу провести скромную ревизию того - что нам обещали и что мы получили в итоге (это будет сугубо субъективное мнение среднестатистического пользователя):