Семь раз оттесть, один раз деплой
Breaking change в REST API часто обнаруживают слишком поздно — уже на интеграционном стенде. Разберём, какие риски можно поймать раньше, где помогают OpenAPI и consumer contracts и почему зелёные проверки ещё не гарантируют совместимость со старым клиентом.
Постмортем Electron-редактора меню: SceneTree, PDFKit и тесты, которые доказали не то
Я вернул «Объём» в поле, для которого он был задуман.
Текст наполз на цену.
Четыре релиза подряд проходили автоматические тесты. Зелёный статус только подтверждал обходной путь, который модель сама придумала, реализовала и затем закрепила проверками.
Когда визуально все выглядело хорошо, пошла проверка деталей, на этапе которой результаты тестов разошлись с реальностью. Проверил руками и увидел, что объём лежит не там, где должен. Не в Position.volume, а внутри PriceNote. Четыре релиза. Четыре зелёных гейта. Четыре раза процесс сказал «всё правильно» тому, что правильным не было. После этого пришлось разбираться не только с багом, но и с контрактом, который его пропустил.
Негативные тесты часто выглядят убедительно: отправили некорректный запрос, получили 4xx, проверка зелёная. Но такой результат ещё не гарантирует, что сработало именно нужное бизнес-правило. Запрос мог быть отклонён раньше — на уровне авторизации, схемы или другого поля.
В статье разбираем, как проектировать негативные API-тесты так, чтобы они действительно проверяли ограничения: готовить валидные данные, изолировать одно нарушение за раз, проверять структуру ошибки и убеждаться, что после отказа система не изменила состояние.
Тест зелёный, а фича сломана — потому что проверка смотрит на форму, а не на эффект: имя поля в файле есть, а в разметку оно не попало. Семь таких случаев из живого проекта на 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: контекст, тестирование требований, генерацию тестовой документации, автотесты и оптимизацию тестовой модели. Но даже когда кейсы написаны, а автотесты готовы, остаётся задача, на которую может уходить довольно много времени — это подготовка тестовых данных для ручного тестирования.