Всем привет, меня зовут Булат Маскуров, я 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 лет с момента, когда слуги народа решили, что пора создавать отечественные аналоги популярных в народе сервисов, приложений, платформ.
Решение, безусловно правильное, нужное, но вот реализация, как всегда.
Хочу провести скромную ревизию того - что нам обещали и что мы получили в итоге (это будет сугубо субъективное мнение среднестатистического пользователя):
Привет! Я Павел Лобач из команды инфраструктуры тестирования Т-Банка. Расскажу, как у нас организована инфраструктура для запуска E2E браузерных тестов, как она развивалась и как в итоге вылилась в открытый проект Selebrow.
Будет много технических подробностей и ни слова про ИИ!
Привет! Я Женя, работаю QA-инженером. У нас в компании случился классический сюжет: с ростом команды появились проблемы из-за отсутствия системы управления тестированием. Решили внедрять, но какую выбрать? Устроили мини-исследование. Где-то радовал функционал, но пугали возможная блокировка или цена. Где-то нужно было пройти квест по настройке под себя. Были и неожиданно приятные находки. Что в итоге оказалось под капотом у пяти TMS из нашего топ-листа — в моей статье.
Привет! Я Ева, тестировщик в KTS.
В этой статье я хочу рассказать про Requestly — мощный инструмент, позволяющий перехватывать и модифицировать HTTP-запросы и ответы без участия разработчиков. Он особенно полезен при тестировании нестандартных сценариев, симуляции ошибок и быстром создании нужных тестовых данных.
Во многих разделах Requestly есть обучающие видео про работу с этим инструментом, однако они не всегда подробно покрывают все его возможности. К тому же, на русском языке материалов о нем довольно мало. Я решила собрать весь свой опыт работы с Requestly в один объемный туториал — от начала работы до конкретных юз-кейсов.
В этой статье мы разберем как можно быстро и удобно конвертировать mind map в чек листы с дальнейшим импортом в Testops и Testrail.
Цель - сэкономить время на рутинных операциях с тестовой документацией.
Мы ускорили релизный цикл в 2 раза за счёт жёсткого shift‑left: запретили писать и коммитить код без ранней проверки требований и автогенерации тестов ИИ. Рассказываем, как у нас это получилось и насколько выгоден такой подход компании.
Google выпустил Computer Use на Gemini 2.5 Pro для автоматизации действий в браузере. Его стали сравнивать с Operator от OpenAI и Comet от Perplexity. Разбираемся, чем они отличаются по возможностям, доступности и сценариям для компаний.
Мнение пользователей о продукте — основное мерило качества работы всей команды. В каждом спринте мы делаем все возможное, чтобы подготовить стабилизированный и соответствующий ожиданиям пользователей релиз. Хотя баги — часть нашей профессии, неприятно узнавать о том, что какие‑то из них проскользнули в продакшн.
Мы регулярно проводим работу над ошибками, благодаря чему стали использовать кросс‑ревью: практику, которая раз за разом помогает нам расширять список проверок и грамотно их структурировать, позволяя получать при тестировании больший профит при меньших трудозатратах. Меня зовут Михаил Михайлов, я руковожу отделом тестирования Polymatica BI, и в сегодняшней статье расскажу, как сейчас устроен этот процесс в нашей команде.
Мультимодальные модели блестяще «понимают» сцены, но промахиваются там, где тестировщику важно точное соответствие: в сравнении двух версий одного экрана. Случайный сдвиг на несколько пикселей ломает пиксельные diff’ы и маскирует реальные проблемы — вроде исчезнувшей кнопки. Разбираем, почему так происходит, как компенсировать искажения многоуровневым сопоставлением и как простая CNN по окнам 9×9 помогает выявлять именно релевантные отличия.
Работая в области машинного перевода в компании Lingvanex, я постоянно читаю статьи в которых сравнивается качество разных переводчиков. Иногда отличие между ними составляет от 0.3 до 1% по какой-либо из метрик, но и это уже повод заявить, что их переводчик - лучший.
При оценке качества машинного перевода важно не только сравнить результаты различных систем перевода, но и проверить, являются ли обнаруженные различия статистически значимыми. Это позволяет оценить, насколько полученные результаты достоверны и могут ли они быть применимы к другим наборам данных.
В данной статье рассматриваются две наиболее распространенные метрики для оценки качества перевода — BLEU и COMET. Также проводится анализ того, как проверить статистическую значимость различий между двумя системами перевода, используя эти метрики.
