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

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

Сегодня доступно множество инструментов: 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. Также проводится анализ того, как проверить статистическую значимость различий между двумя системами перевода, используя эти метрики.

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

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

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

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