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

Тест зелёный, а фича сломана — потому что проверка смотрит на форму, а не на эффект: имя поля в файле есть, а в разметку оно не попало. Семь таких случаев из живого проекта на TypeScript и PostgreSQL: колесо мыши, которое убил мой собственный CSS-фикс и диагностика, проверившая defaultPrevented вместо прокрутки; подстрока, совпавшая с другой подстрокой; комментарий в SQL, прочитанный как код; метка источника, из-за которой отчёт показывал ноль и этот ноль читался как «людей нет». С кодом, разбором каждой ошибки и числами мутационного прогона на 13 400 мутантов.

Привет, меня зовут Артем Русов. Я автор курсов и образовательных материалов для тестировщиков. Сегодня первое сентября, и это удобный повод подвести итог одной работы.

С февраля я собираю курсы по тестированию, устроенные как игра: Древняя Греция для REST API, Древний Египет для GraphQL, город Цифроград для основ компьютерной грамотности. Сюжет, персонаж-проводник, задания в декорациях мира.

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

Ответ получился неудобным для заголовка. Геймификация улучшила почти всё, кроме одной метрики.

Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.

Впервые ежедневный анализ открываемых и закрываемых вакансий в более чем 2000 IT-компаний показал тренд роста вакансий, где требуется тестирование AI-приложений.

У нас семь публикаций в день на четыре площадки, и все они идут через один общий Chrome с живыми сессиями.

В моей игре доменный слой не знает, что существует Three.js. И Rapier. И DOM.

Звучит как оверинжиниринг для платформера, где уровень проходится за полторы минуты, - и наполовину это правда. Но одна вещь окупила всё: e2e-тесты перестали мигать, потому что симуляцию стало можно прокручивать синхронно, не завися от скорости отрисовки.

Внутри: как выглядят порты, во что реально обошлась дисциплина, и в каком месте мне пришлось её нарушить.

В двухнедельном спринте регрессия часто превращается в лотерею: фичи доделывают до последнего дня, полный прогон не помещается в окно, а красному CI уже никто не верит. В итоге команда выпускается, ориентируясь на ощущение, а не на понятную картину рисков.

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.

Как перейти от разовых ИИ-запросов к многоразовым Agentic AI рабочим процессам в QA. Я собрал несколько практических примеров, паттернов и предостережений, которые помогут инженерам по тестированию осуществить этот переход постепенно

Всем привет! Сегодня хочу рассказать об особенностях автоматического тестирования крупного проекта на Django, в котором тесты написаны в разных стилях и есть много пересечений моделей данных. Поговорим о том, как привести всё к единому знаменателю без риска получить непредсказуемое поведение тестов. Также разберём конфигурацию pytest, параметры его запуска, работу с фабриками моделей и стили тестирования в двух парадигмах (Django и чистый pytest).

Flaky-тесты способны довести до отчаяния любую команду. Они падают без видимой причины, ломают пайплайны, откладывают релизы и портят настроение всем — и тестировщикам, и разработчикам. В 2ГИС мы жили с этой болью довольно долго, пока не решили подойти к проблеме системно. 

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

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

Меня зовут Михаил, в Ozon занимаюсь тестированием и автоматизацией финансовых сервисов маркетплейса. До этого за шесть лет мне довелось поработать в шести компаниях и получить опыт в проектах разного масштаба. Многие из них проходили нижеописанные этапы развития, хотя различались продуктами, командами и технологическим стеком. В этой статье я разделю этот путь на четыре условных уровня и покажу, какие метрики сигнализируют о необходимости роста, а также разберём этот процесс на всех уровнях: от архитектуры фреймворка до выстраивания процессов и TestOps.

Что происходит, если вместо массовой раздачи AI-инструментов сначала изучить, как на самом деле работают команды?

Рассказываю, как мы начали AI Enablement в крупной финансовой организации: оценили 13 команд, визуализировали их delivery pipelines, обучили около 800 человек и построили программу вокруг реальных ботлнеков, а не вокруг модных AI-инструментов.

«Playwright сейчас модный, Selenium старый, Cypress удобный». Именно так чаще всего звучит выбор фреймворка на планировании — и именно поэтому команды потом полгода разгребают последствия решения, принятого за один созвон.

Я сам проходил этот выбор не один раз, и каждый раз он оказывался сложнее, чем «взять модное». Дальше — разбор архитектуры, реальных ограничений и того, во что выбор фреймворка выливается через год, когда тестов становится не 20, а 2000.

Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.

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

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

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

Сразу скажу что именно чтобы тем кому надо знать только итог не тратили свое время на чтение. Сайт лежит в виде виртуальной машине убунта без морды на арендованном довольно шустром хосте с 64 Озу 12 ядер 500 ССД и канал 1G. Хост крутит тоже убунта без морды.

Ну и для сайта выделено было пару ядер и пару гигабайт памяти.

Что делает сам сайт — он подключен ко всем буквально источникам новостей об ИИ как к лидерам рынка, так к вендорам и агрегаторам. Суммарно 100 источников. Он собирает все новости что найдет и те что не на английском переводит на английский. Затем чистит от дубликатов. То что осталось раскладывает на рубрики, переводит на 15 языков и выкладывает себе в ленту, выкладывает в Канал в телеге на русском только и все новости на всех языках пихает в ленту RSS.

Чтобы все это делать он пользуется несколькими ИИ подключаясь к ним по API. То есть сайт чисто текстовый. Никаких вычислений тяжелых нет. Нет рендеров и нет картинок даже.

И вдруг выясняется что сайт на этой машине буквально еле ползает. Сайту неделя. Я там единственный пользователь. И чтобы ему нормально было работать оказалось что надо до 6G ему добавить память и выделить еще два ядра. Провел я расследование и вот что оказалось

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

Но тест-кейс — не синоним тестирования. Модель работает только с тем контекстом, что ей передали: не знает незафиксированные правила и может принять баг в коде за норму. Кейсов становится больше, а контроля качества — нет.

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

Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже разобрали shift-left: контекст, тестирование требований, генерацию тестовой документации, автотесты и оптимизацию тестовой модели. Но даже когда кейсы написаны, а автотесты готовы, остаётся задача, на которую может уходить довольно много времени — это подготовка тестовых данных для ручного тестирования.

Привет всем заглянувшим!

В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.

В чем «фишка» этого подхода?

Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.

За последнюю пару лет появилось множество приложений на основе ИИ и ИИ‑функций. Чем больше появляется таких приложений, тем любопытнее мне становится изучить их внутреннюю работу. Надеюсь, мне удастся узнать что‑то новое; по крайней мере, почерпну какие‑нибудь знания о разработке десктопных приложений.

В то же время я заметил, что каждый месяц всё быстрее исчерпываю свои кредиты Copilot. Это заставило меня выбрать его в качестве главного кандидата для моих экспериментов. Я решил подробно исследовать VS Code и Copilot.

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